Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

[Sugarcube 2] problem.

Hello!
I'm experiencing a little problem with Twin/Sugarcube, primary related to the <<nobr>> tag.

I'm writing my passages in OpenOffice, formating them in an easily readable structure. And because of this, i'm wrapping them most of the time in <<nobr>> <</nobr>>, to get rid of unneccesary line-breaks.
Unfortunately, suggarcube tends to replace line-breaks with Spaces, sometimes resulting in strange and visible Text-Formatting. This mainly occurs, if i had a list of Entrys (Hyperlinks or <<print>>-tags), wrapped in if-conditions.

In such a case, the first line always has a leading Space, that pushes the text one step to the right. All other entrys, below the first, are lined up correctly, strict to the left side of the page. That looks like, if the first line had a indentation. But this ONLY occurs, on <<tags>> that are replaced by text during the rendering ... such as <<Link>> or <<print>>. Normal Textbodys are strangely not affected and lined up correctly.

Actually, to get rid of this unnessesary blank, i had to delete several line-breaks from the source-code, but this messed up my formatting, making the sourcecode rather unreadable and very confusing.

Is there a work arround for this?
the nobr-passage-tag is not working for me, because i don't want the nobr on all the page. Just on most of it.

Comments

  • Andy1982 wrote: »
    I'm writing my passages in OpenOffice, formating them in an easily readable structure. […]
    PSA: Word processors can easily break code and are not recommended—breakage often comes via typographic character replacements, e.g. replacement of normal double/single quotes with typographic/curly quotes. They may be used, however, care should always be taken when using any non-plain text editor.

    Andy1982 wrote: »
    Unfortunately, suggarcube tends to replace line-breaks with Spaces, sometimes resulting in strange and visible Text-Formatting. […]
    That's simply how the <<nobr>> macro and nobr passage tag currently work. They remove leading/trailing line breaks altogether and replace each remaining contiguous sequence of line breaks with a single space.

    Andy1982 wrote: »
    Is there a work arround for this?
    You may find the line continuation markup useful, as it suppresses line breaks completely.
  • edited October 2016
    That's simply how the <<nobr>> macro and nobr passage tag currently work. They remove leading/trailing line breaks altogether and replace each remaining contiguous sequence of line breaks with a single space.

    Yes, i know. But normaly, twine/sugarcube ignores leading Spaces completely. If i write a link as something like <<link " klick here!">> it will always be displayed as "klick here!" without a single leading space.

    And then, sometimes, if <<nobr>> is supposed to collaps a handwritten <<if>> structure, it suddenly inserts a unneccessary, leading Space, that is not only not wanted, but also very difficult to remove, and twines auto-correction does not remove this. I think, that's kind of strange.
  • edited October 2016
    Neither Twine nor SugarCube, or any story format for that matter, have anything to do with collapsing/ignoring spaces, that's a feature of HTML and your browser.

    You may be seeing spaces you're not expecting because you're doing something to generate line breaks you aren't expecting or you have other invisible characters causing or, at least, preceding the spaces you're seeing, perhaps both.

    I cannot say for sure since you haven't show any examples of problematic code. If you want to give that a shot, use the code tag (C on the editor bar) and copy/paste the code, so we see it exactly as-is, possible invisible characters and all. Alternatively, post/attach a example project which shows the behavior you're seeing—this is actually the better of the two methods.
  • edited October 2016
    Well:

    This snippet of code:
    @<;br>
      <</if>>
    <</nobr>>
    

    is rendered as:
    CampShelter_Name
     CampFireplace_Name
     CampWorkbench_Name
    

    There is no difference, which entry is the first, and which is second, third, fourth ... whatever. So a problem with the contents of each variable can be excluded as the problems cause. The top-entry will always be lined correctly while the following entrys will always be one space to far on the right. No matter, which entry is the top-one.

    I have produced the same failue vice-versa in other passages, with only the first line to far to the right and the following lines correctly lined.
     First entry
    Second entry
    Third entry
    

    But so far this is the easiest and shortest snippet of code i could find to demonstrate the problem.

    Oh yea, just for the info:
    If i rewrite the code on a plain text-editor lieke note-pad, the problem is still existing. So OpenOffice is not the cause, too. ;)



    Oh Boy ... nevermind ...
    Your short paper about HTML and Browsers had directed me to an Idea. Its embarrassing, but the problem is solved ... the miss-allignement is ONLY exsting in Twines Testing-Mode. If the game is played in a real Webbrowser, all is fine.

    Nevertheless ... tank you very much.
  • You seem to have found resolution, however, as a bit of a followup.
    Andy1982 wrote: »
    This snippet of code:
    @<;br>
      <</if>>
    <</nobr>>
    

    is rendered as:
    CampShelter_Name
     CampFireplace_Name
     CampWorkbench_Name
    

    […]

    Oh Boy ... nevermind ...
    Your short paper about HTML and Browsers had directed me to an Idea. Its embarrassing, but the problem is solved ... the miss-allignement is ONLY exsting in Twines Testing-Mode. If the game is played in a real Webbrowser, all is fine.
    I cannot reproduce that behavior. Using Play—or Test with the debug views turned off—within Twine 2.0.11 (Windows executable version), that renders exactly as I'd expect it would—i.e. with all names flush to the left side. For example:
    CampShelter_Name
    CampFireplace_Name
    CampWorkbench_Name
    


    Which version of Twine 2 are you using and is it the executable or browser-based build? If using a browser-based build, which browser was showing the odd behavior when testing from within Twine 2?
  • I'm using the executable in the version 2.0.11 too.
    And sugarcube 2 as v2.10
  • Huh. That's odd. Oh well. :)
Sign In or Register to comment.