Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
SugarCube print acting weird
Whenever I use the <<print>> macro in SugarCube (1) it seems to print the answer a shade lighter than the rest of the text. This is rather annoying for formatting.
E.g.
Variable: <<print $variable>>%
In that, the result of the print will be a lighter shade of colour than the %. What's causing this?
To see it clearly, have a variable set to 1 and write something like:
<<print $variable>> 1
The two 1s will be different colours. At least in my story.
E.g.
Variable: <<print $variable>>%
In that, the result of the print will be a lighter shade of colour than the %. What's causing this?
To see it clearly, have a variable set to 1 and write something like:
<<print $variable>> 1
The two 1s will be different colours. At least in my story.
Comments
There are notable differences between them:
- The <<print>> macro evaluates the expression passed to it, wikifies the final result, and appends that to the render buffer as-is.
- The naked $variable formatter appends the $variable's value to the render buffer as-is.
If you're simply printing the value of a $variable, then the only way you should possibly see a difference between them would be when using <<print>> on a value that contains markup (TiddlyWiki or HTML).Suggestions:
You should already know this, however, you can inspect the generated DOM via your browser of choice's developer tools to ensure that nothing is wrapping the value, save whatever you (or some code you're using) might have put there.
Try putting a naked $variable equivalent on the next line to see if you get the same result. For example:
Correct, there is not. Beyond that, there cannot be, for a few important reasons:
- You cannot select non-element nodes via CSS. The initial "1" is a text node (well, both are, but we're only interested in the initial one here).
- Text nodes do not contain styling properties, and thus cannot be styled, even if you could select them somehow.
Any styling of text nodes comes from, and must be applied to, ancestor element nodes.This is because it only happens if the <<print>> is followed by another character.
So <<print $variable>>% leads to the $variable display being light. However, simply writing 1% leads to it being normal colour. And <<print>> on its own is also normal.
I will send you a screenshot so you can see I'm not going mad.
Also I cannot use naked variables as I need to use that "%" directly after the print, so cannot have it merged with the variable.
In the area I have this shown, I am displaying these characters in black text on a black background with the following text shadow to create a white glow to illuminate them:
What I am guessing is happening is that somehow, the glow from the neighbouring % sign is overlapping the printed variable and appearing on top of it, instead of undearneath it.
That is exactly what it visually looks like.
The easiest way to fix this would be to incorporate the % into the variable, somehow, so there is no adjacent other type of text, but I am not entirely sure how to write that. Having a brain fart right now.
E.g. the variable needs to show somewhere between 1% and 100%, and dynamically update. I know how to do that with normal numbers, like 1, 2, 3 etc, but not sure if including the % in the variable numbers will break it?
Is that a bad thing to use?
<<print $lucidity + "%">>
fixed it. Now the % is contained in the print expression so its text shadow does not cause overlap.
EDIT: Though I suppose I should update my SugarCube version... the one I am using doesn't seem to support naked variables. Maybe that would have fixed it too.
TL;DR: The following works as expected:
So your browser is going mad (i.e. you've found a browser bug, congratulations; at least, I'd hope that would be considered a bug). Have you tried this in other browsers to see what happens there? Not that I'm suggesting you don't work-around the issue, I'm just curious how widespread this issue is.
It sounds like it's happening because the numeral and the percent sign are in different text nodes, so the easy work-around should be to conjoin them (which you've already thought of and done).
Unfortunately not, if I'm correct about why (adjacent text nodes), since the $varaible's value and the percent sign would be processed separately, again resulting in two text nodes. The work-around you found is the correct one.
This is in Opera. I'll try other browsers.
Also, I just setup a test case and I cannot replicate your issue in any browser using the CSS you provided, so it seems that the issue is more complicated than simply that. In other words, the cause doesn't seem to simply be the CSS you've shown here plus the separate text nodes, but something else as well. As a guess, it's probably a combination of CSS that's causing it, though what that would be I have no clue.
The main culprit is the font choice for that specific text: http://www.identifont.com/show?FES
It does some pretty odd things with the text shadows.
I cannot replicate the bug with a less-insane looking font.
Out of Opera, Chrome, IE and Firefox, only IE is immune to the bug with this specific font. Luckily my game will be nodejs only so I won't need to worry about such concerns.