Sign in to follow this  
Followers 3
Ranger Fox

Line Breaks

16 posts in this topic

Posted (edited)

I received a request from someone to help him with line breaks in his Wherigo\\kit cartridge. However, here's what I've been able to gather:

  • Groundspeak's emulator recognizes regular line breaks (char(13), which is equivalent to either \n or \r), the newline character, and an uppercase <BR>, but not the lowercase <br>
  • Webwigo recognizes regular line breaks and the newline character, but not <br>
  • Garmon Oregon recognizes regular line breaks and the newline character, but not <br>
  • Wherigo for iOS only recognizes the newline character (I did not test for regular line breaks), but will recognize <br> or <BR> if fed through the WF compiler (edited)
  • WhereYouGo recognizes regular line breaks, the newline character, and an uppercase <BR>, but not the lowercase <br> (edited) when fed through the WF compiler.  I'm not sure what it does when downloaded directly from Wherigo.com.  I think this app will detect some of the line break symbology in use, such as the HTML line break, and make sure it's displayed as a line break.

 

Can anyone fill in what WhereYouGo recognizes? I don't have an Android device.

I guess I shouldn't bother with retaining Garmin compatibility, but it would be a pain if WhereYouGo didn't support <br>.

*** Important: There's a difference between what you get with downloading from Wherigo.com and anything using the Wherigo Foundation's compiler.  The WF compiler will substitute a line break the player app will recognize if it sees you're trying to use line breaks.  The Wherigo.com site will just give you what you put in.  However, the WhereYouGo app seems to be smart enough to display line breaks as intended.

(edit) Thank you, Nighthawk700.

(edit) About the difference between the Wherigo.com and WF compiler.

Edited by Ranger Fox
0

Share this post


Link to post

Here's what I see on my WhereYouGo:

 

Line return:

Space character:

Line break:

Lowercase line break:<br>end

0

Share this post


Link to post

Thank you. Looks like WhereYouGo is also case sensitive when it comes to the line break character. This means I can only use <BR> for line break compatibility between the player apps.

 

I'll update my first post.

0

Share this post


Link to post

To make sure I understand this correctly: using <BR> will result in a line break for all players (but at least for Android WhereYouGo and Wherigo for iOS ?)

(my confusion comes from the fact that the edited original post still states that iOS only recognizes <br>  but the final post states that <BR> must be used for compatibility between player apps. In other words: iOS works with <br> and <BR> ?)

0

Share this post


Link to post

That's correct.  Yeah, we're all kinds of inconsistent.  Duct tape and paperclips.

0

Share this post


Link to post

Still confused after a test I did with this: see attached screenshot. On the left is the iPad and the right Android WhereYouGo

The <BR> works fine on the Android but on the iPad only shows as a <BR>

So maybe, it is what you said: the iOS only supports <br> and not <BR> ? I will test it again (but I do not have an iOS device myself and will have to rely on someone else...)

 

If I can not solve this (use one specific newline character across all players) I will make a workaround that fits into the game: I will show a message that consists of two parts delimited by the different line break characters one by one and ask the player to confirm when it is split in two lines. From there on I will use that value in var_nl variabele to concatenate my strings that needs splitting... I think I can make it work in the story without my players noticing too much I am technically struggling with this :-)

Or is there another way that you provide the same experience across players? Is there a safe way to test the device / player and branch from there to use the correct line break character?

Afbeelding1.jpg

0

Share this post


Link to post

If you email me whatever source code you have, I can test it using my iPhone.  (But you might want to post here or send me a private message in the forum that you did so because there are days when I don't check my email.)

0

Share this post


Link to post

I am building with earwigo. Do you have an earwigo account, then I can directly share with you the link. If not, I will send the .lua extraction.

 

 

0

Share this post


Link to post

Yes, I have an Earwigo account.

0

Share this post


Link to post

link sent via DM on your geocaching profile. Thank you for looking into it.

0

Share this post


Link to post

I had to trick Earwigo into giving me the GWZ of cartridge you shared with me since I couldn't see it on the screen where I can manage my own cartridges.  That was fun and easy.  I uploaded the GWZ to the WF site as WG126 (I added you as a co-creator so you can access it), got on my phone's browser, and downloaded the cartridge.  The line breaks were where you expected.  However, it's likely that's due to the WF site using our own compiler.

So I uploaded the cartridge to Wherigo.com and attempted to download the cartridge the same way (through Safari).  As an aside, the browser suggested I open the cartridge in iMovie.  When I tapped on that (I was going too fast and not reading), it opened the cartridge in the Wherigo app.  Odd.  Anyway, after that, I do see the the uppercase <BR> characters.  This means our Wherigo Foundation compiler was being nice to everyone and inserting the right line breaks for the device.  How conscientious.  (So that's where I failed in my personal testing: I used our own WF compiler instead of the one used on Wherigo.com.)

I then changed the line breaks used in the cartridge to lower-case <br>.  Again, the characters were shown and not the actual line break.

I then used the line break character used by Groundspeak's builder.  To use it in your cartridge, I had to change some double quotes to double square braces.  After updating and downloading from Wherigo.com, the iPhone's player recognized the line break.

 

To summarize, I believe the iPhone app is displaying just what the Wherigo site's compiler is giving it and WhereYouGo might be replacing within its runtime environment the HTML line break tag with an actual line break.  When the cartridge is fed through the Wherigo Foundation's compiler, it performs the work necessary to make sure the target device shows the line breaks properly.

(Still... suggesting to open the cartridge in iMovie?  The unexpected file association strikes me as funny.)

IMG_1486 (Copy).PNG

0

Share this post


Link to post

Sorry, but still a bit confused about what you did/fixed... Could you elaborate? What is the "newline character" of the GS builder? Is it \n ? And if so, what/where did you exactly change "some double quotes to double square braces" to make it work in my cartridge (with earwigo)?

I could not find it out by diff'ing the lua produced by my earwigo and your WF cartridge because I did not get a lua copy before I sent it to you...

(I before tried with \n in a string but this showed up as ... \n on the iPhone) I used a variable var_nl that I concatenate the string I want to break so I could if then else on the player to use different break characters if needed, but of course being able to use just one for all would be nicer. 

And yes, I (have to) publish it on the Wherigo.com site or my reviewer won't agree...

0

Share this post


Link to post

Update: I seached the earwigo google group on this issue and @sTeamTraen says there that you should include (in earwigo) \060BR\062\010 into a string and then at runtime his WWB_multiplatform_string  function will do the necessary conversions for the platform it is running on... 

If this is true... cool :-) but I still have to get it to work (and in webwigo I can not for the moment).

(why oh why does this all have to be so difficult)

Edited by Dani+Iris
0

Share this post


Link to post

It's probably \n, but the character itself is invisible in notepad, so it's not rendered to the user as "\n".  It could also be \r, but I don't have a hex editor at work, so I can't say.

I downloaded the cartridge from Earwigo and opened it in notepad.  I did a search for "<br>" and, wherever I found it, I replaced the double quotes encasing the string with double square braces.

var_tekstAnna = "<br>Bank 3(" .. " math.floor(var_gewichtAnna * 1000) .. " g) = " .. var_aantrekkingAnna
-- The above became
var_tekstAnna = [[\nBank 3(]] .. " math.floor(var_gewichtAnna * 1000) .. " g) = " .. var_aantrekkingAnna
-- Note: \n is used here in place of the newline character for illustration purposes.

You won't find the changes made in the WF cartridge because I made them only on Wherigo.com due to its compiler.  In the process of typing this reply, I have updated the WF cartridge listing to use the one I mentioned using on Wherigo.com.

You could likely contain that newline character in var_nl.  I don't know how Earwigo would encode it, though.

Things wouldn't be so difficult if someone was maintaining Groundspeak's Wherigo site and everyone was working off a living specification and there was real leadership.

It's good to keep all cartridges on Groundspeak's Wherigo site for now, anyway.  The WF site can be used for collaboration or playing around, but they still need to be on Wherigo.com.  Bad things would happen if I were to be hit by a truck and no one was there to carry on my work and the site closed.  But I do need to pick up pursuing the WF partnership with Groundspeak as this year has proven they're content with the status quo, and if I want to change things, I'm going to have to be more assertive.  I just don't like the last terms they proposed.  And I've improved so much in the past few years that I'd love to create a new, mobile-friendly WF site with a more robust architecture in the back end.  For now, though, I'm slowly working on improving Wherigo\\kit so I can open source it so others can contribute to the project.  I also want to do the same with the next WF site so it can be more of a community effort and not tied completely to what little free time I have.  At the moment, my full-time job is happily eating away my free time through overtime work (that I don't get paid extra for) since the beginning of the year.  The time I thought about devoting to Kit and Wherigo, I'm strongly considering using to improve the application at work since I can't get the work approved any other way but through extra hours, and I really want that done.

 

(On a side note, I noticed the localization you were using.  I wonder if I should build localization into Wherigo\\kit, but it would be at the cost of people being able to import the cartridges into builders that accept Groundspeak builder cartridges.)

0

Share this post


Link to post

Thanks a lot for the explanation.

I opened the updated WF cartridge in a hex editor and the character is hex 0A. Still looking for how to introduce it in earwigo (or only post edit the .gwz _lua file ... with a hex editor?) 

I'll try to work with that in my cartridge and will let you know the result here.

 

Side note: I always use the localization option of earwigo - and it is one of the many reasons why I like that builder - because in the tiny country of Belgium we already have 3 native languages and on top of that a lot of  international geo-tourists. Building my cartridges only in my mother tongue (Dutch, in fact more exactly Flemish as sometimes even our Dutch brothers think we speak another language :-) ) would limit the number of players of players, especially in tourist heavy areas like my home town Leuven. So yes, for me localization is an important factor. 

0

Share this post


Link to post

When making Earwigo, after a lot of experimenting, I found a cross-platform Lua string that works:

"\060BR\062\010"

That translates to <BR> plus an ASCII line feed.  However, the < and > have to be encoded as escaped decimal numbers to stop the compiler from eating them.

In the Earwigo interactive builder you can just use a line break in a multi-line string box, or (I think; it's a long time since I checked) include "\n" in a single-line string box, and the code that generates the Lua file will handle this correctly.

0

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  
Followers 3