Andreas,
firstly a great thanks for looking at this.
I am not going to comment on your comments right now but there is
probably an important clarification required: All my interpretations of
the spec with respect to white space handling are based on the 1.1WD
not the 1.0 spec. The WG has already confirmed that the description of
white space handling in 1.0 is flawed and has rewritten that part in
1.1. As I mentioned before I believe their intention was not to change
the behaviour they wanted to achieve between 1.0 and 1.1 but to
document it more correctly. 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 refer
to line breaking vs linefeed, glyph areas vs fo's, etc. below. Which
are some of the items you questioned.
Manuel
On Wed, 26 Oct 2005 06:22 am, Andreas L Delmelle wrote:
> 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
