(Created from draft Comments document dated: Fri Dec 03 13:40:14 EST 2004)
This document includes XSL-FO related comments that have been resolved by the XSL FO Subgroup of the XSL Working Group.
Message-Id: <4.3.2.7.2.20020723151245.01668828@172.27.10.30> Date: Tue, 23 Jul 2002 15:14:42 -0500 To: xsl-editors@w3.org From: Tony Graham <Tony.Graham@Sun.COM> (by way of Paul Grosso <pgrosso@arbortext.com>) Subject: bad input to system-color()
Speaking of system-color(), what happens if the NCName is not the name of a system defined color?
Disposition: Explanation of why no change will be made
It is system dependent what system-color() returns for any value (including ones it doesn't expect); it has to return a valid color value or signal an error.
CONSENSUS: Nothing in the spec needs to change.
Regards, Tony.
Message-Id: <4.3.2.7.2.20020723150829.02422958@172.27.10.30> Date: Tue, 23 Jul 2002 15:08:46 -0500 To: xsl-editors@w3.org From: Tony Graham <Tony.Graham@Sun.COM> (by way of Paul Grosso <pgrosso@arbortext.com>) Subject: Errata: <integer> or <number>?
Sections 7.26.12 to 7.26.14, defining number-columns-repeated, number-columns-spanned, and number-rows-spanned, each contain: Value: <number> then each define the meaning of <integer>. Shouldn't the value definitions be: Value: <integer> ? This is true in 7.26.12, 7.26.13, 7.26.14 and 7.26.8. Also 7.9.6, 7.9.7, 7.15.2, 7.25.2, 7.25.7, 7.25.10,.
Disposition: Accepted (bug in spec)
Change <integer> to <number> in all the above cases.
Erratum, Section 7.26.12:
Replace:
the value label <integer>.
with
<number>
Erratum, Section 7.26.13:
Replace:
the value label <integer>.
with
<number>
Erratum, Section 7.26.14:
Replace:
the value label <integer>.
with
<number>
Erratum, Section 7.26.8:
Replace:
the value label <integer>.
with
<number>
Erratum, Section 7.9.6:
Replace:
the value label <integer>.
with
<number>
Erratum, Section 7.9.7:
Replace:
the value label <integer>.
with
<number>
Erratum, Section 7.15.2:
Replace:
the value label <integer>.
with
<number>
Add:
to the definition of the value:
If a zero, negative, or non-integer value is provided, the value will be rounded to the nearest integer value greater than or equal to 1.
Erratum, Section 7.25.2:
Replace:
the value label <integer>.
with
<number>
Erratum, Section 7.25.7:
Replace:
the value label <integer>.
with
<number>
Erratum, Section 7.25.10:
Replace:
the value label <integer>.
with
<number>
Regards, Tony.
Message-Id: <4.3.2.7.2.20020723150957.01635d88@172.27.10.30> Date: Tue, 23 Jul 2002 15:10:18 -0500 To: xsl-editors@w3.org From: Tony Graham <Tony.Graham@Sun.COM> (by way of Paul Grosso <pgrosso@arbortext.com>) Subject: leader-length
Should Section 7.21.4, "leader-length", state that when the value or the value of a component is a percentage, the specified value is inherited, not the computed value?
Disposition: Explanation of XSL spec
One can think of use-cases both ways; i.e. where it would be more "convenient" to have the specified value inherited rather than the computed value, as well as where it is more "convenient" to have the computed value inherited rather than the specified value. One can also think of cases where it is impossible to achieve the desired effect if it was not the computed value that was inherited; you can always specify the percentage where desired, but you cannot refer to a specific ancestor container.
In some future version of XSL, that would support "layout driven" formatting, one can envision extensions to the expression language with functions that referred to result dimensions so you could specify, for example, 50% of the width of "myself", or 50% of my ancestor column width.
Regards, Tony.
Message-Id: <4.3.2.7.2.20020918182239.02654f00@172.27.10.30> Date: Wed, 18 Sep 2002 18:27:34 -0500 To: xsl-editors@w3.org From: Paul Grosso <pgrosso@arbortext.com> Subject: <keep> versus <integer> for the keep-* properties
In sections 7.19.3-4, the keep-together, keep-with-next, and keep-with-previous properties refer to the <keep> datatype in its value but then describe the allowable values for the components in terms of <integer>.
Disposition: Explanation of why no change will be made
The XSL FO SG investigated this and decided that there were no changes required to the spec. The current wording is correct in that it is clear that <keep> is the datatype for the compound properties, but the values of the individual components include the <integer> datatype.
However it was decided to capture this in our comment record, hence this posting.
How do expressions work within a shorthand? For example, is something like the following valid (where the font size is given as an expression: font="bold (1.2*from-parent(text-indent))/14pt sans-serif"
Disposition: Explanation of XSL spec
The value of "font" is not a valid expression according to 5.9. You may not have "individual tokens" in a shorthand as an expression.
How do functions like from-parent() work with compound properties? For example, if the FO's parent has: space-before.minimum="4pt" space-before.optimum="6pt" space-before.maximum="8pt" then what values do the five space-before components have on the current FO if it reads: <fo:block space-before="from-parent(space-before)+3pt"/>
Disposition: Accepted (bug in spec)
The definition of the from-parent function includes:
If the argument specifies a shorthand property and if the expression only consists of the from-parent function with an argument matching the property being computed, it is interpreted as an expansion of the shorthand with each property into which the shorthand expands, each having a value of from-parent with an argument matching the property. It is an error if arguments matching a shorthand property are used in any other way.
It was intended that the same restriction applies to property values of compound datatypes making "from-parent(space-before)+3pt" an error.
Erratum, Section 5.10.4 inherited-property-value:
Add:
at the end of the function description:
If the argument specifies a shorthand property and if the expression only consists of the inherited-property-value function with an argument matching the property being computed, it is interpreted as an expansion of the shorthand with each property into which the shorthand expands, each having a value of inherited-property-value with an argument matching the property. It is an error if arguments matching a shorthand property are used in any other way. Similarly, if the argument specifies a property of a compound datatype and if the expression only consists of the inherited-property-value function with an argument matching the property being computed, it is interpreted as an expansion with each component of the compound property having a valye of inherited-property-value with an argument matching the component. It is an error if arguments matching a property of a compound datatype are used in any other way.
Erratum, Section 5.10.4 from-parent:
Add:
at the end of the function description:
Similarly, if the argument specifies a property of a compound datatype and if the expression only consists of the from-parent function with an argument matching the property being computed, it is interpreted as an expansion with each component of the compound property having a valye of from-parent with an argument matching the component. It is an error if arguments matching a property of a compound datatype are used in any other way.
Erratum, Section 5.10.4 from-nearest-specified-value:
Add:
at the end of the function description:
Similarly, if the argument specifies a property of a compound datatype and if the expression only consists of the from-nearest-specified-value function with an argument matching the property being computed, it is interpreted as an expansion with each component of the compound property having a valye of from-nearest-specified-value with an argument matching the component. It is an error if arguments matching a property of a compound datatype are used in any other way.
Erratum, Section 5.10.4 from-table-column:
Add:
at the end of the function description:
If the argument specifies a shorthand property and if the expression only consists of the from-table-column function with an argument matching the property being computed, it is interpreted as an expansion of the shorthand with each property into which the shorthand expands, each having a value of from-table-column with an argument matching the property. It is an error if arguments matching a shorthand property are used in any other way. Similarly, if the argument specifies a property of a compound datatype and if the expression only consists of the from-table-column function with an argument matching the property being computed, it is interpreted as an expansion with each component of the compound property having a valye of from-table-column with an argument matching the component. It is an error if arguments matching a property of a compound datatype are used in any other way.
Erratum, Section 5.10.4 merge-property-values:
Add:
at the end of the function description:
If the argument specifies a shorthand property and if the expression only consists of the merge-property-values function with an argument matching the property being computed, it is interpreted as an expansion of the shorthand with each property into which the shorthand expands, each having a value of merge-property-values with an argument matching the property. It is an error if arguments matching a shorthand property are used in any other way. Similarly, if the argument specifies a property of a compound datatype and if the expression only consists of the merge-property-values function with an argument matching the property being computed, it is interpreted as an expansion with each component of the compound property having a valye of merge-property-values with an argument matching the component. It is an error if arguments matching a property of a compound datatype are used in any other way.
From: Tony Graham <Tony.Graham@Sun.COM> Message-ID: <15751.44288.968086.99614@tenso.ireland.sun.com> Date: Tue, 17 Sep 2002 23:30:24 +0100 To: xsl-editors@w3.org Subject: border-spacing property
1. Section 7.29.9, "border-spacing", states that border-spacing
applies to fo:table, but border-spacing is not included in the list
of applicable properties in Section 6.7.3, fo:table.
2. The last paragraph of Section 7.29.9 states:
If two values are specified the
"border-separation.block-progression-direction" is set to the
second value and
"border-separation.inline-progression-direction" are both set to
the first value.
Presumably this should be:
If two values are specified the
"border-separation.block-progression-direction" is set to the
second value and
"border-separation.inline-progression-direction" is set to the
first value.Disposition: Accepted (bug in spec)
Erratum, Section 7.29.9:
Replace:
"are both" in the last sentence of the XSL modification
with
is
Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin mailto:tony.graham@sun.com Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708
Message-Id: <4.3.2.7.2.20020927153302.0212d008@172.27.10.30> Date: Fri, 27 Sep 2002 15:33:25 -0500 To: xsl-editors@w3.org From: "Arved Sandstrom" <asandstrom@accesswave.ca> (by way of Paul Grosso <pgrosso@arbortext.com>) Subject: RE: <character> property datatype > -----Original Message----- > From: www-xsl-fo-request@w3.org [mailto:www-xsl-fo-request@w3.org]On > Behalf Of Tony Graham > Sent: July 31, 2002 1:28 PM > To: 'Www-Xsl-Fo > Subject: Re: <character> property datatype >
> Use a Char. > > Do not use 'U+xxxx'. > > Arved Sandstrom wrote at 29 Jul 2002 19:15:09 -0300: > > A number of properties are typed as having <character> values: > "character", > > "grouping-separator", and "hyphenation-character". > > > > <character> is described as being a single Unicode character, > in Section > > 5.11. > > > > However, the property description for fo:character embellishes > this rather > > terse description, and says that a <character> specifies "the > code point of > > the Unicode character to be presented". To me this pretty > clearly means a > > specification of form U+xxxx. > > Pick your Unicode version. Prior to Unicode 3.1, 'U+xxxx' was a > 'Unicode value.' Today, "[i]n running text, an individual Unicode > code point can be expressed as U+n, where n is from four to six > hexadecimal digits..." > > A 'character' property value is hardly running text. Hi, Tony I just revisited this because the question just arose on the fop-dev mailing list. I looked at 7.16.1 in the XSL spec, and it clearly says that <character> there means the code point. Absolutely unambiguously it says _code point_. I also said so above, originally. This is still a sticking point with me. A code point, as stated in your own book, is the _integer value_ (however that might be represented). So how does this work? Is <character character="3066"/> legal? According to the XSL spec, you bet. I just repesented an integer as an XSL <integer>
Disposition: Accepted (clarification)
Erratum, Section 5.11, definition of <character>:
Add:
valid in accordance with production [2] of XML. For example, "c" or "∂".
Erratum, Section 7.16.1:
Replace:
Specifies the code point of the Unicode character to be presented.
with
Specifies the Unicode character to be presented.
Clarification please. Regards, Arved Sandstrom
Message-ID: <3D8DE91B.92EE9944@isogen.com> Date: Sun, 22 Sep 2002 11:00:27 -0500 From: "W. Eliot Kimber" <eliot@isogen.com> To: xsl-editors@w3.org Subject: FO: Requirements from Recent Customers/Prospects ISOGEN has started doing a good bit of XSL FO development as well as working with existing and potential customers on evaluating the applicability of XSL FO to their existing documents. Out of this work we've started to gather a list of requirements that cannot currently be met with XSL 1.0. I reviewed the xsl-editors list back to Jan 2002 and didn't see any of these mentioned (except for the indexing support), so I thought I would list them here. We are currently working with two main types of documents: technical manuals (e.g., user guides, reference manuals, aircraft maintenance manuals, etc.) and serials (STM journals, designed magazines, etc.). We are also starting to do some work with traditional book publishers, but so far haven't found any requirements there that we can't meet (although I'm sure there are some). In addition to the composition-related requirements outlined below, we also have a general requirement for getting feedback from the pagination stage back to the initial FO generation stage--if there was a standard way to do this we could develop, for example, multi-pass processes that could be conditioned on page layout results in a way that FO processes cannot be today except through proprietary extensions. It would also enable the development of, for example, loose-leaf publishing solutions. It might be as simple as standardizing the serialized representation of area trees or it might require the definition of some sort of input-structure to result page mapping format.
Technical Manuals For technical manuals, the unmet requirements I've identified are: Hard Requirements: - Collapsing of sequences of page number citations to unique numbers (same requirement submitted by David Pawson). Both XSL Formatter and XEP provide extensions to do this now and the lack of it is the only barrier to automatically producing back-of-the-book indexes with FO. Note that this has to work even if each page-number-citation is contained within a basic-link (the normal practice for generating linked PDFs). - Page position-sensitive headers/footers for tables. For example, I need to be able to generate headers like "Table 1 (cont.)" on 2nd and subsequent pages of a multi-page table. This appears to be impossible in XSL 1.0. I think this requirement could be met by allowing marker references in table headers and footers, for example. - "Revision bars". Must be able to generate marks that are positioned relative to the position of inline areas and that have the same block-progression- or inline-progression-direction extent as the inline area. I think it would be sufficient for these to be generated within the same region as the inline area, but the best solution would allow the marks to be in one of the non-body regions. I believe all the FO implementation vendors are developing or have developed proprietary solutions to this requirement. Nice-To-Haves: - Direct support for generating PDF links and annotations. I need to be able to generate PDF bookmarks, in particular, but possibly other types of annotations. While basic-link naturally translates to PDF link annotations, there is no obvious way to generate bookmarks or other annotations in a standard way. All the FO implementations provide extensions to generate bookmarks, for example. There ought to be a way to abstract and generalize the notion that PDF annotations represents. For example, it might make sense to have a special region or flow type that is used for these types of online features or there might be a way to define the interpretation of existing online structures, I don't know. But the lack of standardization in this area is a significant barrier to practical interoperation because I think pretty much all uses of FO will be used, in part, to generate PDFs intended for online delivery. It also seems unlikely that an alternative page-based online delivery format will be developed as an alternative to PDF any time soon (seems more likely that PDF will be fully standardized, although I'm not holding my breath for that either). - Flowing of text around floated or absolutely-positioned areas. For technical manuals this is a nice to have--nobody using an SGML-based composition system can really do this today (except maybe with Frame+SGML), so most don't do it, but you do run into some more heavily designed manuals that are not currently SGML or XML based. But this has not been an issue for our technical manual clients or prospects so far.
Disposition: Future XSL version
This request for new functionality will be considered for a future (post 1.1) version of XSL.
Designed Documents
Obviously, designed magazines (magazines with arbitrary page layouts
with lots of design elements) are the biggest challenge--they require
page layout functions that XSL 1.0 explicitly choose not to address (and
good thing to or we might never have seen a spec :-). However, we are
seeing two classes of designed magazines: those that require arbitrary
flows across disconnected areas and those that do not. For our current
serial-producing customer, a fairly typical STM
(scientific/technical/medical) publisher, their magazines fall into the
second category: each article or department is rendered as a single
contiguous page flow that could be rendered by FO "if only". This
suggests that there is a middle ground between the current FO area model
and a completely arbitrary flow-to-area model that would satisfy the
requirements of a large number of magazines without being too complex to
either define or implement. [This enterprise, a non-profit STM
publisher, already uses XML for its non-designed journals and wants to
use XML for its glossy magazines as well in order to, for example, lower
the cost of serving the magazine content in HTML and to resolve on a
single technology base for all its publications. They currently use DTP
tools to do glossy magazine layout and production.]
For these middle-ground serials, the unmet requirements that I've
identified so far are:
- Ability to flow text around rectangular floated or absolutely placed
areas. For example, I might have a two-column layout where the first
page has a graphic positioned in the middle of the page so that it
intrudes vertically into the two columns:
.-----.
| |
.----. | img | .----.
| | '-----' | |
| '---. .---' |
| | | |
-----------------------
- More fine control of column filling and balancing. For example, I need
to be able to ballance two columns of a three-column layout but then do
something else in other (don't have an example to hand). My
understanding is that currently you can only balance across all the
columns of a region.
Given these two features, I think I could otherwise replicate serials of
these types, as long as all graphic elements are rectangular (that is,
no irregularly-shaped design elements around which text would be
flowed).
For fully-designed magazines I would of course need the following
features (which I don't really expect XSL to step up to in the next
revision but I think it's worth capturing the requirements, because they
might end up being easier to do than it appears):
Hard Requirements:
- Ability to apply flows to arbitrarily-placed areas (e.g., articles
continued from page 4 to the page 55).
- Ability to flow text around arbitrarily shaped areas.
Nice-To-Have:
- Automation of layout and page tuning that is currently done largely by
hand. This is mostly copy fitting to make X amount of content fit within
a specific amount of space. For example, it would be ideal if one could
provide hints like "max-page-length='10'" on a block or block-container.
That, coupled with lower-level constraint hints, might make it possible
for a composition engine to do most or all of the layout tuning work.
Then, given an interactive FO-based composition tool (imagine Quark or
InDesign using an FO area tree under the covers) one could do the final
design tweaking, as one does today with these unstructured design tools.
I have no idea how practical or realistic such a vision is, but it seems
to me like it ought to be doable.Disposition: Future XSL version
This request for new functionality will be considered for a future (post 1.1) version of XSL.
Cheers, Eliot -- W. Eliot Kimber, eliot@isogen.com Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139
Message-Id: <4.3.2.7.2.20020806133216.016d9c10@172.27.10.30> Date: Tue, 06 Aug 2002 13:38:59 -0500 To: xsl-editors@w3.org From: Paul Grosso <pgrosso@arbortext.com> Subject: probable typo/bug in XSL spec in table display-align
In 6.7.1.1.2 Simple Table with Relative Column-width Specifications, the example stylesheet and Fo result assign a value of "top" to display-align [1]. However, the allowable values of display-align [2] do not include "top". (The stylesheet, as written, would also pass through an invalid value of "bottom".) I believe this is a bug in the spec. The correction is to fix the stylesheet so that it explicitly converts values of top and bottom (as it now does with middle) to appropriate values for display-align and to correct the FO result accordingly.
Disposition: Accepted (bug in spec)
You are correct.
Erratum, Section 6.7.1.1.2:
Replace:
the xsl:otherwise element in the XSL stylesheet
with
<xsl:choose>
<xsl:when test="@valign='top'">
<xsl:attribute name="display-align">before</xsl:attribute>
</xsl:when>
<xsl:when test="@valign='bottom'">
<xsl:attribute name="display-align">after</xsl:attribute>
</xsl:when>
<xsl:otherwise>
<xsl:attribute name="display-align">before</xsl:attribute>
</xsl:otherwise>Replace:
the value "top" of the display-align property for the first table cell in the Result Instance
with
before
paul [1] http://www.w3.org/TR/xsl/slice6.html#section-N15447-Introduction [2] http://www.w3.org/TR/xsl/slice7.html#display-align
Message-ID: <3D9CBD2B.1020005@club-internet.fr> From: Karen Lease <klease@club-internet.fr> To: Paul Grosso <pgrosso@arbortext.com> Cc: xsl-editors@w3.org Subject: Re: Regarding your comment about inline building on xsl-editors
In 7.16.3, the description of the "suppress-at-line-break" property describes the behavior of "suppress" as: <quote> If the glyph-area generated by the fo:character is first or last in a line-building partition (see section [4.7.2 Line-building]) then it is deleted rather than being placed in the area tree, together with all adjacent areas with a suppress-at-line-break value of suppress. </quote> Since this definition references 4.7.2, one would assume that line-building partitions are defined there. In fact, this section does discuss line-building and partitions, but it's not exactly clear to me if a "line-building partition" is (a) a sequence of subsets Si, Si+1, Si+m, which all consist of inline objects and which generate m+1 adjacent line areas, or (b) each subset Si consisting of inline areas. I lean towards (a). Concerning suppress-at-line-break, 4.7.2 says this (Item 5, bullet 2): <quote> Deletions occur when a glyph-area which is last within a subset Si, has a suppress-at-line-break value of suppress, provided that i < n and Bi+1 is a line-area. Deletions also occur when a glyph-area which is first within a subset Si, has a suppress-at-line-break value of suppress, provided that i > 1 and Bi-1 is a line-area. </quote> To me, this clearly says that a leading space in the first line would *not* be suppressed and neither would a trailing space in the last line. Whereas the intuitive interpretation of 7.16.3 which we both seemed to be using in my original "Item 3" question managed to get rid of these spaces! About the only way I can think of to make these two sections less contradictory is to use interpreation (b) above of line-building, i.e. a line-building partition is a single subset Si containing inline areas which all become the children of a single line-area. In general, leading and trailing spaces (or other glyphs generated by fo:character objects with suppress-at-line-break=suppress) are suppressed, except at the beginning of the first line and the end of the last line, as those are not formatter-generated line-breaks. Would it be possible to clarify the correct relation between 7.16.3 and 4.7.2? As to avoiding the initial space in the first line, one shold use <fo:block>XXX</fo:block> and not: <fo:block> XXXX </fo:block> as any real XML editor would do with mixed content anyway.
Disposition: Accepted (bug in spec)
Your comment prompted a discussion within the FO Subgroup, highlighting an imperfect overlap between the Line-building section and the white-space-treatment and suppress-at-line-break properties.
We decided to move the processing of the white-space-treatment property into section 4.7.2 (Line-building) and to modify the properties slightly for greater flexibility going forward, and to rescind the erratum that created a new property relating to suppress-at-line-break, which is now unnecessary.
We did not find it necessary to move the processing of the white-space-collapse or linefeed-treatment properties.
The newly reworded 4.7.2 and the rewritten property definitions 7.15.8 and 7.16.3 [below] now clarify the relations of these properties to Line-building. Some whitespace handling happens in refinement and some happens in area generation, and this change moves some processing that was happening in refinement (processing of the white-space-treatment and suppress-at-line-break properties) into area generation (4.7.2 line-building).
We believe this is the best way to address the complexities of whitespace handling and allows for implementations and users to get all the control they need.
Erratum, Section 4.7.2:
Replace:
the text of item 4
with
Forced line-breaks are respected. Specifically, if C is a descendant of F, and C is a fo:character whose Unicode character is U+000A, and A is the area generated by C, then either C is a child of F and A is the last area in a subset Si, or C is a descendant of a child C' of F, and A ends (in the sense of 4.2.5) an area A' returned by C', such that A' is the last area in a subset Si.
Replace:
the text of item 5
with
The partition follows the ordering of the area tree, except for certain glyph substitutions and deletions. Specifically, if B1, B2, ..., Bp are the normal child areas of the area or areas returned by F, (ordered in the pre-order traversal order of the area tree), then there is a one-to-one correspondence between these child areas and the partition subsets (i.e. n = p), and for each i,
· Si consists of a single block-area and Bi is that block-area, or
· Si consists of inline-areas and Bi is a line-area whose child areas are the same as the inline-areas in Si, and in the same order, except that where the rules of the language and script in effect call for glyph-areas to be substituted, inserted, or deleted, then the substituted or inserted glyph-areas appear in the area tree in the corresponding place, and the deleted glyph-areas do not appear in the area tree. For example, insertions and substitutions may occur because of addition of hyphens or spelling changes due to hyphenation, or glyph image construction from syllabification, or ligature formation. Deletions occur as specified in (6.), below.
Add:
item 6
white-space-treatment is enforced. In particular, deletions in (5.) occur when there is a glyph area G such that
(a.) the white-space-treatment of G is "ignore" and the character of G is classified as white space in XML; or
(b.) the white-space-treatment of G is "ignore-if-before-linefeed" or "ignore-if-surrounding-linefeed", the suppress-at-line-break of G is "suppress", and G would end a line-area; or
(c.) the white-space-treatment of G is "ignore-if-after-linefeed" or "ignore-if-surrounding-linefeed", the suppress-at-line-break of G is "suppress", and G would begin a line-area.
In these cases the area G is deleted; this may cause the condition in clauses (b.) or (c.) to become true and lead to further deletions.
Erratum, Section 7.15.8:
Replace:
the definitions of the property values
with
Any glyph-area whose Unicode character is classified as white space in XML, except for U+000A, shall be deleted during line-building and inline-building (see 4.1.6 and 4.2.6).
Any glyph-area whose Unicode character is classified as white space in XML shall not be deleted during line-building and inline-building.
Any glyph-area with a suppress-at-line-break value of 'suppress' shall be deleted during line-building and inline-building if it would be the last glyph-area descendant of a line-area.
Any glyph-area with a suppress-at-line-break value of 'suppress' shall be deleted during line-building and inline-building if it would be the first glyph-area descendant of a line-area.
Any glyph-area with a suppress-at-line-break value of 'suppress' shall be deleted during line-building and inline-building if it would be the first or last glyph-area descendant of a line-area.
Erratum, Section 7.16.3:
Replace:
the definition of the "suppress" value
with
The glyph area generated by the fo:character is eligible to be suppressed at the start or end of a line-area depending on the white-space-treatement property. (q.v.)
Replace:
the definition of the "retain" value
with
The glyph area generated by the fo:character shall be placed in the area tree whether or not it first or last in a line-area.
Regards, Karen Lease SPX Valley Forge/FOP
Message-ID: <3DA03D1B.9020905@multiconn.com> Date: Sun, 06 Oct 2002 15:39:39 +0200 From: Oleg Tkachenko <olegt@multiconn.com> To: xsl-editors@w3.org Subject: rl-alternating-lr-tb writing mode (kind of boustrophedon style) Hello !
Am I right that xsl 1.0 doesn't support rl-alternating-lr writing modes? Such scripts did exist, I found references to ancient Hungarian runes and ancient Hawaiian. It's not a real use case though, I'm just curious if lr-alternating-rl-tb is allowed as additional writing-mode value, why rl-alternating-lr-tb is not?
Disposition: Explanation of why no change will be made
You are correct that rl-alternating-lr writing mode is not one of the supported writing modes is XSL. We have restriced these to those where there is clear evidence of use for a script. For ancient Hungarian runes the evidence is contradictory and the most trustworthy source (ISO committee working on character coding) indicates that the report of rl-alternating-lr writing mode is erroneous. For ancient Hawaiian there is only one source claiming the use of this writing mode; other authors found discussing ancient Hawaiian do not mention it.
The XSL WG is, of course, open to add additional writing modes if new and strong evidence is presented for actual usage.
For the record:
Old Hungarian Runes:
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n1758.pdf: Old Hungarian can be written either RTL or LTR; in earlier times RTL predominated.
http://www.omniglot.com/writing/hungarian_runes.htm: Hungarian Runes were usually written on sticks in boustrophedon style (alternating direction right to left then left to right).
http://fang.fa.gau.hu/~heves/runic.html: Typically, writers held a small piece of wood in their left-hand, and carved the letters by their right one. Consequently, the direction of the writing was from right to left. When they reached the end of the stick, they turned it around, so the next line comes "upside-down" compared to the first one.
Scandinavian Rune inscriptions on stone also tended to follow the outline of the stone or placed in other geometric patterns. Frequently the letters were placed on the body of a long dragon. "Regular" texts, however, were writen lr-tb (one example is the stone at Rök). This can be considered the real writing mode and the others a "graphic arts" effect, similar to the one described for writing Hungarian Runes on a stick.
For Hawaiian Oleg clarifies:
Well, now I realized the site where I had read [http://www.k12.hi.us/~lwilson/AAH/Invention13.html] it is the only place on the net (google's cache [http://216.239.51.100/search?q=cache:JjO1U-RE3P4C:www.k12.hi.us/~lwilson/AAH/Invention13.html+boustrophedon+right+to+left+then+left+to+right+hawaii&hl=en&ie=UTF-8]).
The only interesting part is at footnote #294:
"294. In the Modern Hawaiian language Rs and Ts have been transposed intoLs and Ks. This was accomplished by Boston missionaries who arrived in the Hawaiian Islands early in the nineteenth century, and were the first to compose Modern Hawaiian dictionaries. These missionaries noted that when they taught the Islanders to read and write in the English language, although they learned it readily, they persisted in writing alternating lines from right to left, and then from left to right, or in other words, boustrophedon, a technique of writing commonly used in Ancient times. For further discussion of the prospects of Ancient Hawaiian literacy, see: W.A. Kinney, Hawaii's Capacity for Self-Government All But Destroyed (Salt Lake City, Utah: Frank L. Jensen, Publisher, 1927), pp. 13-86, 88, 98, 105, 174, and 201."
Actually I should admit it could be an error and they really wrote ltr/rtl as most boustrophedon scripts, unfortunately there are too few information.
-- Oleg Tkachenko eXperanto team Multiconn International, Israel
Message-Id: <4.3.2.7.2.20021018085703.04067b78@172.27.10.30> Date: Fri, 18 Oct 2002 09:03:40 -0500 To: xsl-editors@w3.org From: Paul Grosso <pgrosso@arbortext.com> Cc: <e.bischoff@noos.fr> Subject: <shape> datatype for clip Eric, I am hereby forwarding your comment on the XSL spec to the appropriate comments list for consideration by the WG. paul >From: =?utf-8?q?=C3=89ric=20Bischoff?= <e.bischoff@noos.fr> >To: <www-xsl-fo@w3.org> >Date: Fri, 18 Oct 2002 12:16:07 +0200 >Subject: Re: xsl-fo first anniversary
>2 - A small mistake in the spec: in section 7.20.1, the "clip" property uses >the <shape> datatype. The <shape> datatype is not defined in section 5.11 >"property datatypes".
Disposition: Accepted (bug in spec)
Erratum, Section 5.11:
Add:
a definition for the following datatype:
"rect (" <top> <right> <bottom> <left> ")" where <top>, <bottom> <right>, and <left> specify offsets from the respective sides of the content rectangle of the area.
<top>, <right>, <bottom>, and <left> may either have a <length> value or 'auto'. Negative lengths are permitted. The value 'auto' means that a given edge of the clipping region will be the same as the edge of the content rectangle of the area (i.e., 'auto' means the same as '0pt'.)
Date: Fri, 18 Oct 2002 12:03:29 -0400 (EDT) From: Eric Bischoff <e.bischoff@noos.fr> To: Paul Grosso <pgrosso@arbortext.com>, xsl-editors@w3.org Message-Id: <200210181804.24068.e.bischoff@noos.fr> Subject: Re: <shape> datatype for clip Le Friday 18 October 2002 16:03, Paul Grosso a 飲it: > Eric, > > I am hereby forwarding your comment on the XSL spec to > the appropriate comments list for consideration by the WG. Thanks Paul. Another one that keeps bugging me : -----------------------------------------------------------------------------------
The BNC production for a function call (section 5.9.4) is :
[3] FunctionCall ::=
FunctionName '(' ( Argument ( ',' Argument)*)? ')'
as you can see, it does not mention any whitespace, neither directly nor
indirectly through FunctionName and Argument productions.
At the same time, in section 5.9.11, it is said that
If the character following an NCName (possibly after intervening
ExprWhitespace) is "(", then the token must be recognized as FunctionName.
which explicitly says one could find white space. This is contradictory.Disposition: Explanation of XSL spec
This is not a contradiction. Section 5.9.11 says the same thing as the XPath spec says reading white space being allowed before or after a token.
----------------------------------------------------------------------------------- -- Linux produces remarkedly less hot air than Windows: under Windows, the processor gets hot after just a few minutes.
Message-ID: <3DB809F9.5080101@isogen.com> Date: Thu, 24 Oct 2002 09:55:53 -0500 From: "W. Eliot Kimber" <eliot@isogen.com> To: xsl-editors@w3.org Subject: basic-link missing from %block; I've been experimenting with using basic link around blocks overlayed on graphics to implement hot spots (works with XSL Formatter--XEP currently doesn't fully implement absolute positioning of blocks, but should otherwise work there too. Haven't tried with Epic yet).
I noticed that %block; does not include basic-link but basic-link allows block. This suggests that basic-link should be allowed where ever block is allowed. There is already an explicit constraint that basic-link cannot contain blocks when it occurs in an inline-only context and visa-versa, so I don't think that allowing basic-link in %block; will open up any potential ambiguity of allowed combinations of elements.
Disposition: Explanation of XSL spec
fo:basic-link generates one or more normal inline-areas (see 6.9.2). It should thus not be part of the list of FOs in %block; that lists those that generate block-areas. To use fo:basic-link as a block-level object it needs to be wrapped in an fo:block - (see note in 6.9.2).
Cheers, Eliot -- W. Eliot Kimber, eliot@isogen.com Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139
Date: Fri, 25 Oct 2002 12:10:07 -0400 (EDT) From: Eric Bischoff <e.bischoff@noos.fr> To: xsl-editors@w3.org Message-Id: <200210251811.02638.e.bischoff@noos.fr> Subject: Fwd: Re: XSL Errata document updated Le Friday 25 October 2002 17:38, Max Froumentin a 飲it: > These errata are mostly the result of comments sent to > the public xsl-editors comment list (archived at > http://lists.w3.org/Archives/Public/xsl-editors/ ). > > Paul Grosso > for the XSL FO Subgroup of the XSL WG Paul,
Isn't there an error in the errata ;-) ?
============================
Replace:
fo: element and attribute tree: <fo:external-graphic src="TH0317A.jpg"/>
with
<fo:external-graphic src="'url(TH0317A.jpg)'"/>
============================
Are you sure it's not rather:
<fo:external-graphic src="url('TH0317A.jpg')"/>
? (look at the position of the single quotes)
Reference: Section 5-11 Property datatypes:
============================
<uri-specification>
A sequence of characters that is "url(", followed by optional white space,
followed by an optional single quote (') or double quote (") character,
followed by a URI reference as defined in [RFC2396], followed by an
optional single quote (') or double quote (") character, followed by
optional white space, followed by ")". The two quote characters must be the
same and must both be present or absent. If the URI reference contains a
single quote, the two quote characters must be present and be double
quotes.
============================
It means "url('string')" and not "'url(string)'".
Same for all other mentions of url( ) in the errata.Disposition: Explanation of XSL spec
No the erratum is correct. The quotes around the "string" are optional and have been left out in the example. The enclosing single quotes ensure that the value is interpreted as a string literal by the expression language. Note that "url" is not a function, but a piece of syntax borrowed from CSS2.
-- - Linux produces remarkedly less hot air than Windows: under Windows, the processor gets hot after just a few minutes... - Yes, but it never stays on long enough to burn out!
Date: Sat, 26 Oct 2002 15:31:16 +0900 From: MURAKAMI Shinyu <murakami@nadita.com> To: xsl-editors@w3.org Message-Id: <20021026152955.3D1C.MURAKAMI@nadita.com> Subject: "clear" property applies to
I believe the "clear" property must apply to not only fo:float but also all block-level FOs -- fo:block, fo:block-container, fo:table-and-caption, fo:table, and fo:list-block, but only fo:float has this property in the list "The following properties apply to this formatting object". Is this an error of the spec?
Disposition: Accepted (bug in spec)
Yes, the text of 7.18.1 (XSL modification) is correctly stating that it applies to the block-level formatting objects.
Erratum, Section 6.5.2:
Add:
the "clear" property to the list of properties that apply.
Erratum, Section 6.5.3:
Add:
the "clear" property to the list of properties that apply.
Erratum, Section 6.7.2:
Add:
the "clear" property to the list of properties that apply.
Erratum, Section 6.7.3:
Add:
the "clear" property to the list of properties that apply.
Erratum, Section 6.8.2:
Add:
the "clear" property to the list of properties that apply.
-- Shinyu Murakami Antenna House XSL Formatter team http://www.antennahouse.com
Date: Sat, 26 Oct 2002 15:48:21 +0900 From: MURAKAMI Shinyu <murakami@nadita.com> To: xsl-editors@w3.org Message-Id: <20021026153350.3D21.MURAKAMI@nadita.com> Subject: normal-sequence-reference-areas
In section 6.4.5 "fo:page-sequence", the term "normal-sequence-reference-areas" should be replaced with "normal-flow-reference-areas" which is used in other places in the spec.
Disposition: Accepted (editorial)
Yes it should.
Erratum, Section 6.4.5:
Replace:
"normal-sequence-reference-areas" in the first paragraph in "Areas:"
with
normal-flow-reference-areas
-- Shinyu Murakami Antenna House XSL Formatter team http://www.antennahouse.com
Message-ID: <3DC3C6F0.3070406@isogen.com> Date: Sat, 02 Nov 2002 06:37:04 -0600 From: "W. Eliot Kimber" <eliot@isogen.com> To: xsl-editors@w3.org Subject: Margins and Block Geometry
I'm trying to get a full understanding of block geometry and I think
I've pretty much got it now but I must report that the initial
discussion of block geometry in section 4.4.1, which I found to be
pretty clear, is then completely thrown out the window by the discussion
of margins in 5.3.2, in that the effect of margin specifications, which
are not mentioned *before* 5.3.2, seemingly contradicts 4.4.1 in that
4.4.1 says that the rectangles of a block are relative to (and only to)
the content rectangle of the containing reference area. And by
implication, are always *inside* of the containing reference area's
content rectangle given positive or zero values for border, padding, and
indent.
That is, given the information in 4.4.1 and this markup:
<fo:block-container
border-start-style="solid"
border-start-width="1pt"
border-start-color="red"
>
<fo:block
border-start-style="solid"
border-start-width="4pt"
border-start-color="rgb(200, 100, 0)"
padding-start="8pt"
font-family="sans-serif"
font-size="24pt"
line-height="110%"
>
I would except to see that the inner block's 4pt orange border is
adjacent to and inside of the block container's red border.
But in fact, the orange border is rendered 12 pts to the left (toward
the page's start edge) from the red border of the containing area!
Why?
The reason, of course, is that I haven't specified either
margin-left="0pt" or start-indent="12pt" (border width + padding). But
nothing in 4.4.1 suggested I would need to do so. Hmph.
It is only in section 5.3.2, in the discussion of margins, that it
becomes clearer why (although the motivation for margins being defined
*at all* is not provided in 5.3.2, or anywhere that I can find other
than for CSS compatibility). That is, this statement:
"If the corresponding absolute margin property is not explicitly
specified, or if the corresponding relative property is specified on the
formatting object and the absolute property only specified by the
expansion of a shorthand, the corresponding absolute margin property is
calculated according to the following formulae:
margin-corresponding = start-indent - inherited_value_of(start-indent)
- padding-corresponding - border-corresponding-width"
Does explain the behavior, but the justification for this formula is not
provided anywhere I can find.
Given that I can't see any value in margins on blocks *at all* (I have
all the control I need from the space, indent, and padding properties)
and don't have any CSS legacy of any kind (conceptual or data) I would
prefer that the margins be limited strictly to page areas, but that's of
course not an option given that the spec is published. [And as a
standards writer myself, I fully understand the need to maintain
compatability with other specs even when you'd rather not have to.]
However, it would be very helpful if 4.4.1 included a discussion of the
effect of non-zero explicit or implicit margin values, as well as the
fact that space-* is overridden by a larger *-indent value--it would, I
think, make things a bit clearer. That is, the statements in 4.4.1 hold
true if and only if margin-*="0pt". As the picture in 4.4.1 stands, it's
unspecified at that point what the effect of having a start-indent
greater than the sum of the space-before, border width, and padding is,
but I expected (for some reason, not sure why) that the extra space
woudl be added to the padding, not the space-* (but the actual behavior
is just as reasonable and probably closer to the normally expected result).
It would also be helpful if 5.3.2 at least provided some motivation for
the inclusion of margin properties or at least say why they have the
counter-intuitive effect of pulling the border and padding rectangles
outside of the content rectangles of their blocks' containing reference
areas.
I assume that the motivation is so that the default effect is for the
content rectangle of the contained block to be the same as the content
rectangle of the containing area, but I don't see the value in making
that the default behavior. What am I missing?Disposition: Accepted (clarification)
Some clarifying text will be added.
Erratum, Section 4.4.1:
Add:
a paragraph to the note below the first figure:
See also section 5.3.2 for how the margin properties affect the indents.
Cheers, Eliot -- W. Eliot Kimber, eliot@isogen.com Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139
Message-ID: <3DC5A18D.4010402@isogen.com> Date: Sun, 03 Nov 2002 16:22:05 -0600 From: "W. Eliot Kimber" <eliot@isogen.com> To: xsl-editors@w3.org Subject: How is Binding Edge Determined?
I noticed that text-align defines "outside" and "inside" in terms of the "binding edge". However, I couldn't find any reference to "binding" or "bound" or "bind" outside of the discussion of text-align. Thus my question: how is the binding edge defined or determined? That is, I might have a normally oriented page (before is top) that is top-bound or I might, for some bizare reason, bind a left-to-right document on the right. Have I missed something?
Disposition: Accepted (bug in spec)
No the specification needs to say that the user agent determines this edge (in an arbitrary way).
Erratum, Section 6.4.5:
Add:
a paragraph to the "Areas" section:
The page-viewport-areas identify one of the sides as a page binding edge. This recommendation does not specify the mechanism for selecting which side is the page binding edge.
NOTE:
If the User Agent can determine that the result is to be bound, then the page binding edge of any given page is the edge on which that page is intended to be bound.
Commonly the page binding edge of a page with an odd ordinal is the start-edge of that page and the binding-edge of a page with an even ordinal is the end-edge of that page.
The binding can be a simple as stapling or may be as complex as producing a book using an imposition scheme.
Thanks, Eliot -- W. Eliot Kimber, eliot@isogen.com Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139
Message-ID: <3DC66DF9.38D699E1@rcc.ch> Date: Mon, 04 Nov 2002 13:54:17 +0100 From: Heinz Grimm <grimm.heinz@rcc.ch> To: xsl-editors@w3.org Subject: fo:table, fo:table-row, Proposal for support of "big tables" Hi, We tried to use XSL-FO to create database reports. The biggest problem was, that big tables are not supported by XSL-FO. Big table means a table that has more rows and columns as can be rendered on a single page. Appended is a proposal to extend the specs of fo:table and fo:table-row to support big tables. I am new to this list. As I understand this list intended to submit proposals for XSL-FO 2.0 specs. Is there a web site, where I can look what changes to XSL-FO 1.0 are already planned or accepted? Thank you, Heinz Grimm
Proposal for support of "big tables"
fo:table
New values for property overflow:
next_row start on next page with table-header and continue
table with next row. Start eachn row with a row
header(see sample (b))
next_column start on next page with table_header and continue
table with next column. Start each row with a row
header (see sample (a))
fo:table-row (fo:table-row-header?,fo:table-cell+)
New formating object fo:table-row-header
Similar to fo:table-header, preceeds each row of a table,
is repeated if a table is wider than one page (see on-overflow)
Sample output (a):
<fo:table overflow="next_column">
.
.
.
<fo:table-row>
<fo:table-row-header>
<fo:block>R1</fo:block>
</fo:table-row-header>
<fo:table-cell>
<fo:block>1</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block>2</fo:block>
</fo:table-cell>
.
.
.
</fo_table-row>
</fo:table>
page 1
| C1 | C2 | C3 |
-------------------
R1 | 1 | 2 | 3 |
-------------------
R2 | 11 | 12 | 13|
-------------------
R3 | 21 | 22 | 23|
page 2
| C4 | C5 | C6 |
-------------------
R1 | 4 | 5 | 6 |
-------------------
R2 | 14 | 15 | 16|
-------------------
R3 | 24 | 25 | 26|
page 3
| C1 | C2 | C3 |
-------------------
R4 | 31 | 32 | 33|
-------------------
R5 | 41 | 42 | 43|
-------------------
R6 | 51 | 52 | 53|
page 4
| C4 | C5 | C6 |
-------------------
R4 | 34 | 35 | 36 |
-------------------
R5 | 44 | 45 | 46 |
-------------------
R6 | 54 | 55 | 56 |
Sample output (b):
<fo:table overflow="next_row">
.
.
.
<fo:table-row>
<fo:table-row-header>
<fo:block>R1</fo:block>
</fo:table-row-header>
<fo:table-cell>
<fo:block>1</fo:block>
</fo:table-cell>
<fo:table-cell>
<fo:block>2</fo:block>
</fo:table-cell>
.
.
.
</fo_table-row>
</fo:table>
page 1
| C1 | C2 | C3 |
-------------------
R1 | 1 | 2 | 3 |
-------------------
R2 | 11 | 12 | 13|
-------------------
R3 | 21 | 22 | 23|
page 2
| C1 | C2 | C3 |
-------------------
R4 | 31 | 32 | 33|
-------------------
R5 | 41 | 42 | 43|
-------------------
R6 | 51 | 52 | 53|
page 3
| C4 | C5 | C6 |
-------------------
R1 | 4 | 5 | 6 |
-------------------
R2 | 14 | 15 | 16|
-------------------
R3 | 24 | 25 | 26|
page 4
| C4 | C5 | C6 |
-------------------
R4 | 34 | 35 | 36 |
-------------------
R5 | 44 | 45 | 46 |
-------------------
R6 | 54 | 55 | 56 |Disposition: Future XSL version
This request for new functionality will be considered for a future (post 1.1) version of XSL.
Message-ID: <3DC7F532.7060405@isogen.com> Date: Tue, 05 Nov 2002 10:43:30 -0600 From: "W. Eliot Kimber" <eliot@isogen.com> To: xsl-editors@w3.org Subject: Tables Don't Respect Reference Orientation--why?
I notice that the spec says that only writing mode determines the cell and row progression order. I'm wondering why this is--I can't immediately think of any reason that tables shouldn't be rotatable just as any other reference area is--that is, the interaction of writing-mode with reference-orientation seems no more complex in a table context than in a multi-column page context, for example. Have I missed some hidden complexity?
Disposition: Explanation of XSL spec
Tables are NOT reference areas, which is why reference-orientation does not apply.
Thanks, Eliot -- W. Eliot Kimber, eliot@isogen.com Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139
Message-ID: <3DC80BEA.7040106@isogen.com> Date: Tue, 05 Nov 2002 12:20:26 -0600 From: "W. Eliot Kimber" <eliot@isogen.com> To: xsl-editors@w3.org Subject: Table Rotation Continued
Am I correct in my analysis that the reason that reference-orientation is not provided on table cell is that the calculation of the block and inline dimensions would just be too freaky when applying auto layout?
Disposition: Explanation of XSL spec
There are many other things that would get quite complex if reference-orientation would apply to table cells; for example border identification. To wrap the cell content in an fo:block-container for the cases where a rotation is required seems to be a simpler and more "orthogonal funtionality" design.
Thanks, Eliot -- W. Eliot Kimber, eliot@isogen.com Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139
Date: Fri, 15 Nov 2002 07:28:18 -0500 (EST) Message-Id: <5.1.0.14.0.20021115072042.031d0d80@junk> To: XSL Editors <xsl-editors@w3.org> From: "G. Ken Holman" <gkholman@CraneSoftwrights.com> Cc: Support at Antenna House <support@antennahouse.com> Subject: XSL 1.0 - Section 2.2 XSL Namespace Dear XSL Editors,
Section 2.2 of XSL 1.0 states "Implementors must not extend the XSL namespace with additional elements or attributes. Instead, any extension must be in a separate namespace." It is unclear if extensions are allowed to be in "no namespace", i.e. using an unprefixed element type name with no default namespace in scope. Such elements are distinguished from XSL elements, but are not in a specific namespace as might be implied by the second sentence of the quote. Therefore, is it an error for an XSL document to have any elements in no namespace, or is such an element merely considered to be an extension?
Disposition: Explanation of XSL spec
The XSL WG does not consider it unclear; an element or attribute in "no namespace" is not an allowed extension element or attribute. A further sentence will be added to make is absolutely clear.
Erratum, Section 2.2:
Add:
the following sentence to the end of the first paragraph after the first note:
The expanded-name of extension elements must have a non-null namespace URI.
Thank you! .................. Ken -- Upcoming hands-on in-depth XSLT/XPath and/or XSL-FO: - North America: Feb 3 - Feb 7,2003 G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/m/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) ISBN 0-13-065196-6 Definitive XSLT and XPath ISBN 0-13-140374-5 Definitive XSL-FO ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath ISBN 1-894049-10-1 Practical Formatting Using XSL-FO Next conference training: 2002-12-08,03-03,06
Date: Fri, 15 Nov 2002 21:26:44 -0500 (EST) Message-ID: <42B972A09F7ED61194A00002A513258201DB036B@n1024smx.nt.schwab.com> From: "Gupta, Deepak" <Deepak.Gupta@schwab.com> To: "'xsl-editors@w3.org'" <xsl-editors@w3.org> Cc: "'gkholman@CraneSoftwrights.com'" <gkholman@CraneSoftwrights.com> Subject: Proposal for suspending page numbering
I believe there is a need for functionality to temporarily suspend the FO page counter, so that a book can be generated with chapter title pages that do not have a page number. I suggest the following syntax :- <fo:page-sequence master-name="title" page-count="suspend"> <fo:page-sequence master-name="section" page-count="resume"> Please let me know if you require clarification & also whether this feature will be considered for the XSL-FO 2.0 specification.
Disposition: Future XSL version
Clarification from editor's list: he wants to omit certain pages from being included in the numbering sequence (not just omitting the display of the number on particular pages).
The proposed design is bad as it implies serial processing. A better approach would be eg "include-page-in-numbering-sequence='no'".
While it might make sense to have a property that suspends page counting on an fo:page-sequence, there are enough edge cases and issues to address that we don't think this is something for XSL 1.1. We will re-evaluate the need for this for XSL 2.0.
Thanks to Ken Holman for recommending that I contact the XSL Working Group. thanks, Deepak
Message-ID: <3DDBC0CE.1070806@multiconn.com> Date: Wed, 20 Nov 2002 19:05:18 +0200 From: Oleg Tkachenko <olegt@multiconn.com> To: xsl-editors@w3.org Subject: Extension functions in xsl-fo Hello!
Are extension functions allowed in xsl-fo expressions? The Recommendation says nothing about it and taking into account the fact that FunctionName production[1] is NCName, one may conclude that extension functions (in form we all used to in XPath) are not allowed. But on the other hand the Recommendation defines *Core* Function Library and one may conclude that noncore functions might exist too. Please, shed some light upon the issue.
Disposition: Explanation of XSL spec
In XSL 1.0 extension functions are not allowed in "xsl-fo" expressions. The existing functions are called "core", since they are very basic functions and more specialized ones added in future versions of XSL (at non-basic conformance levels) would not be included under that label.
Extension functions may be considered in a future version of XSL, but would also need a mechanism, similar to the XSLT "function-available", so portable stylesheets could be written.
The XSL WG invites you to come with usecases demonstrating what kind of extension functions you are thinking about. For a version of XSL that supports "layout driven" formatting it is clear that additional functions to eg refer to dimensions of formatted result will be needed; these should not be part of an extension set.
[1] http://www.w3.org/TR/xsl/slice5.html#NT-FunctionName -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel
Message-ID: <3DE22ABA.5050204@isogen.com> Date: Mon, 25 Nov 2002 07:50:50 -0600 From: "W. Eliot Kimber" <eliot@isogen.com> To: xsl-editors@w3.org Subject: Request clarification of true intent for simple-page-master content model
The content model for simple-page-master is a sequence group. However, there is no practical reason for it to not to be an AND group--there is no interdependency among the page region declarations and therefore there's no practical benefit to requiring a particular order of specification. This is the only sequence group in the spec that has this quality--all other sequence groups reflect practical ordering dependencies. At the moment no known FO implementation enforces the content model constraints for simple-page-master and XEP's validator does not complain if it is not followed. I'm wondering if my supposition that the Editors really did intend this to be an AND group in practice is correct and, if so, it would be possible to clarify this intent with a note to that effect. It would, I think, eliminate the possibility of annoying (but not tragic) Simon Says behavior on the part of some implementation that takes a pedantic stance on validation.
Disposition: Explanation of XSL spec
The "content models" aim to be as close to content models in XML DTDs as possible; thus no "and" groups.
The XSL Recommendation defines the correct order. However, given that the Recommendation doesn't say anything specific about what to do when encountering the incorrect order, in that case an implementation may (but need not) signal an error and recover in any way. (The way some implementations currently "recover" is reasonable.)
Thanks, Eliot -- W. Eliot Kimber, eliot@isogen.com Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139
To: Dave Pawson <daveP@dpawson.freeserve.co.uk> Cc: "Arved Sandstrom" <asandstrom@accesswave.ca>, <www-xsl-fo@w3.org>, xsl-editors@w3.org> From: Max Froumentin <mf@w3.org> Date: Wed, 10 Jul 2002 11:41:07 +0200 Message-ID: <86elebapjg.fsf@sophia.inria.fr> Subject: Re: [Moderator Action] RE: block width="2in"
Dave Pawson <daveP@dpawson.freeserve.co.uk> writes: >>In the case of 'block' none of the height/width/*-progression-dimension >>properties apply (Section 6.5.2). > > Yep. Noted. > >> If they did then we'd see them explicitly >>mentioned, as we do for 'block-container' (Section 6.5.3). If we can't count >>on at least this much in the spec then we may as well all pack up and go >>home. I'm not sure how to parse the above sentence. "this much" == "the fact that height/width/*-progression-dimension do not apply to block' or "this much" == "the fact that if they did the spec would mention them explicitely" ? > So the 'applies to all' statement on the property is false? width: Applies to: all elements but non-replaced inline elements, table-rows, and row groups height: Applies to: all elements but non-replaced inline elements, table columns, and column groups block-progression-dimension: Applies to: see prose [no fo:block mentioned] inline-progression-dimension: Applies to: see prose [no fo:block mentioned] > Some contradiction? The boxes describing width and height are copied straight out of CSS2, so I agree that it looks like a contradiction, but my opinion is that the list of properties that apply to an FO takes precedence over the text in the boxes. > Max? Anyone else from the working group listening? > Arbitration please. This is my opinion, not the working group's. > I'm going with 7.14.12 as the contra position. I am not. For 'width' and 'height', below the box, it says [[XSL modifications to the CSS definition: In XSL, this property is mapped to either "inline-progression-dimension" or "block-progression-dimension"]] For those two properties there is no contradiction, as 7.14.1 says "This property specifies the block-progression-dimension of the content-rectangle for each area generated by this formatting object." This doesn't specify which FO the property applies to so we can take from the listed properties for fo:block that it doesn't apply.
Disposition: Accepted (clarification)
Clarifying text will be added.
Erratum, Section 7.2:
Add:
at the end of the first paragraph:
The normative "applies to" information in XSL is given with the formatting objects instead of with the formatting properties.
Max.
Message-Id: <4.3.2.7.2.20021202165051.022ad698@172.27.10.30> Date: Mon, 02 Dec 2002 16:55:54 -0600 To: xsl-editors@w3.org From: Paul Grosso <pgrosso@arbortext.com> Subject: use of body-start() outside lists
The XSL spec says [1]:
Function: numeric body-start()
The body-start function returns the calculated body-start
value for lists. See the definition in [7.28.4
"provisional-distance-between-starts"].
NOTE:
When this function is used outside of a list, it still
returns a calculated value as specified.
However, the defn at [2] says:
body-start() = the value of the start-indent + start-intrusion-adjustment
+ the value of the provisional-distance-between-starts of the
closest ancestor fo:list-block.
If the defn of body-start() refers to the value of the
provisional-distance-between-starts of the closest ancestor
fo:list-block, then how could it "still return a calculated
value as specified" when used outside of a list? And what
is the point of doing such?
It seems to me that the NOTE in [1] should be deleted.Disposition: Accepted (bug in spec)
Erratum, 5.10.4:
Delete:
the note in the definition of the body-start() function
Erratum, 7.28.3:
Add:
after the current text a new paragraph:
If there is no ancestral fo:list-block, the value used for the provisional-label-separation and provisional-distance-between-starts in the above formula shall be equal to inherited-property-value(provisional-label-separation) and inherited-property-value(provisional-distance-between-starts) respectively of the FO in which the body-start() function is evaluated.
Erratum, 7.28.4:
Add:
after the current text a new paragraph:
If there is no ancestral fo:list-block, the value used for the provisional-distance-between-starts in the above formula shall be equal to inherited-property-value(provisional-distance-between-starts) of the FO in which the body-start() function is evaluated.
paul [1] http://www.w3.org/TR/xsl/slice5.html#section-N8624-Property-Value-Functions [2] http://www.w3.org/TR/xsl/slice7.html#provisional-distance-between-starts
Message-ID: <3DF8B215.3000509@multiconn.com> Date: Thu, 12 Dec 2002 17:58:13 +0200 From: Oleg Tkachenko <olegt@multiconn.com> To: xsl-editors@w3.org Subject: 5.8. Unicode BIDI Processing Hello! Small comments about 5.8. Unicode BIDI Processing[1]:
1. 5-th paragraph: The definition of when text reordering step is done is a little bit confusing - it's stated that "First, the final, text reordering step is not done during refinement. Instead, the XSL equivalent of re-ordering is done during formatting." But "refinement" itself is defined as "second phase in formatting" in 1.1.2.
Disposition: Accepted (clarification)
"formatting" should be replaced with "area tree generation" to make it clear during which phase of "foratting" this takes place.
Erratum, Section 5.8:
Replace:
"formatting" in the third sentence of the 5th paragraph
with
area tree generation
2. A typo in the same paragraph: "...properties that were either specified on inline formatting objects generated by tree construction or are are on inline formatting objects...".
Disposition: Accepted (editorial)
Erratum, Section 5.8:
Replace:
"are are" in the last sentence of paragraph 5
with
are
4. Last Note mentions "Key property", which is not defined in the Recommendation.
Disposition: Accepted (bug in spec)
That part of the sentence should be deleted.
Erratum, Section 5.8:
Delete:
in the last Note: "or Key property"
[1] http://www.w3.org/TR/xsl/slice5.html#section-N6720-Unicode-BIDI-Processing -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel
Message-Id: <3.0.5.32.20021216081406.00ab3140@mailsj-v1.corp.adobe.com> Date: Mon, 16 Dec 2002 08:14:06 -0800 To: xsl-editors@w3.org From: Stephen Deach <sdeach@adobe.com> Cc: chris@w3.org Subject: z-index property
Are items with z-index="0" is drawn in-front or behind those with z-index="1". XSL-1.0 cites the CSS-2 spec, but I can't find clarification in CSS-2.
Disposition: Explanation of XSL spec
An item with a z-index=1 is drawn on top of (and thus obscures) another item with a z-index=0.
XSL 1.0 has a section explicitly describing how areas are rendered (Section 4.9, "Rendering model"). For this issue, consult subsection 4.9.6, "Layering and Conflict of Marks".
Also, is there an implied drawing order if 2 items with the same z-index overlap? or may they be drawn in any order. (Many existing formatters do this in differing orders, it may be hard to enforce, but might be useful to suggest an ordering.)
Disposition: Explanation of XSL spec
The last paragraph of that subsection 4.9.6 implies that this is a (recoverable) error, with recovery by drawing the marks from the first area (in the pre-order traversal order) beneath those of the other area.
---Steve Deach sdeach@adobe.com
Message-Id: <5.2.0.9.0.20030122065031.00ba81e0@pop.storm.ca> Date: Wed, 22 Jan 2003 07:13:12 -0500 To: XSL Editors <xsl-editors@w3.org> From: "G. Ken Holman" <gkholman@CraneSoftwrights.com> Cc: Paul Grosso <pgrosso@arbortext.com> Subject: Re: Fwd: Spanned cells pending beyond the row group At 2003-01-21 14:48 -0600, Paul Grosso wrote: >Do I have your permission to forward a copy of Nikolai's email >to the public xsl-editors comments list so that we have a public >record of this issue? Paul (and others on the XSL Editors list), You have my blanket permission to quote any of my messages on XSL Editors if you think it will help forward discussions. Waiting for me to reference any particular issue may delay your work. CC'ing me will help me know that it has been done, but you don't have to wait if you think it will help. >[Alternatively, feel free to send something yourself to xsl-editors >about this.]
In a very large UBL-related stylesheet laying out a paper form on a 33x17 grid, I spanned rows without heed of table-body boundaries. I assumed that multiple table bodies were merely "syntactic" methods of using different row-grouping strategies at different stages of table body building, but that regardless of which method to *specify* the cell contents, the spanned rows from cells in higher rows worked in the table as a whole, not limited to the table body in which the spanning was done. In my example, the left-most column spanned all 33 rows because it had some marginalia rotated at 90 degrees, and the top-most row spanned the remainder of the 32 columns because it had title information. This left 16 columns by 32 rows to lay out the fields of the form. I needed different row-groups because of the logistics of the source data, so I wrote three table-body constructs, one for the top 12 rows, another for the middle 8 rows, and the third for the bottom 12 rows. My intuition was that table-body constructs where merely mechanisms for expressing the contents of cells, the choice available based on the algorithms of the stylesheets, but that the table-body boundaries were "invisible" to the user, and essentially "invisible" to me the stylesheet writer. My 33-row span of my marginalia was specified in the first table-body and the other table-bodies respected that because the first table-body had sufficiently accommodated the first column of each of the rows. My stylesheet was certainly a lot easier doing it the first way ... to find common behaviour between the two implementations I had to nest a table in a table, where the outside table has the marginalia and the title, and the inside table is the 32x16 grid that I need for the form. I can see any of Nikolai's three interpretations as being acceptable, though it was more work and less intuitive to me to have to accommodate table-body borders at all.
Disposition: Accepted (bug in spec)
Such a specification is an error.
Erratum, Section 6.7.3:
Replace:
the last paragraph and the last note under "Constraints"
with
It is an error if two table-cells overlap or if a table-cell would extend beyond the current table row group (i.e., the current table-body, table-header, or table-footer).
NOTE:
Such overlap could be due to the same column-number being assigned to two different cells in the same row, or due to column or row spanning causing an overlap. A table-cell might extend beyond the current table row group by having a number-columns-spanned or number-rows-spanned value that is larger than the remaining number of columns or rows in the spanned direction.
Nikolai's post cited by Paul continues below. Good luck with this one! .......................... Ken >paul > > >From: "Nikolai Grigoriev" <grig@renderx.com> > >To: <w3c-xsl-fo-sg@w3.org> > >Date: Tue, 21 Jan 2003 01:32:05 +0300 > >Subject: Spanned cells pending beyond the row group > >X-Archived-At: http://www.w3.org/mid/01a301c2c0d3$c84dce90$7f01000a@grig > > > >Hello, > > > >in a private mail, Ken Holman signalled one more FO-related issue. > > > >Situation: a fo:table-cell with @number-rows-spanned > >extends below the last fo:table-row element in a row group, > >like in the example below: > > > > <fo:table-body id="body1"> > > <fo:table-row height="2in"> > > <fo:table-cell><fo:block>A1</fo:block></fo:table-cell> > > <fo:table-cell number-rows-spanned="2"> > > <fo:block>A2</fo:block> > > </fo:table-cell> > > </fo:table-row> > > </fo:table-body> > > > > <fo:table-body id="body2"> > > <fo:table-row height="2in"> > > <fo:table-cell><fo:block>B1</fo:block></fo:table-cell> > > </fo:table-row> > > </fo:table-body> > > </fo:table> > > > >How should a formatter behave? Ken Holman could not find > >an answer in the spec, and neither could I. Alternatives > >known to me (and implementations using them): > > > >1. Let cells leak into the next row-group (Antenna House); > > > >2. Pad the row group with empty fo:table-rows (RenderX); > > > >3. Reduce @number-rows-spanned at the offending cells > >so that the cell fits completely into the existing rows. > >This is inspired by the following quote in CSS2 > >[17.5 Visual layout of table contents]: > > > >CSS> 6. A cell box cannot extend beyond the last > >CSS> row box of a table or row-group; the user agents > >CSS> must shorten it until it fits. > > > >Personally, I an inclined to prefer the third, CSS2-style option: > >in this case, we have a better alignment with HTML table model. > >IE6 and Opera 7 use this method (though Opera 6 does not). > > > >Whichever option we choose, it looks reasonable to put a notice > >to [6.7.10. fo:table-cell] or [7.26.14. "number-rows-spanned"] > >(or both). > > > >Best regards, > >Nikolai Grigoriev > >RenderX -- Upcoming hands-on in-depth Europe: February 17-21, 2003 XSLT/XPath and/or XSL-FO North America: June 16-20, 2003 G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) ISBN 0-13-065196-6 Definitive XSLT and XPath ISBN 0-13-140374-5 Definitive XSL-FO ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath ISBN 1-894049-10-1 Practical Formatting Using XSL-FO Male Breast Cancer Awareness http://www.CraneSoftwrights.com/f/bc
Message-ID: <3E428924.8040009@powerup.com.au> Date: Fri, 07 Feb 2003 02:11:16 +1000 From: "Peter B. West" <pbwest@powerup.com.au> To: xsl-editors <xsl-editors@w3.org> Subject: Questions about markers Background: Processing of large FO documents is both cpu and memory intensive. The volume of property information is partly responsible for the memory requirement. In order to minimise this demand, I want to be able to divide the property construction into two phases with different requirements. 1. The construction of individual branches of the FO tree. During this phase, as tree building proceeds down a particular branch towards a leaf node, the ancestor nodes of that leaf are constructed without knowledge of the requirements of descendants. Therefore, no optimisaton is possible of the set of properties which must be maintained at each ancestor node. Whether a particular specified or inherited property is required by an individual ancestor node, a full set of properties must be developed and maintained (at least conceptually) until the inheritance and functional reference requirements of the last descendant have been determined. These sets are constructed as control descends down the tree, making the set available to each child and its descendants. 2. As control retreats back up the tree, having constructed the property sets of each of its descendants, there is no further need for any but the actual properties pertaining to each individual node. This allows for considerable space (and subsequent performance) optimisations, by, e.g., reducing the applicable property set to the minimum required by the FO, and maintaining that set in an array of predetermined length, whose elements can be accessed by a mapping array, whose length and contents are predetermined. This neat and compact arrangement may be disturbed by the presence of markers. Markers do not inherit from their FO tree ancestors, but from their ancestors determined in the Area tree. The properties of retrieved marker subtrees are necessarily resolved in the context of the Area tree; the marker retrieved at a certain point is determined by the status of the Area tree construction. Given this close connection with the Area tree, I wish to have clarified the environment of expression resolution for markers, in particular as it affects inheritance and the from-nearest-specified-value() function.
Questions: Is this environment conceptually akin to that which would obtain were the fo:marker subtree transposed to the position in the FO tree occupied by the fo:retrieve-marker during phase 1 of FO tree construction? In this case, all properties specified and inherited are available to "normal" inheritance and to the core functions. Is it akin to that which would obtain were the fo:marker subtree transposed to the same position in the FO tree following phase 2, as described above? In this case, only properties which were relevant to particular FOs would be retained. The point at which a property was specified would be lost if it were not relevant at the point of specification. Is it rather the environment which derives from the traits of the Area tree at the point of attachment? This case is similar to the one above, in that information about properties which had no prior point of application would be lost before the fo:marker subtree properties were resolved.
Disposition: Explanation of XSL spec
The interpretation given in the first paragraph is the correct one, which is what we're trying to say in the spec when it says (under Trait Deriviation for 6.11.4 fo:retrieve-marker [1]):
"The properties and traits specified on the ancestors of the fo:retrieve-marker are taken into account when formatting the children of the retrieved fo:marker as if the children had the same ancestors as the fo:retrieve-marker."
(This does mean that inheritance and property function evaluation does sometimes depend on what happens during the formatting and pagination process.)
Peter -- Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?"
Message-ID: <3E428B8C.3060709@powerup.com.au> Date: Fri, 07 Feb 2003 02:21:32 +1000 From: "Peter B. West" <pbwest@powerup.com.au> To: xsl-editors <xsl-editors@w3.org> Subject: Percentages + absolute lengths
Please clarify the editors' expectation for the resolution of an expression like "25% + 3pt" an FO where the relative value is resolved in terms of an enclosing reference area. The difficulty with respect to such expressions that I have experienced in implementing FO tree building is that they force property resolution into dependency on Area tree construction. Even in the simplest cases, the evaluation of such expressions assumes the availability of page-based information, as opposed to the FO tree's flow and static-content view. I those cases where the dimensions of areas may be dependent on look-ahead layout and retries, e.g. during attempts to resolve column widths for "auto" column layout, the dependency becomes even more tortuous. The end result is that such expressions must be carried around in the constructed FO tree, and only resolved as the applicable FO's areas are generated and returned, or re-generated and returned. This greatly complicates the expression parsing which must be done early for the FO tree building to be able to proceed. While a simple percentage, e.g., "25%", suffers from the same uncertainties, it can at least be reduced to a single datum, whose resolution makes no further demands of the expression parser, which in turn simplifies the parser. My current implementation of FO tree building rejects expressions such as "25% + 3pt" on the basis that (part of) "...the expression value cannot be converted to the necessary type for the property value," (5.9.12) within the context of the building of the FO tree. This is in spite of the fact that the spec states, fatuously in my view, that, "Properties are evaluated against a property-specific context. This context provides: ... Conversions from relative numerics by type to absolute numerics within additive expressions." The context of this conversion is not property-specific as much as area-tree specific.
Disposition: Explanation of XSL spec
This is true. Some uses of percentages do require feedback from the result of area tree construction.
We may consider making a modification to XSL 1.1 that makes the handling of percentages in places that require dependency on composition part of extended level conformance, but leaves the handling of those that can be computed before formatting as part of the base conformance level.
Peter -- Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/ "Lord, to whom shall we go?"
Message-ID: <3E452585.7060106@re.be> Date: Sat, 08 Feb 2003 16:43:01 +0100 From: Werner Donn頦lt;werner.donne@re.be> To: xsl-editors@w3.org Subject: Deviation margin-left and margin-right from CSS Hi,
The margin-left and margin-right properties are taken over from CSS. However, they don't completely behave as in CSS. More specifically the value "auto" is treated differently. Section 5.1.2 states that for auto values the formulas must be applied. In this case it would be the last two formulas of section 5.3.2. As a consequence, it is the same as if margin-left or margin-right were absent. The auto value is not treated as an explicit value. In my opinion it should be and it should be computed according to the CSS rules, from which the properties are taken over, even if that implies an exception to the indentation rules. I see no point in being only partially compatible with CSS properties. A practical consequence, for example, is that a fixed-width block which is stacked in another block can't be centered through setting the margin-left and margin-right properties to "auto", such as it is the case in CSS. The same goes for aligning the stacked block to the left or right.
Disposition: Accepted (clarification)
We do reference the CSS spec and don't override this part of it, so our behavior should be the same as CSS when margin-{left,right} is set to auto. However, we agree the XSL spec isn't clear in this area, so we will clarify it.
Erratum, Section 5.3.2:
Add:
in the second paragraph, after the second note, before "The formulae...":
The computed value of the of the absolute "margin" property is determined by the CSS descriptions of the properties and the relevant sections (in particular section 10.3) of the CSS Recommendation referenced by these properties.
Regards, Werner. -- Werner Donn頠-- Re BVBA Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be
From: Eric Bischoff <e.bischoff@noos.fr> To: Paul Grosso <pgrosso@arbortext.com>, asandstrom@accesswave.ca, olegt@multiconn.com, gkholman@CraneSoftwrights.com, eliot@isogen.com, daveP@dpawson.freeserve.co.uk Date: Sat, 22 Feb 2003 09:20:46 +0100 Cc: xsl-editors@w3.org Message-Id: <200302220920.46431.e.bischoff@noos.fr> Subject: Re: Updated public XSL (FO) Disposition of Comments document -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Saturday 22 February 2003 00:01, Paul Grosso a 飲it: > The public XSL (FO) Disposition of Comments document at > http://www.w3.org/Style/XSL/2003/01/FO-DoC > has just been updated with responses to your comments. > If you are unsatisfied with the response, please feel > free to post another comment to xsl-editors@w3.org. > > Thank you for your interest in XSL FO and for your > patience as we work our way through the comments. > > Paul Grosso > for XSL FO Subgroup Hi Paul, Nice compilation Work.
However I'm still unhappy with the comments of one of my contribs : ================================================== No the erratum is correct. The quotes around the "string" are optional and have been left out in the example. The enclosing single quotes ensure that the value is interpreted as a string literal by the expression language. Note that "url" is not a function, but a piece of syntax borrowed from CSS2. ================================================== Okay with that, but it contradicts the spec then (perharps it's just a bug in the spec) : At http://www.w3.org/TR/xsl/slice7.html#src one can read : ================================================== 7.28.7 "src" XSL Definition: Value: <uri-specification> | inherit ================================================== Please note that it does not accept a <string>, but an <uri-specification> It's been a long time I wanted to tell you that, but I lacked time to do it. Sorry about that. So I think that that issue is still unclosed.
Disposition: Explanation of XSL spec
<string> is any arbitrary string; a valid value for "src" has to follow certain specific rules specified for <uri-specification>.
I hope it helps. PS Most people know the stylesheets standard as "XSL-FO". I advise that it gets reflected in the standard's title as well (currently it's "XSL"). PPS The current standard is uselessly complicated : too much exceptions, too much special cases, not enough uniformity. I would say that it would be great if it could evolve to become much more orthogonal in the next versions. For example, url() and rect() should become functions like any other in next versions. All units should be processed in an uniform way. Etc. - -- According to a recent survey, 82% of the citizens of the European Union are against American planned invasion of Irak. (EOS Gallup Europe, 15,080 people aged 15+, 21st to 27th January 2003) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+VzLefYJTRPWp6rkRAtbqAJ9y9ho+ZmuVycUK4+vs26CW2dI5PgCeI6pd JI38VPTIjrilFOolLZ6Ockg= =ifL4 -----END PGP SIGNATURE-----
Message-Id: <5.2.0.9.0.20030310110030.03327710@junk> Date: Mon, 10 Mar 2003 11:11:34 -0500 To: XSL Editors <xsl-editors@w3.org> From: "G. Ken Holman" <gkholman@CraneSoftwrights.com> Cc: PIERRES@hthk.com Subject: Need for repeatable subsequence specifier in page sequence masters Dear XSL editors,
Following a discussion online regarding the need to pattern a collection of
simple-page-master page geometries, I'd like to request a future version of
XSL-FO consider a new construct to indicate the repetition of an arbitrary
collection of sub-sequences.
http://xep.xattic.com/lists/xep-support/0742.html
This new wrapper would be a sub-sequence specifier whose children are
sub-sequence specifiers, as in the following example:
<new-construct-here maximum-repeats="no-limit|<number>|inherit">
<single-page-master-reference master-reference="page-1-of-4"/>
<single-page-master-reference master-reference="page-2-of-4"/>
<single-page-master-reference master-reference="page-3-of-4"/>
<single-page-master-reference master-reference="page-4-of-4"/>
</new-construct-here>
I would think that any sub-sequence specifier (including this new
construct) could be a child of this new construct.Discussion message: http://xep.xattic.com/lists/xep-support/0742.html
At 2003-03-07 14:56 +0800, PIERRES@hthk.com wrote:
>I had a question previously posted to xsl-list and the answer I got was to
>use extension features.
I missed the post on XSL-List and would have commented there. I just found
the message in an archive, so I will post my answer below to that list as
well since there will be readers on that list that are not on this
list. Sorry for the duplication.
I don't think you need an extension if you are willing to accept a limit.
>So I want to have your advices about any solution of my problem using XEP.
>
>I need to print some horizontal bar on left edge of every pages of a bill
>statement which is used to be read by folding machine.
>The folding machine will use these bars to detect some information for the
>folding processing. (e.g. page sequence, account sequence)
>Then the machine will fold the pages for one account into an envelope.
>
>For each account, I need to specify a page sequence no. for each page.
>There are four bars, they have values 1, 2, 4 and 8, I can print, and the
>total of their values should equal to the page sequence no.
>The page sequence no. start from 1 for page 1 to 15 for page 15, then reset
>to 1 for page 16 etc.
I would have thought that page 16 would have zero bars and that page 17
would have been reset to 1 ... but my solution stands if the answer goes
either way.
If you don't mind having some "typically maximum limit" and then
accommodating an overflow condition ... say you accept a 256 page limit ...
that no bill will be longer than 256 pages and that if there is one that is
257 or more pages that you accept the XSL-FO formatter throwing an error to
signal the pages were not totally completed.
Create as many <simple-page-master>s as you have combinations of bars (so
either 15 or 16 based on the answer above ... I'll assume 16). Each
<simple-page-master> has a different <region-start> name, say "region-0"
through "region-15".
Create a <page-sequence-master> with 256 <single-page-master-reference>
children, in order pointing to masters respectively with
"region-0",...,"region-15","region-0",...,"region-15", etc.
Create your <page-sequence> pointing to the <page-sequence-master> and
including 16 definitions of <static-content> one for each of the 16
combinations of bars, with absolutely positioned block containers with a
<leader> rule in each positioned where you want the folding marks.
Then go ahead and format the document! If there are 257 pages in the one
bill, the formatter will abend and indicate that it has run out of page
geometries for the formatting run. But as long as there are enough
single-page-master-references in your page-sequence-master, it will not
abend and you will get the pattern of marks in the edge of your paper.
Yes, it would be cleaner and there would be no limit if there were a
sub-sequence-repeater object in XSL-FO (how about that as a new requirement
for version 2?) but if you can accept the maximum page count and I've
understood your requirement then I think you've got what you need.
I hope this helps.
........................... Ken
--
Upcoming hands-on in-depth XSLT/XPath and/or XSL-FO
North America: June 16-20, 2003
G. Ken Holman mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6 Definitive XSLT and XPath
ISBN 0-13-140374-5 Definitive XSL-FO
ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1 Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/f/bc
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
Disposition: Future XSL version
This request for new functionality will be considered for a future (post 1.1) version of XSL.
I hope this helps!
............... Ken
--
Upcoming hands-on in-depth XSLT/XPath and/or XSL-FO
North America: June 16-20, 2003
G. Ken Holman mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
ISBN 0-13-065196-6 Definitive XSLT and XPath
ISBN 0-13-140374-5 Definitive XSL-FO
ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1 Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/f/bcMessage-ID: <3E6F48A0.408@isogen.com> Date: Wed, 12 Mar 2003 08:48:00 -0600 From: "W. Eliot Kimber" <eliot@isogen.com> To: xsl-editors@w3.org CC: support@antennahouse.com, xep-support@renderx.com Subject: Clarrification Needed: Implications of writing mode on region-body Editors,
There is disagreement between XSL Formatter and XEP over the implication of setting writing-mode on region-body and my reading of the spec cannot find a clear justification for either interpretation. In section 7.27.7, the definition of the writing-mode property, the spec says: <quote> o When "writing-mode" is applied to the fo:region-*, it defines the column-progression within each 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). o To change the "writing-mode" within an fo:flow or fo:static-content, either the fo:block-container or the fo:inline-container, as appropriate, should be used. </quote> With XEP, setting writing-mode on region-body only changes the positions of the columns on the page--it does not affect the writing mode of the areas within the flow contained within the region body. With XSL Formatter, the writing mode is propagated to the areas within the region body.
[See the original posting for the rest of its text.]
Disposition: Explanation of XSL spec
Setting writing-mode on simple-page-master or region-* affects only the placement of page regions or columns and does not determine the default writing mode of any contained areas; the value used is the one specified, or inherited in the FO tree, on fo:flow and descendants.
Message-Id: <4.3.2.7.2.20030313055905.00b78fa8@172.27.10.30> Date: Thu, 13 Mar 2003 05:59:46 -0600 To: xsl-editors@w3.org From: Paul Grosso <pgrosso@arbortext.com> Subject: NCName -> QName in property functions
In 5.10.4 Property Value Functions at [0], all the functions (except proportional-column-width()) say they take an NCName (as defined at [1] in the Namespace spec) as an argument. However, I think it makes more sense for this to be a QName (as defined at [2] in the Namespace spec); that is, something that could have an optional namespace prefix. This would match what an XML attribute name can be which would be a logically more correct situation. (An attribute name is defined as "Name" [3] in the XML spec at [4], but the Namespace spec makes it clear at [5] that all "constructs corresponding to the nonterminal Name" in the XML spec are really QNames as opposed to NCNames.) The problem with what we have now can be seen when you consider that a user might want to use an extended property in one of these functions. An extended property has to be in another namespace, but then it has to be prefixed. But then you can't put it into any of these property functions as currently restricted. I think this is just an erratum, and we should change these function definitions to say they take a QName. This is an upward compatible change and allows users to use extended properties in these property value functions.
Disposition: Explanation of XSL spec
We want NCName here on purpose, because if we allowed QName, it would make it more likely that a stylesheet using such extensions would not be able to produce output when run in an implementation that doesn't understand this extension. We note that the spec says nothing about what can be in the value of an extended property, so it is not disallowed for the value of an extended property to include the ability to use what look like XSL property functions that take QName values.
paul [0] http://www.w3.org/TR/2001/REC-xsl-20011015/xslspec.html#section-N8624-Property-Value-Functions [1] http://www.w3.org/TR/REC-xml-names#NT-NCName [2] http://www.w3.org/TR/REC-xml-names#NT-QName [3] http://www.w3.org/TR/REC-xml#NT-Name [4] http://www.w3.org/TR/REC-xml#NT-Attribute [5] http://www.w3.org/TR/REC-xml-names#dt-qname
Message-ID: <3E86AD90.6030509@multiconn.com> Date: Sun, 30 Mar 2003 10:40:48 +0200 From: Oleg Tkachenko <olegt@multiconn.com> To: xsl-editors@w3.org Subject: more BIDI comments Hello! Some more comments about "5.8 Unicode BIDI Processing" [1]:
1. The example in the last note uses "ID" attribute, instead of "id".
Disposition: Accepted (editorial)
Erratum, Section 5.8:
Replace:
"ID" (three occurences) in the example in bullet item 2.B.
with
id
2. 6-th paragraph mentions "override" instead of "bidi-override" as a value of the "unicode-bidi" property.
Disposition: Accepted (editorial)
Erratum, Section 5.8:
Replace:
"override" in the sixth paragraph:
with
"bidi-override"
3. The algorithm, described in "5.8 Unicode BIDI Processing" doesn't say how inline formatting objects like fo:external-graphics or fo:leader should be treated with respect to BIDI processing. I think it should be explicitly stated, that according to BIDI algorithm they should be treated as OBJECT REPLACEMENT CHARACTER (U+FFFC): "For the purpose of the bidirectional algorithm, inline objects (such as graphics) are treated as if they are an OBJECT REPLACEMENT CHARACTER (U+FFFC)."[2]
Disposition: ***TO BE DONE***
[1] http://www.w3.org/TR/xsl/slice5.html#section-N6720-Unicode-BIDI-Processing [2] http://www.unicode.org/unicode/reports/tr9/ -- Oleg Tkachenko http://www.tkachenko.com/blog Multiconn Technologies, Israel
Message-Id: <5.2.0.9.0.20030410093157.00b7a120@junk> Date: Thu, 10 Apr 2003 09:56:33 -0400 To: XSL Editors <xsl-editors@w3.org> From: "G. Ken Holman" <gkholman@CraneSoftwrights.com> Subject: Differing interpretations of whitespace collapsing Good morning!
Two vendors produce different results for the following test:
<flow flow-name="frame-body" font-family="Times" font-size="20pt">
<block>x x x x</block>
<block>x <basic-link external-destination="url('test')">
x</basic-link> x x</block>
</flow>
One vendor collapses the spaces in the second block such that all the "x"s
line up vertically. Another vendor preserves two spaces between the first
two "x"s of the second block, thus the "x"s do not line up vertically.
I desire what the first vendor does: collapse the whitespace such that the
"x"s line up ... but I cannot find text in the spec to defend that position
to the second vendor.
I distilled this from my training material where I have in my XML:
<text>And for details see: <ref idref="x"/> for more information
...
<x>
Title <m>with embedded</m> here</x>
Note how I use a single space around each side of the <ref/>. I want the
leading linefeed of the title to be tossed, but I cannot use XSLT's
normalize-space() on the text node as that would abut the words "Title" and
"with".
According to the spec, should the "x"s line up vertically in my test above?
Disposition: Explanation of XSL spec
According to the current spec as clarified by the discussion on "immediately preceding" in the 2002 October 22 SG Comment document in response to comment 5 item 1, the current situation is that the spaces in this example should not collapse.
Thanks for your help! ................. Ken -- Upcoming hands-on courses: Europe (XSLT/XPath): May 5, 2003 - Europe (XSL-FO): May 16, 2003 - (XSLT/XPath and/or XSL-FO) North America: June 16-20, 2003 G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) ISBN 0-13-065196-6 Definitive XSLT and XPath ISBN 0-13-140374-5 Definitive XSL-FO ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath ISBN 1-894049-10-1 Practical Formatting Using XSL-FO Male Breast Cancer Awareness http://www.CraneSoftwrights.com/f/bc
From: "Victor Vishnyakov" <tch_@mail.ru> To: <xsl-editors@w3.org> Date: Tue, 22 Jul 2003 16:44:14 +0300 Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAYMl6iFgB402mZDZojzVrDcKAAAAQAAAAqOyhZABiwEW2Ks2eYSby9wEAAAAA@mail.ru> Subject: Why does fo:page-number and fo:page-number-citation not have color attribute?
subj.
Disposition: Explanation of XSL spec
Specifying e.g. color="red" on a fo:page-number or fo:page-number-citation is the way to specify color to be applied to the number.
Technically, however, this is achieved by inhertiting the color specification from the fo:page-number or fo:page-number-citation to the fo:character objects, to which "color" applies", representing the page-number.
Message-ID: <3F1FCECB.3070306@re.be> Date: Thu, 24 Jul 2003 14:19:23 +0200 From: Werner Donn頦lt;werner.donne@re.be> To: xsl-editors@w3.org Subject: Measurement unit ex Hi,
XSL-FO uses the x-height notion. Why then isn't there the relative measurement unit "ex"?
Disposition: Explanation of why no change will be made
The XSL-WG intentionally disallowed the measurment unit ex, since it is not well-defined noe uniformly-defined for most vendor's fonts and since an ex unit does not exist on fonts/languages that do not have lower-case characters.
Regards, Werner. -- Werner Donn頠-- Re BVBA Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be
From: Mazza, Glen R., ,CPMS <glen.mazza@cpms.osd.mil> Date: Wednesday, 14 January, 2004 18:36 To: xsl-editors@w3.org Subject: XSL 1.1 WD comment: The properties which may be attached to an F O.
Hello, I'm Glen Mazza of Electronic Data Systems and of the XML Apache FOP Project. I'm unsure, after reading the 1.1 Working Draft of the XSL Specification, about the set of properties which may be attached to an FO. The Introduction and Overview, Section 1.1.2 Formatting [1], gives this statement: "Although every formatting property may be specified on every formatting object, for each formatting object class, only a subset of the formatting properties are used to determine the traits for objects of that class." Section 5.1.4, Inheritance [2], gives this rule: "The inheritable properties can be placed on any formatting object." [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#d0e178 [2] http://www.w3.org/TR/2003/WD-xsl11-20031217/#inheritance Two comments on these statements:
1.) 5.1.4's statement seems to contradict 1.1.2's by implying that noninheritable properties cannot be placed on every formatting object. If 1.1.2's statement is correct, however, it would be better for the reader if 5.1.4's were written more unambiguously as: The inheritable properties, like all properties, can be placed on any formatting object.
Disposition: Accepted (clarification) ERRATUM TO BE ADDED
As discussed previously in email, it is the case that any property can be placed on any FO, though only certain properties apply to certain FOs.
2.) The rule given by 1.1.2--every property can be attached to every FO--is very significant for implementors, and should not be limited to just a subordinate clause of a sentence in the introduction. Of course, introductions should not be the only place where a specification rule is given. Somewhere in the body of the specification this rule should be explicitly stated--absent such an statement, I'm not getting a "firm handshake" from the authors about this rule--causing me to think that 5.1.4's current statement is what they were intending. (But I may be wrong here--I may have missed the section where this rule was explicitly stated. Apologies if this is the case.)
Disposition: Accepted (clarification) ERRATUM TO BE ADDED
See response above.
Thanks, Glen Mazza EDS glen.mazza at eds.com
From: <komachi@y-adagio.com> Date: Sat, 17 Jan 2004 23:00:31 +0900 To: xsl-editors@w3.org Subject: Comments on XSL1.0
Dear XSL-Editors, Attached you will find the JSA(Japanese Standards Association)/EPCom(Committee for Electronic Publishing)'s submission on
- requirements for various extensions to XSL1.0
Discussion message: http://lists.w3.org/Archives/Public/xsl-editors/2004AprJun/0001.html
Disposition: Some accepted for XSL 1.1, others filed for Future XSL version
Regarding document meta data (document-info), one can use namespaced elements--perhaps even those from Dublin Core--to give document meta data, most likely inserting them into fo:declarations (see 6.4.3). We plan no further work in this area in 1.1 because the mechanism is already there, and we don't want to get into standardizing meta-data.
We have added Bookmarks to XSL 1.1. As far as outline-order, the bookmark order in our XSL 1.1 fo:bookmark feature is determinable by the XSLT code.
The XSL FO SG has decided not to add footnote-position and suppress-duplicate-footnote extensions to XSL 1.1, but to record them as possible post 1.1 features.
We have added to XSL 1.1 a change bar feature that covers the revision bar requirement.
The XSL FO SG has decided not to add a column rule feature to XSL 1.1, but to record it as a possible post 1.1 feature.
Background color/image on simple-page-master has been determined to be post 1.1 potential feature.
physical-page-number aka ordinal-page-number (but perhaps by a different name) has been determined to be post 1.1 potential feature. We would probably address this requirement by adding a property to page-number and page-number-citation.
The requirement for suppress-duplicate-page-numbers is addressed by our XSL 1.1 indexing feature.
Text treatment a la CSS3 text module is a potential post 1.1 feature.
Allowing a list-item-label position of inside/outside is a potential post 1.1 feature.
Incorporation of xml:base into XSL would presumably affect all attributes of type <uri-specification>. The actual request is to affect the external-destination of fo:basic-link, but use of xml:base would affect the absolutization of external-destination at FO processing time, and that does not address the use case of being able to relocate the result of an XSL-FO run. After much discussion, the XSL FO SG decided not to do anything about xml:base in XSL 1.1.
Regarding soft-hyphen-treatment, our experts tell us that this is a misuse of the Unicode soft hyphen character. There should be no glyph assigned to U+00AD as the semantics for this Unicode character is that of a soft hyphen.
We have added clear/float values of inside/outside to XSL 1.1.
Floats of type after, in-column, mid-column are potential post-1.1 features.
The "extra" writing mode values (and more) are listed in Appendix A of the XSL specification.
Best Regards, Yushi Komachi (Convener of EPCom/WG1) ------------------------------------------------------------------ Yushi Komachi Panasonic Communications Co., Ltd. 2-3-8 Shimomeguro, Meguro-ku, Tokyo 153-8687 Japan Phone +81 3 5434 7053, Fax +81 3 5445 3663 Email komachi@y-adagio.com
From: Glen Mazza <grm7793@yahoo.com> Date: Sun, 18 Jan 2004 20:12:17 -0800 (PST) Message-ID: <20040119041217.31774.qmail@web60110.mail.yahoo.com> To: xsl-editors@w3.org
I've finished reading the Ch. 1 Introduction of the Working Draft. I could only find a few "nitpick" suggestions, but here's what I found:
1. In Section 1.1.2, Formatting, the Diagram given in [1] below, recommend changing text from "Result XML Tree in the 'fo' namespace (element and attribute nodes)" to simply, "Element and Attribute Tree". (The latter term has already clearly been defined in bold before, and used twice before reaching this diagram, so at this stage it seems more important to clarify the precise name of the tree in question) [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/tree2-3.gif
Disposition: Explanation of why no change will be made
We prefer to be very explicit about what the trees represent.
2. In this same section, the Diagram given in [2] below, recommend switching Area Tree label from "XSL areas rendering traits" to simply "Area Tree" or "Area Tree rendering traits". [2] http://www.w3.org/TR/2003/WD-xsl11-20031217/trees4-5.gif
Disposition: Explanation of why no change will be made
We prefer to be very explicit about what the trees represent.
3. Section 1.2 [3], this sentence: "While many of XSL's formatting objects and properties correspond to the common set of properties, this would not be sufficient by itself to accomplish all the goals of XSL." Recommend changing to: "While many of XSL's formatting objects and properties correspond to *a* common set of properties, this would not be sufficient by itself to accomplish all the goals of XSL." or "While many of XSL's formatting objects and properties have equivalent counterparts in those standards, this would not be sufficient by itself to accomplish all the goals of XSL." [3] http://www.w3.org/TR/2003/WD-xsl11-20031217/#d0e253
Disposition: Explanation of why no change will be made
What is referred to is THE common set of properties between DSSSL, CSS, and XSL; not just A common set...
4. Section 1.2.1, "Paging and Scrolling" (http://www.w3.org/TR/2003/WD-xsl11-20031217/#d0e266) Change the "can be" below: In addition, the selection of XML source components that *can be* styled (elements, attributes, text nodes, comments, and processing instructions) is based on XSLT and XPath [XPath], thus providing the user with an extremely powerful selection mechanism. to "are to be"
Disposition: Explanation of why no change will be made
The "can be" refers to the components of an XML document that can be addressed by XPath.
5. Section 1.2.3, "An Extended Page Layout Model" (http://www.w3.org/TR/2003/WD-xsl11-20031217/#d0e307) Add "possibly" to the below sentence: This formatting object allows one to define independently filled regions for the body (with *possibly* multiple columns), a header, a footer, and sidebars on a page.
Disposition: Explanation of why no change will be made
The FO in question does definitely allow multiple columns to be specified.
6. Finally, if you could add pointers to this new WD on the Working Group page, it would be helpful for others to quickly find this new version: http://www.w3.org/Style/XSL/
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
A link has been added to the public XSL WG page.
Thanks, Glen __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
From: Glen Mazza <grm7793@yahoo.com> Date: Wed, 25 Feb 2004 15:43:29 -0800 (PST) Message-ID: <20040225234329.19648.qmail@web60108.mail.yahoo.com> To: XSL Editors List <xsl-editors@w3.org> Subject: Comments on Section 4 of the Specification
1.) For section 4.2.2 of the 1.1 Spec [1], Common Traits, the definition of is-reference-area is given as follows: "The Boolean trait is-reference-area determines whether or not an area establishes a coordinate system for specifying indents. An area for which this trait is true is called a reference-area." This definition of "is-reference-area" seems somewhat confusing, because the emphasis is placed on the establishment of a coordinate system, not on the fact that you can specify indents with them. (I.e., one infers a non-reference-area uses some other form of system for specifying indents rather than not being able to specify indents at all.) Perhaps this is clearer: "An area for which the Boolean is-reference-area trait is true is called a reference-area. Only reference areas may have indents specified."
Disposition: Explanation of why no change will be made
The proposed replacement text is incorrect; other areas may also have indents specified! What is "special" about reference areas is that they establish a coordinate system with respect to which descendant areas indent values refer.
2.) The definition of is-viewport-area is given in the same section. However, the specification does not appear to define the precise FOs/areas which have an is-viewport-area value of "true" -- so I'm unsure which areas are actually viewport-areas. [This is in contrast to is-reference-area, where the FO's that have this trait set to true are defined here [2], and the five FO's which generate areas having this trait are also defined ([3], for example, in the "Trait Derivation" section.)]
Disposition: Explanation of why no change will be made
Each FO that generates a viewport-area has a statement to that effect in the "Areas" section of the FO definition.
Thanks, Glen Mazza [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#area-common [2] http://www.w3.org/TR/2003/WD-xsl11-20031217/#d0e4813 [3] http://www.w3.org/TR/2003/WD-xsl11-20031217/#fo_block-container
From: Oliver Becker <obecker@informatik.hu-berlin.de> Date: Tue, 2 Mar 2004 16:40:26 +0100 (MET) Message-Id: <200403021540.i22FeQwK019040@mail.informatik.hu-berlin.de> To: xsl-editors@w3.org Subject: Typo in note of 6.4.11 Hello,
both XSL 1.0 and 1.1 contain the following note in section 6.4.11 <http://www.w3.org/TR/2003/WD-xsl11-20031217/#fo_conditional-page-master-reference> "If any page-master referenced from a conditional-page-master-reference with blank-or-not-blank="true" provides a region in which to put fo:flow content, no content is put in that region." I assume it should read blank-or-not-blank="blank"
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
It should, but in addition the Note has been deleted for other reasons...
Regards, Oliver /-------------------------------------------------------------------\ | ob|do Dipl.Inf. Oliver Becker | | --+-- E-Mail: obecker@informatik.hu-berlin.de | | op|qo WWW: http://www.informatik.hu-berlin.de/~obecker | \-------------------------------------------------------------------/
From: Robertson, Andy <Andy.Robertson@capitafhe.co.uk> Date: Thu, 4 Mar 2004 14:45:59 -0000 Message-ID: <4C3ADB9CBE128045804894AF3F27A8E2491128@fastnet.int.dolphin-cs.co.uk> To: "'xsl-editors@w3.org'" <xsl-editors@w3.org> Subject: The Formatting Object Section
http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section <http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section> This appears to refer to simple-links, whereas they only appear to work with basic-links. Is this an error?
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
There are several occurrences of fo:simple-link in the examples in section 6.6.1.1.4 Table of Contents with Leaders.
All these occurrences are typos and should be fo:basic-link.
Andy.Robertson Core Team - Author for F&HE, CAPITA Software Services Phone:01392 437356 Mob:07876 707787
From: <arnd.beissner@cappelino.de> Date: Tue, 13 Apr 2004 11:31:05 +0200 To: xsl-editors@w3.org Message-ID: <OF6672A951.528BFBBA-ONC1256E74.0067FDCA-C1256E75.00343FB9@cappelino.de> Subject: Re: recto page with blank back
> I come from the FOSI world (where this is possible) and military > applications (where this is required) and need to be able to set up > an XSL-FO application with the following condition output on an odd > page: page 43/44 blank. I am ending each chapter/work package on an > even page, which sometimes may be blank. > > Does the current spec support this? If so, can you tell me how. (I > have not been able to set this up successfully, although I have > blank pages working.) Or are there any plans for this feature? Is > it/will it be supported by vendors? I found the thread below on the > Yahoo XSL-FO group, and know this is a big requirement for Army and > Navy tech manuals. Any information will be greatly appreciated. ..... > > But I hope the XSL committee is listening or you can take the time to send > > your requirement to the xsl-editors@w... address. I think you've made a > > justification for a "next-to-last" page-position test value (though not > > being an implementer I'm not sure what the ramifications are). Wait ... > > even that won't help, because just with that you won't be able to say > > "next-to-last when last-is-blank", so it is getting too bizarre to try and > > express declaratively. Joy, I think that: 1. The current spec doesn't support this - for the reasons outlined in your quotes. One could think of a hack concerning inserting pseudo-blank pages at the start of a chapter instead of at the end, but this gets really ugly - if it works at all.
2. My suggestion for the XSL committee would be to add support for this functionality by specifying two new functions: page-number and page-number-citation with the same semantics as in the fo:page-number and fo:page-number-citation elements. Also, we would need a next-to-last option for the page-position property (in that case you could have a special page-master for page-position="next-to-last" and odd-or-even="odd").
Disposition: Explanation of why no change will be made
The XSL FO SubGroup discussed your email requesting new functionality to allow for a solution to "page with blank back" problem.
Several SG members think what your are suggesting is basically equivalent to asking for the resolved value of things like page numbers to be available to the XSL FO expression language. But the expression language is expected to be evaluated before page generation, so it is not possible to have page numbers available at expression language evaluation time. Certainly, even if there were certain tricks some implementations could do to get this information (such as a multiple pass method) we would not want to write something that requires a certain kind of implementation trick into the specification.
The XSL FO SG has decided not to add such an enhancement into XSL 1.1.
I don't see the mentioned issue about '"next-to-last when last-is-blank"' since "odd-or-even=odd" already does that for you in your case. One more thing: a "value" property for fo:page-number so you can specify things like "<fo:page-number ...other formatting options.... value="page-number()+1"/> I just tried it in our XSL-formatter - it's pretty easy to add if the "last" test value is already implemented (ok, make that 'reasonably implemented'), and it's also fairly straightforward to specify formally. XSL-Editors: how about that for XSL 1.1? Hope this helps, Arnd Beissner -- Arnd Bei߮er Cappelino Informationstechnologie GmbH Bahnhofstr. 3, 71063 Sindelfingen, Germany Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99 Mobile: +49-173-3016917
From: Glen Mazza <grm7793@yahoo.com> Date: Sat, 17 Apr 2004 22:27:30 -0400 Message-ID: <4081E792.2040309@yahoo.com> To: xsl-editors@w3.org Subject: Comment on 1.1 Spec, fo:conditional-page-master-reference
Editors:
For the definition of the fo:conditional-page-master-reference[1], the "Note" in this section appears inaccurate: "If any page-master referenced from a conditional-page-master-reference with blank-or-not-blank="|true|" provides a region in which to put fo:flow content, no content is put in that region." There appears to be three problems with this statement: 1.) Although the blank-or-not-blank property may *resolve* to "true", that is not an acceptable value for the property--it is limited to "blank", "not blank", "any", or "inherit". (Both in the description of this property in [1] and in [2]). If it was your intention to mean "resolve to true", you should probably remove the quotes from the above. But even so: 2.) The first of the three conditions in which this trait evaluates to true ([1], paragraph just above the Note) is when the value of the trait is "not-blank" and there are areas generated. So the Note appears to be contradicted: here, blank-or-not-blank evaluates to "true", but content *will be* put in that region. (A similar statement can be made when the value for this property is "any".) 3.) The Note appears to have the definition backwards: it is the fact that no content ended up being put in the region, along with a value of this trait being "blank" or "any", which *caused* the value of this trait to resolve to "true". Not that fact that it is "true" beforehand, and hence no content is to be put into the region. Recommendation is to remove the sentence comprising the Note.
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
The note has been removed.
Thanks, Glen Mazza FOP Team [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#fo_conditional-page-master-reference [2] http://www.w3.org/TR/2003/WD-xsl11-20031217/#blank-or-not-blank
From: Glen Mazza <grm7793@yahoo.com> Date: Sun, 25 Apr 2004 12:21:43 -0400 Message-ID: <408BE597.2070705@yahoo.com> To: xsl-editors@w3.org Subject: 1.1 WD Comments on 7.29.8 "id" property
Editors: I have two comments for the 7.29.8 "id" property definition [1] on the 1.1 XSL WD:
(1) The "initial value" for this property indicates that a machine-generated unique value should be created for each FO (for which this property applies) where not explicitly specified: "The initial value of this property is [a] random and unique identifier. The algorithm to generate this identifier is system-dependent." I'm not sure of the value of this. Although an FO Processing implementation could very well benefit from having a unique ID specified on every FO on the result tree, it doesn't appear necessary to for the specification to mandate this, as this appears to be just an internal processing issue. I can also see where an FO processor implementor, upon seeing it helpful to set an id value for every FO, might wish to use a "pseudo-property" instead of using the explicit "id" property, perhaps to avoid needing to handle duplicate ID conflicts between the machine-generated values and stylesheet-specified ones. (This would be analogous in the database world of using a hidden column for a primary key, separate from the external, nullable, unique key that the system user types in.) Recommendation is to switch to an initial value of "none". I believe this will still allow the FO processor implementor to subsequently place in machine-generated values for this property, should he/she choose, while not requiring (or necessarily encouraging) them to do so.
Disposition: Explanation of why no change will be made
The value "none" is a valid ID and cannot be the initial value.
(2) If the change in (1) above is done, then all id values will specified on the stylesheet. In this case, I would recommend adding to the "id" definition something to the effect that that it is an error for the same id value to appear more than once on the result tree.
Disposition: Explanation of why no change will be made
Thanks, Glen Mazza EDS / Apache FOP [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#id
From: Victor Mote <vic@outfitr.com> Date: Wed, 12 May 2004 22:26:55 -0600 To: "'XSL Editors'" <xsl-editors@w3.org> Message-Id: <20040513042727.21877A2CF9@frink.w3.org> Subject: marginalia use case issues
Dear XSL Editors:
The use case I would like to discuss is pretty well documented by RenderX here: http://xep.xattic.com/xep/testsuite/usecases/marginalia.pdf specifically, the second scenario listed there, which they describe as duplex marginalia. There are at least two use cases where the solution that they propose fails, and for which I don't think the XSL-FO Standard (either 1.0 or the 1.1 proposal) allows a solution. My comments assume a lr-tb page orientation: 1. The artificially-created marginalia "area" created by the maneuver described there will intrude into any footnotes that are in the same flow. The desired effect is that the footnote "area" would have precedence over the marginalia "area". 2. Other fo:float objects, such as drop caps, may be affected by the clear="both" attribute that is required for the solution, even though they are never vertically aligned (i.e. they are conceptually in different columnar parts of the page). I have some proposals regarding these issues: Predicate Issue --------------- All of the above is dependent upon the RenderX extension float="inside | outside". I would like to propose that this extension, or something functionally similar be added to the standard. #1: Footnote/Marginalia Precedence ---------------------------------- The best solution that I can think of here is to add "inside-indent" and "outside-indent" properties in all places where "start-indent" and "end-indent" are allowed, which would be mapped internally to either "start-indent" or "end-indent" depending on the odd-even/right-left value of the page. Another possible solution would be to allow the inline progression dimension properties of the footnote-reference-area (and presumably the before-float-reference) to be manipulated as part of the creation of a page-master object. There may be other solutions as well. I realize that both float="inside | outside" and inside-indent/outside-indent are probably of limited use in systems whose ipd is vertical, but I don't see that they are of any harm either. In general, it strikes me as being useful for "inside" and "outside" concepts to be applied to margins and nearly anything else that deals with "start", "end", "before" and "after" concepts. However, I do not have any use cases in mind at the moment for such features. I am not sure, but I think these items would be relatively easy for implementors to implement, at least if they already handle text-align="inside | outside". #2: Other float items --------------------- The workaround allowing marginalia creates an artificial area in the region-body for the marginalia. Within this "column", a user probably wants to keep each float clear of the others. In a situation, such as RenderX's implementation, where a float can float to the inside or outside (as well as start or end), floats must use clear="both" to get that effect. The problem is that there may be other floats on the page, that are *not* in the marginalia column, but that share either a conceptual float="start" or float="end" because of the internal mapping that would be done to get from float="inside" or float="outside". So, for example, if marginalia floats float to the inside, and the main text has drop caps that always float to the "start" side, then both of these effectively have a "start" value on odd-numbered (recto) pages. Assuming the user has kept these in different "columns", there is no possibility of collision between them, yet the needed clear="both" in the marginalia floats will not allow them to both be intersected by a line in the inline-progression-dimension. The best solution I have come up with so far is a "class" property for the float object, that would allow these floats to be conceptually segregated. Then, the "clear" property could list the class(es) that the float should be kept clear of. Alternatively (but less flexibly), the "clear" property could simply have an option that allowed it be clear of floats in its same class, perhaps clear="this-class" or clear="same".
Disposition: Explanation of why no change will be made
The XSL FO SG has necessarily limited to scope of XSL 1.1 in an attempt to get it out sooner rather than later.
We have added inside and outside to float for XSL 1.1, and that might allow you to get some of what you wants, but any further changes in this area are deemed to be beyond the scope of XSL 1.1.
We will add further work in this area to our list of potential post-1.1 features, but this cannot be taken as any kind of commitment.
Conclusion ---------- I apologize for the brevity of the above discussion, and the inexactness of some of my terminology. It is my hope that since you probably spend a lot of time thinking about these issues, you already know what I am talking about. If not, and if I have not provided enough detail, please let me know, and I will be glad to expand as needed. BTW, thanks for your efforts on the standard. It is *extremely* useful. Thanks also for your consideration of the above items. Victor Mote (mailto:vic@outfitr.com) Enterprise Outfitters (www.outfitr.com) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice +1 (719) 622-0650, Fax +1 (720) 293-0044
From: Julian Reschke <julian.reschke@gmx.de> Date: Thu, 20 May 2004 12:26:57 +0200 Message-ID: <40AC87F1.2060206@gmx.de> To: xsl-editors@w3.org Subject: FO 1.1 WD: missing pieces (?)
Hi,
I'm maintaining code that transforms RFC2629-style ("xml2rfc") documents
to FO (<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>). This code
historically used special cases to support various extensions in Apache
FOP, AntennaHouse XSL Formatter and RenderX. Last week, I decided to
standardize on XSL 1.1 WD features, and to use post-processing XSLTs to
generate the extensions for the various backends.
This works just fine for bookmarks and index generation extensions (page
ranges etc.).
Two things are left that aren't covered in the current working draft;
maybe they should be considered.1. Generating PDF destinations Apache FOP has an extension for generating those (<http://xml.apache.org/fop/extensions.html#named-destinations>). The ability to produce them is of great importance if you want identical URI fragments to work for different media types with HTTP content negotiation (such as <http://example.com/rfc2518#rfc.section.1>, where the actual mime type (HTML, PDF...) is selected based on the client's accept header). Note that this doesn't necessarily need to be any change to the language -- it would make perfect sense to generate a PDF destination for each "id" attribute in the FO document. However, right now none of the processors I'm aware of seems to do that.
Disposition: Explanation of why no change will be made
Support of named destinations really requires no change to the XSL spec; it's more a question of how a given XSL FO implementation works, so the SG decided not to add anything to the XSL 1.1 spec for this.
We noticed that we could potentially write a Note on how this might work in implementations that generate PDF, but since this wouldn't impact the XSL 1.1 spec itself, and due to lack of resources, we didn't get anyone to commit to do this.
2. Generating document information RenderX supports adding document information to PDF output (<http://xep.xattic.com/xep/doc/spec.html#Document_Information>). This seems to be a both useful and trivial thing to do; it would be nice if there'd be a standard way to express this.
Disposition: Explanation of why no change will be made
This is really metadata, and the XSL SG do not want to use XSL FO's to represent this. Something more like Dublin Core may be more suitable.
SG members agreed both capabilities were useful, but we decided neither of them should result in changes to the XSL spec itself.
Note that both features seem to be specific to PDF output. Maybe a separate document for PDF output optimizations could cover this?
Best regards, Julian
From: <arnd.beissner@cappelino.de> Date: Fri, 21 May 2004 14:15:36 +0200 To: xsl-editors@w3.org Message-ID: <OF4AF137F7.5B45F27E-ONC1256E9B.0034E07A-C1256E9B.004352F5@cappelino.de> Subject: Possible error in 7.22.7. indicate-destination
Editors,
while implementing the basic-link formatting object for PDF output, I looked for a way to indicate to the PDF renderer when to make links visible and when not. The property 7.22.7 "indicate-destination" almost seems to do this. The spec reads: "The areas that belong to the link target when traversed should, in a system-dependent manner, be indicated." Did you perhaps intend "The areas that belong to link *source*....."? If yes, the property makes perfects sense to me. If not, would you consider adding a new property for XSL 1.1? Also, in case this is meant as it is written, what is the use case for highlighting a link destination instead of a link source?
Disposition: Explanation of XSL spec
This wording in the spec is not in error.
The source is the contents of the fo:basic-link, and your stylesheet can apply any property you want to that content--for example, underlining it is common.
The indicate-destination allows the target of a basic-link to be, say, highlighted in some fashion. The use case is as clear as highlighting the source, I guess. Some people like to know what elements in their document are potential link targets. (The fact that support for indicate-destination is so rare indicates to me that the use case is not a common one, but the use case isn't hard to understand.)
Presumably, indicating the target is only feasible currently for internal-destination links. In theory, one could have a renderer that can load a web of inter-linked documents and recognize in one document the target of a link in another document, but I am not aware of any such XSL-FO aware tool at this time. Also, this only makes sense if your external links use URIs with a fragment identifier--such as XPointer, but nothing has yet been officially stardardized as the fragment identifier for the XML media type.
I'm not entirely sure what you mean by "indicate to the PDF renderer when to make links visible and when not" (I am not a PDF expert), but visibility is an XSL FO property. If you want to make such visibility dynamic, consider using the fo:multi-switch FO.
If there is something else you need to tell the PDF renderer, you might need to invent and use your own property.
Thanks for consideration, Arnd Beissner -- Arnd Bei߮er Cappelino Informationstechnologie GmbH
From: <mallamanis@yahoo.gr> Date: Mon, 24 May 2004 12:44:51 +0300 To: <xsl-editors@w3.org> Subject: Possible Typοgraphical mistake in XSL Specifications
A small typographical mistake has been made in the XSL specifications at the
end of section 6.9.1. Below is the code where with the mistake is (line 1
char 10) <fo:block">. The quotes should not be here it should be <fo:block>
. The code (copied from the specification text) follows:
<fo:block">Follow this
<fo:multi-properties text-decoration="underline">
<fo:multi-property-set active-state="link" color="blue">
</fo:multi-property-set>
<fo:multi-property-set active-state="visited" color="red">
</fo:multi-property-set>
<fo:multi-property-set active-state="active" color="green">
</fo:multi-property-set>
<fo:multi-property-set active-state="hover" text-decoration="blink">
</fo:multi-property-set>
<fo:multi-property-set active-state="focus" color="yellow">
</fo:multi-property-set>
<fo:wrapper color="merge-property-values()"
text-decoration="merge-property-values()">
<fo:basic-link external-destination="http://www.w3.org/TR"
show-destination="new" role="An Example">link
</fo:basic-link>
</fo:wrapper>
</fo:multi-properties> to access all
TRs of the W3C.
</fo:block>
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
The erroneous '"' has been removed.
Best regards Miltos Allamanis
From: Glen Mazza <grm7793@yahoo.com> Date: Mon, 14 Jun 2004 23:01:50 -0400 Message-ID: <40CE669E.3060602@yahoo.com> To: XSL Editors <xsl-editors@w3.org> Subject: removing fo:color-profile requirement from fo:declarations
Editors:
In the 1.0Rec/1.1WD, the contents listing for fo:declarations[1] requires at least one fo:color-profile child element: Contents: (color-profile)+ However, there is an immediate qualification to this as follows: "The fo:declarations flow object may have additional child elements in a non-XSL namespace." With this qualification, the requirement for at least one fo:color-profile seems strange. Because you can use fo:declarations for non-XSL child elements, it is conceivable that a user could use fo:declarations precisely for this reason, with no concern or need of fo:color-profiles. I recommend switching the fo:declarations contents listing to the following: Contents: (color-profile)* This makes the entry of an fo:color-profile optional, and similar in nature to the zero-or-more child FO requirements of fo:title, fo:block, fo:inline, and others.
Disposition: Accepted (new functionality) ERRATUM TO BE ADDED
The "+" has been changed to a "*".
Thanks, Glen Mazza EDS / Apache FOP Team [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#fo_declarations
From: Glen Mazza <grm7793@yahoo.com> Date: Mon, 14 Jun 2004 23:08:26 -0400 Message-ID: <40CE682A.4080900@yahoo.com> To: XSL Editors <xsl-editors@w3.org> Subject: Re: removing fo:color-profile requirement from fo:declarations
One more issue, just noticed from my previous email:
> > "The fo:declarations flow object may have additional child elements in > a non-XSL namespace." > ^^^^ > Switch to "formatting" object.
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
"flow object" has been changed to "formatting object".
Thanks, Glen
From: Glen Mazza <grm7793@yahoo.com> Date: Sat, 31 Jul 2004 23:02:17 -0400 Message-ID: <410C5D39.1040708@yahoo.com> To: XSL Editors <xsl-editors@w3.org> Subject: Suggested clarification on internal-destination and external-destination properties
Editors:
The following constraint appears both on the internal-destination[1] and
external-destination[1] properties in the 1.1WD:
"At least one of the external-destination and internal-destination
properties should be assigned. If both are assigned, the system may
either report the error, or use the internal-destination property."
The second sentence appears to contradict the first ("At least
one...should") by indicating that having both assigned would be an
error. I would recommend rewriting the above constraint to either of
the following, depending on your original intent:
"Only one of the external-destination and internal-destination
properties should be assigned. If both are assigned, the system may
either report the error, or use the internal-destination property."
(Switching "At least" to "Only one")
or
"At least one of the external-destination and internal-destination
properties should be assigned. If both are assigned, the system may
either report it as an error, or use the internal-destination
property." (Switching "the error" to "as an error")
I suspect the former is what was intended.
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
Changed to "One of ..." and "it as an error". What is meant is "at least one and not more than one"...
Thanks, Glen Mazza Apache FOP Team [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#internal-destination [2] http://www.w3.org/TR/2003/WD-xsl11-20031217/#external-destination
From: Glen Mazza <grm7793@yahoo.com> Date: Tue, 10 Aug 2004 22:35:31 -0400 Message-ID: <411985F3.6030009@yahoo.com> To: XSL Editors <xsl-editors@w3.org> Subject: WD Comment: internal- and external-destination properties
Editors:
The content model constraint for fo:bidi-override has a small error: "An fo:bidi-override that is a descendant of an fo:leader or of [an-->the] fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container." Switch from "an fo:inline child" to "the fo:inline child", as shown above, because an fo:footnote has only one fo:inline child. This will make the text similar to what is already there for fo:inline's constraint: "An fo:inline that is a descendant of an fo:leader or of the fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container."
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
The "an" has been changed to a "the".
Thanks, Glen
From: Glen Mazza <grm7793@yahoo.com> Date: Tue, 10 Aug 2004 22:35:31 -0400 Message-ID: <411985F3.6030009@yahoo.com> To: XSL Editors <xsl-editors@w3.org> Subject: WD Comment: internal- and external-destination properties
Editors,
I found a possible nitpick between the internal-destination[1] and external-destination[2] property definitions in the 1.1 WD: The acceptable and initial values defined for internal-destination are: Value: empty string | <idref> Initial: empty string For external-destination, they are defined as Value: <uri-specification> Initial: empty string Looking at the two, it appears that "empty string" should also be given as a value option for external destination.
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
Yes it should indeed!
Thanks, Glen
From: Glen Mazza <grm7793@yahoo.com> Date: Tue, 10 Aug 2004 22:35:31 -0400 Message-ID: <411985F3.6030009@yahoo.com> To: XSL Editors <xsl-editors@w3.org> Subject: WD Comment: internal- and external-destination properties
Editors:
Part of the content model constraint for fo:inline[1] is stated as follows: "An fo:inline that is a child of an fo:footnote may not have block-level children. An fo:inline that is a descendant of an fo:leader or of the fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container." I think it would be clearer to combine the two sentences as follows: "An fo:inline that is a descendant of an fo:leader or fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container."
Disposition: Explanation of why no change will be made
The proposed text is not equivalent; eg it applies to descendants of fo:footnote-body as well...
Thanks, Glen Mazza FOP Team [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#fo_inline
From: Glen Mazza <grm7793@yahoo.com> Date: Sat, 14 Aug 2004 14:15:00 -0400 Message-ID: <411E56A4.6000404@yahoo.com> To: XSL Editors <xsl-editors@w3.org> Subject: suggestion on fo:inline content model constraint
Editors:
Part of the content model constraint for fo:inline[1] is stated as follows: "An fo:inline that is a child of an fo:footnote may not have block-level children. An fo:inline that is a descendant of an fo:leader or of the fo:inline child of an fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container." I think it would be clearer to combine the two sentences as follows: "An fo:inline that is a descendant of an fo:leader or fo:footnote may not have block-level children, unless it has a nearer ancestor that is an fo:inline-container."
Disposition: Explanation of why no change will be made
The proposed text is not equivalent; eg it applies to descendants of fo:footnote-body as well...
Thanks, Glen Mazza FOP Team [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#fo_inline
From: Glen Mazza <grm7793@yahoo.com> Date: Sat, 21 Aug 2004 09:55:25 -0400 Message-ID: <4127544D.3050103@yahoo.com> To: XSL Editors <xsl-editors@w3.org> Subject: 1.1 WD comments on fo:instream-foreign-object content model
Editors: I have some suggestions for the 1.0/1.1 content model for fo:instream-foreign-object [1]. Here is a (truncated) example for reference: <fo:instream-foreign-object> <svg:svg xmlns:svg="http://www.w3.org/2000/svg" width = "542px" height="505px"> <svg:title>A tiger</svg:title> <svg:g transform="translate(190, 170)"> <svg:g style="stroke:#a5264c; stroke-width:2"> <svg:path d="M47 244.801C47 244.801 50.6 242.401 53 243.601"/> </svg:g> .... .... </svg:g> </svg:svg> </fo:instream-foreign-object> The text in question is from the "Content Model" block, reproduced below: " The fo:instream-foreign-object flow object has a child from a non-XSL namespace. The permitted structure of this child is that defined for that namespace. The fo:instream-foreign-object flow object may have additional attributes *in the non-XSL namespace.* These, as well as the xsl defined properties, *are made available* to the processor of the content of the flow object. Their semantics is defined by that namespace. " Comments:
1.) Last sentence of the second paragraph-- change "Their semantics is defined..." to "are defined..."
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
2.) In the first sentence of the second paragraph, where I've placed the asterisks, I would recommend switching from "in the non-XSL namespace" (i.e., only the namespace of the child element) to "from non-XSL namespaces". It seems unnecessary to limit the child element to only the attributes from (a) XSL and (b) its own namespace, given that the subsequent sentence indicates that the child may be able to work with attributes outside its own namespace.
Disposition: Explanation of why no change will be made
The XSL SG feels it a cleaner design that at the "interface" the properties are from the XSL namespace and the, single, foreign namespace.
3.) For the second sentence of the second paragraph, again where I've placed the asterisks, switch from "are made available" to "may be made available". Some child elements from certain namespaces may not have a defined protocol for accepting and working with attributes from a non-SVG parent node. Rather, they would require those attributes to be directly attached to the child element. (For example, in the fo:i-f-o example above, the "width" and "height" attributes are directly assigned to the svg:svg node.) Perhaps a more complete way to rephrase the last two sentences of the second paragraph would be something like: "These, as well as the xsl defined properties, may be made available to the processor of the child element, depending on that processor's requirements. The semantics of any attributes passed in would be defined by the processor."
Disposition: Explanation of why no change will be made
As far as exactly which namespaced properties get passed into the foreign object, the SG has discussed this issue many times before. It turns out to be more complicated that at first appears.
We have decided that properties get used by the foreign object as they see fit, but we're not saying in the XSL FO spec how properties get inherited from one namespace into another.
This issue is outside the scope of the XSL WG; other WGs and CGs in the W3C are discussing this issue.
Therefore the XSL FO SG has decided that we will not make any changes to XSL 1.1 in response to this issue.
4.) Finally, as a sanity check, I'm unsure of the benefits of passing in the properties of the fo:i-f-o to the child processor under any circumstances. Because the protocol of this passing-in is undefined by both XSL and (potentially) the child namespace(s), this would appear to affect interoperability among the various XSL implementations and among the various processors of that child element. At any rate, AFAIK, svg itself has no provision for working with attributes not directly affixed to its elements, so I'm unsure why other namespaces would need that functionality. It would appear cleaner to require that any attributes one wishes to send the child--fonts, color, location, etc.--be directly attached to the child element. Such a requirement would also force the child namespaces to be more cleanly implemented: Rather than their recommendations stating "When this object is being embedded within an XSL:instream-foreign-object, read in these XSL properties from that object..." they would instead need to define those attributes within their own namespaces, to be attached by the user to that child's elements.
Disposition: Explanation of XSL spec
The idea behind making these properties available is to have a mechanism to permit, for example, the font family to be effectively "inherited" into the foreign namespace. One expects that the W3C will develop a model for how properties pass from namespace to namespace and also a model for arbitrary nesting of namespaces. Would it not be nice to be able to use formatting objects as part of an svg graphic when more complex text is desired?
Thanks, Glen Mazza Apache FOP Team [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#fo_instream-foreign-object
From: Glen Mazza <grm7793@yahoo.com> Date: Sat, 21 Aug 2004 11:14:02 -0400 Message-ID: <412766BA.8020902@yahoo.com> To: XSL Editors <xsl-editors@w3.org> Subject: 1.1 WD Comment on autogenerated property IDs.
Editors:
I previously wrote [1] on the issue of autogenerated property ID's a few months back. I have an additional comment on this topic and a change to my previous suggestion: A search on <idref> within the 1.1 WD gives only two defined uses of the ID property: 1.) as the internal_destination for an fo:basic-link. 2.) as the ref_id for an fo:page-number-citation. If this is correct, then given that both defined uses for the property ID require the user to have advance knowledge of what the ID value is, the value of subsequently autogenerated ID's for FO's remains unclear. OTOH, if autogeneration is primarily for internal processing of the document, that would appear to be an implementation detail that doesn't need to be placed in the recommendation. (FOP, for example, currently does not need such an autogenerated ID, and shouldn't be required to generate one.) Rather than use my previous suggestion of "none" for initial values, however, I have a new suggestion for the "initial value" requirement for the id property [2] that may give the most flexibility to XSL implementors: Change from: "An identifier unique within all objects in the result tree with the fo: namespace. [...] The initial value of this property is [a]* random and unique identifier. The algorithm to generate this identifier is system-dependent." (* fix typo) to something like: "An identifier that must be unique for all formatting objects for which it has been specified. [...] Initial values, if any, of this property are implementation-dependent."
Disposition: Explanation of XSL spec
You are correct that the autogenerated ID's are not reachable by any links (either inside or outside the document). In fact, an implementation can ignore these IDs. They were put into the specification to satisfy the following requirements:
1) every property must have an initial value.
2) the "ID" property takes an identifier (string of characters) as its value and that string must be unique in the result tree.
Requirement 1) means that some value must be specified and requirement 2) means that the value cannot be a keyword, such as "none" because that would be a legal ID identifier. Furthermore, the value must be unique in the result tree which eliminates any single initial value.
That lead us to the creation of a random unique identifier that is unique in the result tree. This is effectively equivalent to your "implementation dependent value", but more clearly satisfies the above formal requirements of the specification. Therefore, the Working Group sees no need to make a change in the specification nor is there any need for an implementation to realize these not reachable IDs.
Thanks, Glen Mazza Apache FOP Team [1] http://lists.w3.org/Archives/Public/xsl-editors/2004AprJun/0018.html [2] http://www.w3.org/TR/2003/WD-xsl11-20031217/#id
From: Glen Mazza <grm7793@yahoo.com> Date: Sun, 29 Aug 2004 18:49:22 -0400 Message-ID: <41325D72.6010604@yahoo.com> To: XSL Editors <xsl-editors@w3.org> Subject: 1.1 WD Comments on region-name and flow-name properties
Editors: A few comments on the region-name and flow-name properties in the 1.1 WD:
1.) In Section 7.25.17, "region-name" property [1]: A search on the 1.1 WD is showing that "xsl-before-float-separator" and "xsl-footnote-separator" are defined only for the flow-name property, not the region-name as listed here. Recommend to remove these two values and their definitions from region-name, and place them in the flow-name property description instead.
Disposition: Accepted (bug in spec) ERRATUM TO BE ADDED
Yes, these values are only flow names, not region-names.
2.) (minor edit) In Section 7.25.17, "region-name" property: For the definitions of the xsl-region-xxxx values, switch from "...for use as default name..." to "...for use as the default name...".
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
"the" has been added in the sentences.
3.) In Section 7.25.5, "flow-name" property [2]: a) For the sentence: "If the name is empty or if a name-conflict is encountered, an error shall be reported." It may be good to also define here (if it hasn't been defined explicitly elsewhere--I didn't see it) what happens if no region on the simple page master has the flow-name specified. I think, in this case, that would *not* be an error, but that the flow's content would just not be generated. I believe this is the case because the region-name definition states that we can define different names for the same region on the odd and even pages of fo-repeatable-page-master-alternatives (e.g., to have different static headers depending on whether we're on an odd or even page.) b) The sentence "Defines the name of the flow" seems too vague, perhaps it should be switched to something like "Designates the region that this flow's content should be assigned to."
Disposition: Explanation of why no change will be made
You are correct that this is not an error.
The SG does not want to make a wording change here because we cannot list everything that is an error. In general in the spec, if it isn't disallowed, it's allowed.
4.) In Section 6.4.1.4, "Flows and Flow Mapping" [3], make sure to update the paragraph below because we now do have an fo:flow-map formatting object in 1.1: "In version 1.0 of this Recommendation, the flow-map is implicit. [...] In future versions of XSL, the flow-map is expected to become an explicit formatting object."
Disposition: Accepted (editorial) ERRATUM TO BE ADDED
The text has been updated.
Thanks, Glen Mazza Apache FOP Team [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#region-name [2] http://www.w3.org/TR/2003/WD-xsl11-20031217/#flow-name [1] http://www.w3.org/TR/2003/WD-xsl11-20031217/#fafm
From: <arnd.beissner@cappelino.de> Date: Fri, 3 Sep 2004 09:40:45 +0200 To: XSL Editors <xsl-editors@w3.org> Subject: Handling of text-align="justify" when nesting blocks
Editors,
please consider the following inconsistency in the recommendation: Example: <fo:block text-align="justify"> TEST TEST TEST TEST ..... ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES ..... TEST ENDS A. <fo:block> whatever </fo:block> TEST TEST TEST TEST ..... ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES ..... TEST ENDS B. </fo:block> Now what would you expect: Version A: TEST TEST TEST TEST TEST ENDS A. whatever TEST TEST TEST TEST TEST ENDS B. OR Version B: (second line is justified) TEST TEST TEST TEST TEST ENDS A. whatever TEST TEST TEST TEST TEST ENDS B. Common sense would probably say "A": But, 7.15.9 of the rec says: The last (or only) line of any block, and any lines in the block ending in U+000A, will be aligned in accordance with the "text-align-last" property value. If such lines are to be justified specify "text-align-last='justify'". In the example, line 2 is neither the last nor the only line of a block, and it's also not a line ending in U+000A, so it should be justified. In contrast to this, 7.15.10 (text-align-last) says (thanks to Luca Furini for the hint): "Specifies the alignment of the last line-area child of the last block-area generated and returned by the formatting object, and to any line-area generated by the formatting object whose following sibling is a block-area that is not a line-area, and any lines in the block ending in U+000A." If 7.15.9 were worded like 7.15.10, the example would be formatted like in Version "A", which is probably what the editors intended. 7.15.9 and 7.15.10 now clearly contradict each other, IMO. My suggestion is to change the cited portion of 7.15.9 to the following wording: "The last line-area child of the last block-area generated and returned by the formatting object, and any line-area generated by the formatting object whose following sibling is a block-area that is not a line-area, and any lines in the block ending in U+000A, will be aligned in accordance with the "text-align-last" property value. If such lines are to be justified specify "text-align-last='justify'".
Disposition: Accepted (bug in spec) ERRATUM TO BE ADDED
The XSL FO SG agrees that the "The last (or only) line of any block..." sentence under the "justify" value in section 7.15.9 is confusing and misplaced (and probably just wrong). We have decided to delete that sentence.
The text at the end of section 7.15.10 is correct and is sufficient to address the issue, so we feel merely deleting the incorrect sentence from 7.15.9 is the correct action.
Thanks for considering this, Arnd -- Arnd Bei߮er Cappelino Informationstechnologie GmbH