Skip to content

Discrepancy in leading space rendering of layoutText #19

Closed
jamie-threerings opened this Issue Mar 28, 2013 · 3 comments

3 participants

@jamie-threerings

This is pretty easy to observe in the demo. Choose "Text Test" and click to enter a string with leading and trailing spaces, like " A ". Under java, just the "A" is rendered. Under ios, the " A" is rendered. Is it possible to make this consistent? It's causing problems for me in a styled text renderer in my app.

I'd prefer to include spaces in all rendering since that would allow the best control. Otherwise, I'd need to somehow measure a space and do special extra stuff during laying out each chunk, not pretty.

@roguenet

My only initial problem with the included spacing preference is that typically a user will write bold HTML text as "here is a bunch of text, only some of which is bold." The bolded text in that example needs a little extra space around it than normal text, but the person writing the formatted text isn't going to be thinking about that, and you're going to end up with bold text snuggled up too close to normal text.

@samskivert
Three Rings member

Text layout and rendering is a morass of ill specified and dubiously implemented functionality (on every platform). There's nothing in PlayN's Java layout and rendering code that is stripping off whitespace. So something deep in the bowels of Java is doing it. PlayN can't fix that for you.

@samskivert samskivert closed this Mar 28, 2013
@samskivert
Three Rings member

I take that back. It looks like the code that PlayN uses to work around font rendering discrepancies is causing problems when you have leading whitespace. Yay Java. I'll see what I can do.

@samskivert samskivert reopened this Mar 28, 2013
@samskivert samskivert added a commit that closed this issue Mar 28, 2013
@samskivert samskivert Adjust bounds fiddling to handle text with leading whitespace. Fixes #19
.

We previously eliminated leading whitespace because some fonts stick it in
there just for kicks. But that also eliminated leading whitespace in text like
" foozle". So we just let the leading whitespace lie whether it be intentional
or supplied gratis by the font.

This also improves the adjustment that takes place for fonts that inject
negative leading whitespace. We now compute the maximum negative leading
whitespace for all lines in multiline text and shift everything over by that
maximum rather than shifting each line over by its negative whitespace.
Presumably the fonts are using negative whitespace for some aesthetic purpose
and this does a better job of preserving it, as much as possible.
3fabad5
@nirvanin nirvanin pushed a commit that referenced this issue Jun 18, 2013
@samskivert samskivert Adjust bounds fiddling to handle text with leading whitespace. Fixes #19
.

We previously eliminated leading whitespace because some fonts stick it in
there just for kicks. But that also eliminated leading whitespace in text like
" foozle". So we just let the leading whitespace lie whether it be intentional
or supplied gratis by the font.

This also improves the adjustment that takes place for fonts that inject
negative leading whitespace. We now compute the maximum negative leading
whitespace for all lines in multiline text and shift everything over by that
maximum rather than shifting each line over by its negative whitespace.
Presumably the fonts are using negative whitespace for some aesthetic purpose
and this does a better job of preserving it, as much as possible.
479dbe5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.