Comments on 2nd WD (part 11)

Editors:

More comments on the XSL 1.1 2WD:

101.  Section 6.3, Formatting Object Summary for
page-number-citation-last, and 6.6.12,
fo:page-number-citation-last description (two places):
 "consistent" is misspelled: "...has an area-class
that is [consistent] with the specified
page-citation-strategy."


102.  Section 6.4.12,
fo:conditional-page-master-reference, Constraints
section.  Consider rewriting:

"Since the properties from which these traits are
derived are not inherited and the initial value of all
the properties makes the corresponding sub-condition
true, this really means that the subset of traits that
are derived from properties with specified values must
make the corresponding sub-condition true."

to 

"However, since the properties from which these traits
are derived are not inherited and the initial value of
all the properties makes the corresponding
sub-condition true, only the subset of traits that are
derived from properties with specified values must
have their corresponding sub-condition be true."


103.  Section 6.4.13, fo:simple-page-master, recommend
making the intention to create an fo:page-master less
definite--it doesn't seem correct for one
Recommendation to authoritatively declare what a
future one will have.  

"Future versions of this Recommendation will support
more complex page layouts constructed using the
fo:page-master formatting object."

to 

"Future versions of this Recommendation -->may<--
support more complex page layouts constructed using
-->an<-- fo:page-master formatting object."


104.  (Global) About 20% of indefinite references to
fo:xxxx are using "a fo:xxxx", the other 80% use the
more correct "an fo:xxxx".  You may wish to search and
replace "a fo:" to "an fo:" document-wide.


105.  Section 6.4.13, fo:simple-page-master, Areas
Returned section.  There is stray text here (not
present in the 1.0 Recommendation) that is incorrect
and/or not relevant for this section.  It appears that
it should be all removed:

"The "writing-mode" of the page is used to determine
the placement of the five regions on the master. The
writing mode "writing-mode" of the fo:region-body
defines the column-progression within the region. The
inline-progression-direction is used to determine the
stacking direction for columns (and the default flow
order of text from column-to-column)."

1st sentence--the "writing-mode" is actually *not*
used to determine the placement of the five regions,
it is used to define the direction of the text within
those regions.

2nd sentence--it should be "The *property*
"writing-mode"..., but it appears this text belongs in
the fo:region-body description, not here with
fo:simple-page-master.

3rd sentence is correct, but also appears better
suited for fo:region-body description, especially
since the previous paragraph already tells the reader
to go to the various region sections to learn about
their layout.


106.  Section 6.4.13, fo:simple-page-master,
Constraints section:  The following sentence appears
incorrect:

"The traits derived from the margin properties
determine the size and position of the
content-rectangle of the page-viewport-area."

As the graphic just below it shows, it is the
page-height and page-width properties that determine
the content-rectangle of the page-viewport-area.


107.  Section 6.4.13, fo:simple-page-master,
Constraints section:  The second sentence below
appears incorrect:

"The traits derived from the "margin-top",
"margin-bottom", "margin-left" and "margin-right"
properties are used to indent the page-reference-area
content-rectangle from the corresponding edge of the
content-rectangle of the page-viewport-area. Here
"top", "bottom", "left" and "right" are determined by
the computed values of the "page-height" and
"page-width" properties."


Reason: margin-top/bottom/left/right are already
absolute (not relative) directions, so they don't need
to be determined by the computed values of the
page-height and page-width properties.  Further, even
*if* these properties were named
margin-before/after/start/end, the computed values of
page-height and page-width would not give any
indication what the absolute values would be.


108.  Section 6.4.13, fo:simple-page-master,
Constraints section.  Recommend minor changes here:

"The format, letter-value, grouping-separator,
grouping-size, country, and language traits are used
to format the number into a string form, as specified
in XSLT, section 7.7.1. This formatted number is used
by the fo:page-number flow object."

to

"The format, letter-value, grouping-separator,
grouping-size, country, and language traits are used
to format the number into a string form, as specified
in -->XSLT (hyperlink to normative references at
bottom of document)<--, section 7.7.1. This formatted
number is used by the fo:page-number -->formatting<--
object."


109.  Section 6.4.14, fo:region-body, Common Usage,
first Note:  Recommend to remove the following
sentence:

"These region-reference-areas are all area descendants
of page-areas for which the page-master included an
fo:region-body."

Reason:  It's not adding to the point of the
paragraph, also all page-masters have an
fo:region-body.


110.  Section 6.4.14, fo:region-body, Areas returned
section.  As far as I can tell, the WD remains silent
on the issue of column-balancing (where more than one
column is specified for the fo:region-body, and there
is not enough text to fill up all of its
columns/normal-flow-reference-areas.)  While there may
be reasons to not mandate a particular implementation
at this time, being silent *about* being silent on a
relatively important topic appears suboptimal.

The main question to be answered on this topic is: 
Under what circumstances do we balance the columns (or
not balance them)?  I think the general consensus has
been to balance the columns if there is a subsequent
fo:block with span="all", and not balance otherwise.  

The WD already states "The block-progression-dimension
of the normal-flow-reference-areas is the same as that
of the parent span-reference-area."  However, this is
somewhat of a non-answer with respect to column
balancing--one can have empty normal-flow reference
areas with the same bpd as its filled siblings, so it
is not giving us needed information one way or the
other on this issue.

Column-balancing has apparently been in demand for a
long time[1].  While the Editors may not have a
position on it for 1.1, I think it would be good to
have a non-normative note in this section stating
that.  (Alternatively, in such a note it may be good
to give what an implementation may be well-advised to
implement.)  Overall, though, column balancing appears
too important to not be mentioned in this
section--even a decision to *not* mandate a particular
method should still be explicitly stated.

[1]
http://www.w3.org/TR/1998/WD-XSLReq-19980511#AEN204

Regards,
Glen Mazza
Apache FOP Team