XSL FO WD of Oct 18

Dear XSL authors,

I have accumulated some comments/questions re the last XSL draft; I hope they
will be helpful to you.

1. In this draft like in previous ones, there is still no way to scale, rotate,
or size background images! It's an old issue: I raised it in my letter to
xsl-editors of Jan 13, 2000. Please trust me: this makes part of  basic
functionality for background images. In my opinion, we definitely need this
issue to be resolved in XSL 1.0.

2. Let's consider a quote from 5.1.4. "Inheritance":

"The inheritable properties are propagated down the formatting object tree from
a parent to each child. (These properties are given their initial value at the
root of the result tree.) For a given inheritable property, if that property is
present on a child, then that value of the property is used for that child (and
its descendants until explicitly re-set in a lower descendant); otherwise, the
specified value of that property on the child is the computed value of that
property on the parent formatting object."

This raises another old issue: what about inherited features on
fo:footnote-body/fo:float? From the above, I should conclude that footnote body
inherits font properties, color, indents, etc. from the point in the text where
the footnote reference is inserted. We at RenderX tried to implement such a
solution; this turned out to be a real mess, because one needed to redefine all
inherited properties explicitly at every fo:footnote-body (otherwise, you get
footnotes with keep-together="always" from titles, indented footnotes from
lists, etc.). Therefore, for practical reasons, we have interrupted the
inheritance at this point: fo:footnote-body inherits properties directly from
its ancestor fo:flow, and so does fo:float. Are we wrong?

3. Reference-orientation property rotates only the content rectangle of the
affected area: therefore, space/border/padding side orientations for
areas/blocks that host a reference-orientation property remain the same
regadless of the rotation value. But what about backgrounds? I can deduce from
the definition of 'background-position-horizontal' and
'background-position-vertical' that reference orientations for background are
the same as for the padding rectangle. But I am not sure: it would mean that
background-image orientation is rotated with respect to the text it underlines.

It would be nice to include an explicit list into the specification, stating
which properties are rotated along with the content-rectangle and which are not.

4. When line-stacking-strategy equals "line-height": how are conditional
half-leadings before/after the block calculated? I.e. if you specify
line-height.conditionality="discard", what is to be discarded? Our current
solution is to discard the least of half-leadings encountered in the first/last
line. More clarification would be greatly appreciated.

5. In 6.4.12 "fo:simple-page-master", I read:

"Trait Derivation:
In version 1.0 of this recommendation, borders and padding are not allowed with
a page-reference-area. The remaining traits on the page-reference-area are set
according to normal rules for determining the values of traits."

My interpretation: background is (finally) allowed on page-areas! But there are
no respective properties in the property list: am I wrong with my assumptions?

6. In 6.4.14. "fo:region-before" and other side regions, I see a phrase that
puzzles and frightens me:

"Areas:
...
In version 1.0 of this recommendation, the values of the padding and
border-width traits must be "0"."

Why this? Does it mean that padding/borders are no more legal on headers and
footers? In the previous drafts, only margins were banned.

Nowadays, I use padding on fo:region-after to provide a uniform alignment with
fo:region-body, like this:

<fo:simple-page-master master-name="page">
  <fo:region-body  margin="1in"
                   padding="6pt 0pt"/>
  <fo:region-after extent="1in"
                   display-align="after"
                   padding="6pt 1in"/>
</fo:simple-page-master>

In this way, I can always ensure that side edges of content-rectangles of
xsl-region-before and xsl-region-after are always aligned with respect to each
other, so that I need not bother to provide additional indents in the
fo:static-content. Are you going to forbid such usage?

7. Re conditionality on borders and padding: if you have enabled this (very
useful) feature to control appearance of borders on page breaks, why haven't you
permitted this on line breaks? Currently, there is no possibility to toggle
padding/border when an inline-area with a border is broken by a linefeed. The
most straightforward way of achieving this would consist in giving the value
type of <length-conditional> to border-start-width / border-end-width /
padding-start / padding-end (parallel to border-before / padding-before).
Personally, I think that all border-*-widths and all padding-* could be made
conditional - even absolutely oriented ones (like padding-top or border-bottom);
this would  yield the spec more uniform.

8. URI-reference now requires a function-like url() wrapper around all URIs. May
I ask you why did you drop the initial approach where naked URIs were also
permitted in attributes? From the implementor's point of view, the only point
where url() notation is really required is inside the 'background' shorthand
property. In all other places, this notation bears no semantics. Have you any
other reasons? I wonder if it makes sense to spoil the spec with an extra
unmotivated element, just for the sake of compatibility to one CSS2 shorthand. I
think it would be better to require this inside the shorthand only, and leave
naked URLs in normal XSL attributes like 'src' or 'external-destination'.

9. Are multiple fo:flows permitted now? The spec is inconsistent:

- on one hand, there is the content model for page-sequence that includes only
one instance of fo:flow. Moreover, auxiliary regions like
"xsl-before-float-separator" or "xsl-footnote-separator" cannot get custom
names - a strong evidence that multiple flows in a page sequence are not
permitted;

- on the other hand, the text in 6.4.1.4 "Flows and Flow Mapping" presumes
multiple flows. Moreover, fo:flow and fo:region-body can have
flow-name/region-name properties that would be useless if only one flow may be
contained in the page sequence.

Which of the two interpretations is true? If there's only one flow for XSL 1.0,
then you should better cancel the flow-name attribute on fo:flow, giving it some
default name. In this case, I think the best solution would be to cancel
region-name on fo:region-body also, hardwiring fo:flow to region-body.

If, however, your intent was to enable multiple flows, then:

- the content model for fo:page-sequence should be changed;

- static-contents for subregions should be linked to instances of fo:flows, not
to page-sequence. E.g. one could add a special element inside fo:flow - let's
call it fo:conditional-static-content. It would host the same data that are now
placed in static-contents for conditional subregions.

<!ELEMENT fo:flow (fo:conditional-static-content*, (%block;)+ )>
.....

<!ELEMENT fo:conditional-static-content (%block;)+>
<!ATTLIST fo:conditional-static-content
   flow-name ( xsl-before-float-separator
             | xsl-footnote-separator) #REQUIRED
.....


10. A small issue concerns the definition of a pixel:

5.9.13.1. "Pixels" contains the following quote:

"... for print, desktop computer monitors, and hand-held devices viewed at
normal viewing distances this is assumed to be 0.28mm..."

To justify this, a reference is made to CSS2 spec. But in CSS2, one pixel for
print is somewhat different:

[CSS2, 4.3.2 "Lengths"] "When printed on a laser printer, meant for reading at a
little less than arm's length (55 cm, 21 inches), 1px is about 0.21 mm".

This has direct implications on how to size GIFs in a renderer.

11. Why does the initial value of the 'format' property include a dot? In XSLT,
it has no dots - just "1".

12. A collection of typos:

- fo:simple-link cited in a note inside 6.9.2 "fo:basic-link";

- 'space-together' (;-)) property appears in 5.11. "Property Datatypes";

- 'display-align' and 'text-align' properties are duplicated in the property
list in 6.6.5 "fo:external-graphic";

- 6.7.5 "fo:table-caption" contains the following line twice:

   "keep-with-next" property with value "0".

Keep-with-next is a compound property; moreover, value of "0" have no clear
semantics. Probably, it should read 'keep-with-next.within-column'="always". As
for the second occurrence, there should be 'keep-with-previous' instead of
'keep-with-next'.

- typo in 7.4.1. "absolute-position"- the last line reads:

  absolute-positon="auto" specified.

In the previous draft, it was absolute-posiiton ;-).

- 7.13.7. "linefeed-treatment": "treat-as-zero-width-space" is described but not
listed in the value list;

- 7.13.8. "space-treatment": ignore-if-*-linefeed are described but not included
in the value list.


Best regards,
Nikolai Grigoriev

RenderX

Received on Sunday, 22 October 2000 16:29:38 UTC