[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text
From:       John Hendrikx <jhendrikx () openjdk ! org>
Date:       2023-10-30 19:59:43
Message-ID: E1DDRiRpkdd0zPyUzVTEU-JEXwCAXwVUsJL7wSHD8vI=.dbc8f183-55aa-4a6f-81d7-07838ad23321 () github ! com
[Download RAW message or body]

On Mon, 30 Oct 2023 19:00:08 GMT, Andy Goryachev <angorya@openjdk.org> wrote:

> > There are a number of tickets open related to text rendering:
> > 
> > https://bugs.openjdk.org/browse/JDK-8314215
> > 
> > https://bugs.openjdk.org/browse/JDK-8145496
> > 
> > https://bugs.openjdk.org/browse/JDK-8129014
> > 
> > They have in common that wrapped text is taking the trailing spaces on each \
> > wrapped line into account when calculating where to wrap.  This looks okay for \
> > text that is left aligned (as the spaces will be trailing the lines and generally \
> > aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with \
> > LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  \
> > CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, \
> > but if space reduces further, it will wrap **too** early because the space is \
> > taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, \
> > so the engine wraps it to `AA` + `A  ` or something). 
> > The fix for this is two fold; first the individual lines of text should not \
> > include any trailing spaces into their widths; second, the code that is taking \
> > the trailing space into account when wrapping should ignore all trailing spaces \
> > (currently it is ignoring all but one trailing space).  With these two fixes, the \
> > layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early \
> > wrapping due to a space being taking into account while the actual text still \
> > would have fit (this is annoying in tight layouts, where a line can be wrapped \
> > early even though it looks like it would have fit). 
> > If it were that simple, we'd be done, but there may be another issue here that \
> > needs solving: wrapped aligned TextArea's. 
> > TextArea don't directly support text alignment (via a setTextAlignment method \
> > like Label) but you can change it via CSS. 
> > For Left alignment + wrapping, TextArea will ignore any spaces typed before a \
> > line that was wrapped.  In other words, you can type spaces as much as you want, \
> > and they won't show up and the cursor won't move.  The spaces are all getting \
> > appended to the previous line.  When you cursor through these spaces, the cursor \
> > can be rendered out of the control's bounds.  To illustrate, if you have the text \
> > `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, \
> > typing spaces before `BBB` will not show up.  If you cursor back, the cursor may \
> > be outside the control bounds because so many spaces are trailing `AAA`. 
> > The above behavior has NOT changed, is pretty standard for wrapped text \
> > controls,...
> 
> From https://www.unicode.org/reports/tr14-4/
> 
> 
> 5.6 Break opportunity after characters (A)
> Breaking Spaces
> SPACE (SP) � U+0020
> 
> The space characters are explicit break opportunities, but spaces at the end of a \
> line are not measured for fit. If there is a sequence of space characters, and \
> breaking after any of the space characters would result in the same visible line, \
> the line breaking position after the last space character in the sequence is the \
> locally most optimal one. In other words, since the last character measured for fit \
> is BEFORE the space character, any number of space characters are kept together \
> invisibly on the previous line and the first non-space character starts the next \
> line. 
> It is sometimes convenient to use SP, but not the other breaking spaces to override \
> context based behavior of other characters under the "anywhere, except where \
> prohibited" style of line breaking (context analysis style 2). 
> EN QUAD � U+2000
> EM QUAD � U+2001
> EN SPACE � U+2002
> EM SPACE � U+2003
> THREE-PER-EM SPACE � U+2004
> FOUR-PER-EM SPACE � U+2005
> SIX-PER-EM SPACE � U+2006
> PUNCTUATION SPACE � U+2008
> THIN SPACE � U+2009
> HAIR SPACE � U+200A
> 
> The preceding list of characters all have a specific width, but behave otherwise as \
> breaking spaces . 
> ZERO WIDTH SPACE (ZWSP) � U+200B
> 
> This character does not have width. It is used in a style 2 context analysis to \
> provide additional (invisible) break opportunities. 
> IDEOGRAPHIC SPACE � U+3000
> 
> This character has the width of an ideograph but like ZWSP is fully subject to the \
> style 2 context analysis. 
> 
> A quick check with (the latest?) MS Word 2208 on Windows shows that, at least with \
> EN QUAD U+2000 it is treated as a regular character (i.e. it is always "displayed" \
> even if right aligned).

@andy-goryachev-oracle 

> The space characters are explicit break opportunities, but spaces at the end of a \
> line are not measured for fit. If there is a sequence of space characters, and \
> breaking after any of the space characters would result in the same visible line, \
> the line breaking position after the last space character in the sequence is the \
> locally most optimal one. In other words, since the last character measured for fit \
> is BEFORE the space character, any number of space characters are kept together \
> invisibly on the previous line and the first non-space character starts the next \
> line.

That's certainly a good description of how the breaking should be handled.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-1785940681


[prev in list] [next in list] [prev in thread] [next in thread]