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
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.
You may find the line continuation markup useful, as it suppresses line breaks completely.
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.
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.
This snippet of code:
is rendered as:
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.
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.
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:
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?
And sugarcube 2 as v2.10