On Oct 25, 2005, at 10:57, Manuel Mall wrote:
Hi Manuel,
I haven't got any technical comments to the issues raised on the Wiki
page. Is this 'too hard' or 'too boring' or 'too messy' or what?
All three, and more :-P
Nah, seriously now, trying to comment in on the thread from last week:
On Oct 19, 2005, at 03:45, Manuel Mall wrote:
On Wed, 19 Oct 2005 05:44 am, Jeremias Maerki wrote:
You place the white-space-treatment after the white-space-collapse
but I think it is clear that the latter comes last ("during area tree
construction" =after line breaking vs. "during line-building and
inline-building" =before line-breaking).
Yes I agree that this is a critical interpretation issue and I
expected
that part of the algorithm to be controversial. The problem is that in
the description of value "true" for the white-space-collapse property
it clearly refers to the fo tree and fo:character siblings in the
tree.
That was further clarified by an e-mail on the xsl editor list
http://lists.w3.org/Archives/Public/xsl-editors/2002OctDec/0004. Once
we have done line-building the fo tree (at fo:character level) is
largely gone, we have now glyph areas which could have been merged,
ligatures combined, etc.. That means referring at this stage back to
fo:character siblings in the fo tree seems lets say unusual.
Correction: the FO tree isn't 'gone' until layout for the page-
sequence is finished. Only at that time are all the FObjs released.
It may seem unusual to refer back to fo:character siblings, but that
doesn't mean it's wrong. The corresponding FObj is still available to
us at that point...
The fact that we are dealing with glyph areas and not fo:character
elements in line-building / area tree construction is further
emphasised by the description of the handling for the
white-space-treatment property. It is all defined in terms of
glyph areas not fo:characters.
Errm... I seem to be missing something, or aren't you talking about
the XSL-FO Rec here?
I can't find any reference to the term 'glyph' or 'glyph area' in the
description of white-space-treatment. Many references to 'character
flow object' and 'XML whitespace' though. (XSL 1.0) The passage about
line-building (4.7.2) indeed talks about glyph areas, but only seems
to mention suppress-at-line-break (a property which, incidentally,
only applies to fo:character objects).
Besides, the question that needs to be posed when handling white-
space-collapse is: "Should this whitespace character generate an area
or not?"
The description in the Rec (XSL 1.0 -- 7.15.12) IMO clearly indicates
that no layout information is needed to answer the above question, as
it depends solely upon the character itself, the preceding and the
following character.
Further to this it doesn't make sense to me to collapse white space
after line breaking as is implied by your interpretation because the
amount of white space does contribute to the line breaking decisions.
If we remove white space after line breaking we would IMO get sub
optimal line breaks. In summary I think white space must be collapsed
before or at least during line breaking but not after.
100% agreed. I wouldn't place it after line breaking either. It seems
like a decision that can (and should?) be made *during* layout:
"Should this whitespace character generate an element or not?"
If it generates an element, it will also --if appropriate-- trigger
the generation of an area.
Another related issue is the description of collapsing white space
around a linefeed in the spec under white-space-collapse. The spec is
very specific and refers to U+000A (linefeed) fo:character siblings in
the fo tree.
No, it talks about 'character flow objects', which makes me wonder...
Are all characters to be considered 'character flow objects' or only
those that were specified using fo:character? Not that it would make
a big difference, I think.
This is obviously very different to removing white space around a line
break generated during line building.
--which is what 'suppress-at-line-break' is meant for.
Also in the default case by the time we get to white-space-collapse
handling all linefeeds would have been replaced by spaces during
refinement. Which leads to the question do they really mean that in
the spec or do they really meant to remove white space around a line
break? But then again that is really dealt with by the white-space-
treatment
property in much more detail.
But why then do we need the duplication of white-space-collapse
removing white space around a linefeed character and
white-space-treatment removing white space (not quite actually - it
removes characters with the suppress-at-line-break property being
true)
around line breaks?
I don't see where white-space-treatment explicitly refers to
generated 'line-breaks'. It only mentions 'linefeeds'.
The right order in which the related properties should be dealt with
seems to be:
1. white-space-treatment (property refinement)
2. linefeed-treatment (property refinement)
3. white-space-collapse (layout/area tree construction)
4. suppress-at-line-break (layout/area tree construction)
Firstly, white-space-treatment doesn't do anything with linefeed
characters. The linefeed character --U+000A-- is explicitly excluded,
whatever value white-space-treatment got. On top of that, the Rec
repeats, for all possible values of white-space-treatment, the little
phrase "before any linefeed-treatment handling is considered".
All in all, this implies that, after white-space-treatment and
linefeed-treatment have been handled, there is *still* the
possibility of whitespace preceding a preserved linefeed, hence the
apparent 'duplication'.
I'll have a closer look at your most recent post ASAP (most likely
tomorrow or the day after).
That's it for now. Hope this already helps a bit... :-/
Cheers,
Andreas
