Re: New XSL working draft published

Dear Sirs,

these are some comments arisen while reading the new XSL Format
working draft. Hope they will be of some help. I post a copy of this
to XSL-List, too.


I. FUNCTIONALITY STILL LACKING FROM THE NEW DRAFT

Some useful functionality has been added to the new draft:
better control over page-sequences, leaders, instream graphics,
fine-grained control over whitespace treatment. But nevertheless,
several basic typography features are still lacking:

- running headers;
- drop and raised caps;
- kerning control;
- background image scaling;

and more. Moreover, in some points you have removed the
functionality already existing - e.g. vertical align of
list-item-label with respect to list-item-body.


II. ISSUES REMAINED FROM THE PREVIOUS VERSION

I have prepared a list of issues already present in the April 1999
version that have not been resolved in these nine months. Most of
these were extensively discussed in the XSL list; so you have had
some reasons to leave them as they were. May I know these reasons?

1. If there are correspondences for borders, padding,
and margins, why there are no correspondences for spaces
and indents? 'Space-top' sounds equally good...

2. [5.3.2 - 5.3.3] Margins are said to correspond to indents and
spaces. But spaces are composite, and margins/indents are monolythic.
Does it imply that, whenever there is a margin or indent explicitly
set, than

  space-X.minimum == space-X.optimum == space-X.maximum;
  space-X.conditionality="false";
  space-X.precedence="force"?

Can you please specify this in more detail?

3. My experience teaches that space-before.optimum is lengthy and
anti-intuitive. Everybody writing his first XSL stylesheet, writes
something like space-before="6pt"; I haven't seen any exception.
What about permitting this as a shortcut? It may have the following
meaning:

  space-before="6pt" =>
     .minimum = .optimum = .maximum = "6pt";
  space-before="6pt 12pt" =>
     .minimum = 6pt; .maximum = "12pt";
  space-before="6pt 12pt 18pt" =>
     .minimum = 6pt; .optimum = "12pt"; .maximum = "18pt";

or something like this. Trust me, this would be of great help.

4. fo:static-content: still no way to specify different static
contents for different page masters. What about just adding
"page-master" property to it? This was proposed by James Tauber
and discussed widely in XSL List (and accepted enthusiastically).

5. fo:external-graphic, fo:character, fo:inline-container: does it
really make sense to have an 'inhibit-line-breaks' property there?

6. fo:float: the prose says that floating is always to the top
(=before), while the 'float' property states only lateral floating.
The whole part seems underdeveloped, exactly as it was in the previous
draft; are there any real problems with them?

7. fo:list-block: so, you insist that indents for item-label
and item-body be calculated this strange way, from the surrounding
page-level... Let me repeat some reasons against your solution.

  7.1. Norm Walsh wrote in XSL Requirements Summary: "Support for
       easy construction of a wide variety of types of lists.
       (Easy things should be easy)". I expected that

       <fo:list-block>
         <fo:list-item>
           <fo:list-item-label>
             <fo:block>1. </fo:block>
           </fo:list-item-label>
           <fo:list-item-body>
             <fo:block>First Item </fo:block>
           </fo:list-item-body>
         </fo:list-item>
       </fo:list-block>

       is a correct list-block. Nope, this is wrong now.

  7.2. Implementing lists correctly now requires implementing
       a portion of expression functionality. I thought that lists
       were more basic than expressions, and there should be a
       possibility for a (partially conformant) processor to
       implement lists first, and expressions further, without
       breaching the specs.

  7.3. To put an indented note into a list-item-body, and have it
       be indented from the left edge of the surrounding text,
       I need to specify the indents as follows:

       <fo:block start-indent="inherited-value()+0.25in">
          Note: ...
       </fo:block>

       Do you find it intuitive? I am also worrying about the need
       to implement arithmetics before releasing conformant lists,
       though this is less important.

8. fo:footnote-citation: An editor's note states that this element
will be removed. If you have decided to remove it, please do so,
and let us know the final decision. In the current shape of the
spec, there is absolutely no clarity about the footnotes. There
is no fo:footnote-citation in the Appendix B.6. Instead, I see
a fo:footnote-body. It's really a pity that you haven't chosen
the latter solution.

I repeat the problem with footnotes as they are designed today:
inline properties should be inherited by the <fo:footnote-citation>
from the surrounding text; but its parent <fo:footnote> can hardly
inherit anything from where it stays. So, <fo:footnote-citation>
inherits features directly from its grandparent; a real mess.

9. There is still no way to specify the dimension of a
background-image; why? I understand that this was of no importance
in HTML and, consequently, in CSS2; but it does matter while rendering
FO to printed media.

10. The greatest delusion: vertical-align is still alive??? Haven't
you promised to split up this property??? I repeat what is wrong
with it: the property is used to specify at least 2 different types
of alignment - the contents of an inline element or an
area-container (table-cell or region). These traits have different
value sets (no 'baseline'/'sub'/'super' for regions) and even different
defaults ('baseline' vs 'top').

(The merged traits were three in the previous version; you have dropped
vertical alignment from lists, sacrifying the functionality).

I am more than sure that you know all this by heart. I therefore
conclude that CSS2 compatibility is more important than consistency
of the draft itself. If so, I'm desperate.


III. QUESTIONS/OBSERVATIONS ABOUT NEW FEATURES

1. [4.2.1 Area types]
Is there any real need to define a glyph-area? I wonder if you can
consistently describe kerning in terms of glyph-areas. Suppose you
have adjacent L and T glyphs, placed so that their character boxes
overlap by effect of kerning; what would be their z-order? And what
about ligatures? Won't it be more consistent with the current practice
to treat text chunks as minimal area units? (See also an issue note
in 6.1.1 (single-area-from-multiple-FOs)).

2. [4.2.9 Glyph areas]

>"...its ascent and descent should depend only on the font-name,
>font-size, and font-weight properties of its generating formatting
>object, and is not based on the individual glyph rendered."

What does it mean?
  2.1. What about font-style, font-stretch?
  2.2. How does this agree with the maximum-line-rectangle calculation?
       I presumed that the maximum-line-rectangle height was equal
       to the maximum-descent+maximum-ascent of all the glyphs really
       present on the line; was I wrong?


3. fo:bidi-override: why do you need it? Why could not we add a
'direction' property to the <fo:inline>?

4. fo:initial-property-set - IMHO, fo:first-line-marker was more clear.

5. fo:instream-graphic: introducing this, you make impossible to
validate an FO document using a DTD ;-(. But, in the depth of my
heart, I agree such an element is necessary. Maybe it is possible
to limit the accepted graphic formats to SVG, so that I may include
SVG DTD into FO one? I wonder if anyone plans to create an EPS file
by a stylesheet - this would cause an XML parser to choke, sure ;-).

6. A new property value, "inherit", can now be applied to
non-inheritable properties. Inherit from where? 'Table-layout'
can be specified on tables only; does it mean that
table-layout="inherit" is only applicable to nested tables?
Or, alternatively, does it imply that _any_ property may be specified
_anywhere_ in the result tree? No more distinction between
inheritable and non-inheritable? Anarchy??


IV. TECH NOTES & PROOFREADING

1. (Technical): what about making self-references in your HTML
file local? Currently, all hrefs from the table of contents are absolute
(prefixed with the full site name); therefore, when I save a local copy
of the spec and try to navigate through it, it starts reloading the
document from its original location.

2. (Technical): could you please publish the XML version
of the spec (if any)?

3. (Editorial): Are simple-links and multiswitches really related
to each other? There is no place for simple-link on the diagram
in 6.9.1, and this is understandable. Won't it be more natural
to separate links and multi-state stuff?

4. [4.2.3. Geometric definitions], image with mixed writing mode
content: in the traditional Japanese writing mode, the full stop
(hollow circle,"maru") should be written in the top-right corner of
the character box.

5. table-omit-header-at-break: called table-omit-middle-header-at-break
in the text of 7.12.8. Same for table-omit-footer-at-break in 7.12.9.

6. white-space-collapse written as whitespace-collapse (extra hyphen)
in 7.19.45.


Yours sincerely,
Nikolai Grigoriev

RenderX

Received on Thursday, 13 January 2000 08:39:02 UTC