On Oct 26, 2005, at 18:00, Andreas L Delmelle wrote:
On Oct 26, 2005, at 03:16, Manuel Mall wrote:
Therefore I think it is correct and
advisable to refer to 1.1 in this case. Could you please review your
comments under this aspect as I believe that would clarify why I
to line breaking vs linefeed, glyph areas vs fo's, etc. below. Which
are some of the items you questioned.
Will most certainly do so. I only very briefly looked at the 1.1 WD
so far, so it could indeed be that I'm missing quite a few
FWIW: I have already taken a quick look at white-space-treatment, and
this definition indeed differs very much between the two versions. In
1.0 white-space-treatment was much more straightforward, and dealt
only with XML whitespace characters (no reference to glyph-areas
yet). IMHO, currently the 1.1 WD is making matters more complex than
they should be by dragging in the concepts of 'glyph-areas' and 'line-
breaks', two things that become apparent much further downstream...
Moreover it seems like a Big Mistake to define a value 'ignore-if-
after-linefeed' and then clarify the effects of that value by
referring to 'line-breaks'. I'd advise the editors to either return
to the definition of the 1.0 Rec, or rename the value 'ignore-if-
after-line-break'. As it stands now, it seems like white-space-
treatment should be handled before linefeed-treatment, but then again
it should be handled after...
*sigh* What a friggin' mess! :-)
Why does this property all of a sudden refer to 'suppress-at-line-
break'? The distinction between the two properties in 1.0 was
precisely that white-space-treatment could be handled totally
independently from any layout process (in the FO tree itself, solely
by looking at sibling characters).
The linefeed-treatment and white-space-collapse properties OTOH,
don't change at all.
Have you received any response yet to the questions concerning white-
space handling you directed to the editors? If not, I'd strongly
advise to await their reply before using the current WD definition of
white-space-treatment as a basis. It's just still too much of a
'draft' ATM. Maybe the definition could be separated in two parts:
one part that can be handled in the same way the 1.0 Rec defines it
(the very first step in white-space handling referring only to
characters), and a second pass that is explicitly handled when
actually performing line- or inline-building.
I'll be back tomorrow with that comment on your examples I promised.