text changes

Dear Editors:

This post concerns linefeed-treatment, white-space-treatment,
white-space-collapse, and text-transform. First, I apologize for even
bringing it up, as I see that a lot of effort has been expended to get it
where it is, but I think another (hopefully easy) round of work on it will
yield some improvements. All references below are to the XSL-FO 1.1
Recommendation.

1. [Editorial] Section 1.1.2, paragraph 9, which begins "The second phase in
formatting is to refine ..." enumerates five items, the fourth of which
includes white-space-treatment as a part of the refinement process, which I
think is no longer correct. This is minor but potentially confusing.

2. [Editorial, I think] Section 7.16.12, next-to-last paragraph, which
begins "The 'white-space-collapse' property ..." is, I think, quite
misleading and potentially confusing. It seems to make unstated assumptions
about the values of the white-space-collapse and white-space-treatment
properties, assuming in both cases that the "initial" values are used. It
might be more clear to simply say that the order of application is 1)
linefeed-treatment (during refinement), 2) white-space-collapse (during area
tree construction), and 3) white-space-treatment (during area tree
construction, after white-space-collapse has been applied).

3. [Editorial] Section 7.16.12 seems to be the place where the precedence of
these three properties is most clearly addressed. I recommend referencing
this section from 7.16.8 (white-space-treatment), so that the precedence is
available from both properties.

--------

The remaining items are a result of my interest in the aXSL FoTree
interfaces (http://www.axsl.org/fo/) which provide an API to a refined FO
Tree, so they may reflect more pickiness about where the line between
refinement and area tree construction lies than is normal. One of the design
goals of the API is to push as much processing as possible (and no more)
upstream out of area tree construction and into the refinement. I suppose
that a similar principle exists in where that line is drawn within the
Recommendation.

4. [Substantive] Since white-space-collapse precedes white-space-treatment,
and since white-space-collapse (as far as I can tell) can be entirely and
completely processed in the FO Tree, with no knowledge of the Area Tree or
layout, I recommend that consideration be given to making the application of
white-space-collapse a part of the refinement step instead of a part of the
area tree construction. If I am wrong about this, and white-space-collapse
processing must be deferred until area tree construction, it is not all
clear why this should be, and an explanation in the documentation is
probably warranted. In other words, I don't know what the difference between
"shall be discarded during the refinement process" (7.16.7) and "shall not
generate an area" (7.16.12) might be.

If this recommendation were followed, the documentation recommendations in
#1, #2 and #3 above should also change. With regard to #3, any confusion
about precedence would then be between linefeed-treatment and
white-space-collapse, those steps being done during refinement.

5. [Substantive] If and only if #4 were adopted, a similar change should be
considered for the "ignore" value of white-space-treatment. This would leave
the before-and-after-linefeed issues as the only items that need to be
handled in the area tree construction. This has the drawback of being
marginally confusing by splitting the processing of this property between
the two tasks, which I suppose is why it is documented the way it is.

6. [Substantive] I don't think it is possible to handle text-transform as
part of the refinement step when it is being applied through the
initial-property-set object. I recommend that, at least for this one case,
documentation be changed at 5.7.1 and 7.17.6 to reflect that this must be
performed as part of the area tree construction. Perhaps it is cleaner to
say that this is true in all cases for this property.

-----

Thank you in advance for your consideration of these matters.

Victor Mote
The FOray Project (www.foray.org)

Received on Friday, 24 August 2007 12:31:15 UTC