FWD: Re: New XSL working draft published

>From: "Nikolai Grigoriev" <grig@iitp.ru>
>To: <xsl-editors@w3.org>
>Cc: "XSL List" <xsl-list@mulberrytech.com>
>Subject: Re: New XSL working draft published
>Date: Thu, 13 Jan 2000 16:37:59 +0300
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook Express 4.72.3110.5
>X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
>X-Recipient: xsl-editors@w3.org
>Sender: owner-xsl-list@mulberrytech.com
>Reply-To: xsl-list@mulberrytech.com
>
>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
>
>
>
>
>
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>

-----------------------------------------------------------------------------
This e-mail reflects the personal opinion of the author.
 -- Unless explicitly so stated in the text, it does not represent an
    official position of Adobe Systems, Inc.
 -- Unless explicitly so stated in the text, it does not represent an
    official opinion of the W3C XSL Working group.
-----------------------------------------------------------------------------
  Stephen Deach                            |  Sr Computer Scientist
  408-536-6521 (office)                    |  Adobe Systems Inc.
  408-537-4214 (fax)                       |  Mail Stop W15-424
  sdeach@adobe.com (no advertizing)        |  345 Park Ave
                                           |  San Jose, CA 95110-2704
                                           |  USA
----------------------------------------------------------------------------
-

Received on Thursday, 13 January 2000 11:59:11 UTC