On Nov 3, 2005, at 08:53, Manuel Mall wrote:

On Thu, 3 Nov 2005 06:03 am, J.Pietschmann wrote:

Computing line breaking opportunities and discarding whitespace at
the end (or beginning) of a line are different matters. If whitespace
has to be retained, trailing spaces after a non-space string may
simply mean the previous line breaking opportunity has to be used,
because otherwise the string including the trailing spaces will
overflow the line area. The trailing whitespace may also influence
text justification.

Hmm, to me it appears that UNICODE and XSL-FO have slightly different
models when it comes to white space in the context of line breaking
which is causing the discussion here. In UNICODE everything is based
simply on the properties of the codepoint in question and its
neighbour. In XSL-FO one can change the behaviour of a codepoint by
setting those white space related XSL-FO properties.

Hmm, apart from suppress-at-line-break (which is a more general property, not specific wrt whitespace), the whitespace-related properties only deal with XML whitespace (which is obviously not the same as Unicode whitespace, but a very small subset thereof).

During refinement, all whitespace other than U+0020, U+0009, U+000D and U+000A is left alone. At that stage, it's only these four codepoints' behavior that can be influenced/changed by the three properties: white-space-treatment, linefeed-treatment and white-space-collapse. This means that a sequence of nbsp-space-zwsp-space-nbsp should arrive in layout untouched (never collapsed).

As Joerg points out, discarding whitespace at line-breaks and computing those line-breaks are two different issues. If I get the intention correctly, we shouldn't be following Unicode UAX#14 wherever it mentions white-space-removal/-retaining around eventual breaks except for non-XML-whitespace (as we implement a Recommendation that, at least from our POV, supersedes what Unicode says about this). We're using UAX#14 only to determine the feasible/ most desirable (non-)breaks.

If UAX#14 always breaks at the end of a sequence of spaces, then this tells us only that doing so would use the most desirable break- opportunity. If anything, it seems to make the job less complicated, because this means that we will practically never have to consider cases of whitespace following a line-break, no? Only in case of explicit linefeed-treatment="preserve"... Correct me if I'm wrong, but such a space sequence would correspond to a Knuth element sequence with the break-before penalty gradually increasing and the break-after penalty decreasing for each consecutive space, such that, when the decision has to be made where to break, the break-after for the last space will be chosen if possible. A break before a space is feasible, but not preferable to breaking after it, breaking after the first space should be marked less preferable than breaking after the last one. What happens with immediately preceding XML whitespace (or explicit fo:characters with overrides for default suppress-at-line-break), is then again determined by the white-space-treatment of the containing block. In this respect, the default rules are pretty simple: all glyph areas (or non-areas, which could still be relevant to possible FO extensions) for whitespace characters are retained, except regular spaces, or fo:characters with explicit "suppress".

That is not a concept within UNICODE. If you want to retain white space in UNICODE you use a different codepoint. If you want to retain a space in XSL-FO you could use a different codepoint but more likely you set a
XSL-FO property if you want this applied widely in your document.

If we want to 'marry' UNICODE linebreaking with XSL-FO white space
handling we have this interaction to consider. One possible solution
would be to replace spaces (U+0020) by different codepoints which
resemble the behaviour modification imposed by any XSL-FO white space
handling properties in effect.

Not really 'replace' but 'treat-as-if' (generate a Knuth sequence analogous to codepoint ...)

But I am not sure if this can be done in
all cases. Otherwise we may have to modify the UNICODE line breaking
algorithm to cater for the XSL-FO white space specialities.

Hm. Same as Joerg, I also see these two operate at different levels. Don't know if I'm seeing this correctly, but the line breaking algorithm operates at the level where we have to decide the value of the penalties for breaking before or after a particular type of whitespace (or non-whitespace), whereas the white-space treatment refers to line-building, so what happens/has to happen in case the break is 'elected'.



Reply via email to