Message-ID: <017201c0481f$a570e800$26020001@vgi.com> From: "Glenn Adams" <gadams@vgi.com> To: "W3C XSL FO SG" Date: Mon, 6 Nov 2000 13:30:31 -0500 Subject: table column groups
The lack of an fo:table-column-group prevents one from specifying a border and a background on a column group that would support the CSS2 transparency layer and border collapse algorithms as well as the rendition of HTML4 tables the "rules=groups" attribute. Is this lack of functionality intentional?
Disposition: Accepted (editorial)
The "column group" backgrounds are handled using the background of fo:table-column with number-columns-spanned greater than 1. A note as been added pointing this out and the list of areas for background generated by the fo:table changed to include "spanned areas" (XSL term) rather than "column-groups" (CSS2 term). Borders are handled at the XSLT stage when constructing the FO tree.
Links to the changed text in the XSL recommendation:
See link to changed text.
Regards, Glenn
Message-ID: <003801c051e3$d61e2620$47070001@vgi.com> From: "Glenn Adams" <gadams@vgi.com>> To: "W3C XSL FO SG" Date: Sat, 18 Nov 2000 23:47:33 -0500 Subject: fo:character needs to generate multiple glyph areas!
I am concerned that the descripiton of fo:character and the text in 4.9.5 overconstrains the character to glyph mapping process. In paricular, the text described in the following has fo:character generating only *one* glyph area. Were this constraint be enforced, then it would be impossible to correctly render a variety of scripts where there are cases that a single character maps two two distinct, non-contiguous glyphs. For example, the following vowel in Malayalam maps to two glyphs which are placed on either side of the glyph generated from the preceding consonant character. U+0D4C MALAYALAM VOWEL SIGN AU For example, if one has: <fo:character character="ക"> <!-- MALAYALAM CONSONANT KA --> <fo:character character="ൌ"> <!-- MALAYALAM VOWEL SIGN AU --> Then, under default rendering of this script, this consonant (C) and vowel (V) would generate three inline glyph areas G1 G2 G3. This works out to a correspondence as follows: C => G2 V => G1, G3 Note that for this script, there is no ligating among these three glyphs. The XSL text which concerns me includes the following. Under section 6.6.3, fo:character, there appears: The fo:character flow object represents a character that is mapped to a glyph for presentation ... The fo:character formatting object generates and returns a single normal inline-area. Also under 4.9.5, Intrinsic Marks, there appears: For example, an fo:character object generates a glyph-area ...
Discussion message:
Message-Id: <4.2.0.58.J.20001120134532.035d93c0@sh.w3.mag.keio.ac.jp> Date: Mon, 20 Nov 2000 13:46:51 +0900 To: "Glenn Adams" <gadams@vgi.com>, "W3C XSL FO SG" From: "Martin J. Duerst" <duerst@w3.org> Subject: Re: fo:character needs to generate multiple glyph areas! I fully agree with Glenn that this needs to be fixed. But this should be done during CR, not before going to CR. Maybe before going to CR, a note could be added that there is some need for more work. Regards, Martin. At 00/11/18 23:47 -0500, Glenn Adams wrote: >I am concerned that the descripiton of fo:character and the text in 4.9.5 >overconstrains the character to glyph mapping process. In paricular, the text >described in the following has fo:character generating only *one* glyph area. >Were this constraint be enforced, then it would be impossible to correctly >render a variety of scripts where there are cases that a single character maps >two two distinct, non-contiguous glyphs. For example, the following vowel in >Malayalam maps to two glyphs which are placed on either side of the glyph >generated from the preceding consonant character. > >U+0D4C MALAYALAM VOWEL SIGN AU > >For example, if one has: > ><fo:character character="ക"> <!-- MALAYALAM CONSONANT KA --> ><fo:character character="ൌ"> <!-- MALAYALAM VOWEL SIGN AU --> > >Then, under default rendering of this script, this consonant (C) and vowel (V) >would generate three inline glyph areas G1 G2 G3. This works out to a >correspondence as follows: > >C => G2 >V => G1, G3 > >Note that for this script, there is no ligating among these three glyphs. > >The XSL text which concerns me includes the following. > >Under section 6.6.3, fo:character, there appears: > >The fo:character flow object represents a character that is mapped to a glyph >for presentation ... >The fo:character formatting object generates and returns a single normal >inline-area. > >Also under 4.9.5, Intrinsic Marks, there appears: > >For example, an fo:character object generates a glyph-area ...
Discussion message:
Message-ID: <OF36C983DE.A7366200-ON8525699D.007811A0@pok.ibm.com> From: "Anders Berglund" <alrb@us.ibm.com> Date: Mon, 20 Nov 2000 16:52:59 -0500 Subject: Re: fo:character needs to generate multiple glyph areas! I am not so sure that more than one glyph area should be generated or if the actual display using GLYPHS IN THE FONT (design and architecture dependent) is the place where one "ideal glyph" (=XSL) is mapped into more for the distplay. I think it is quite analogous to a case where the "ideal glyph" for "A with ring" is displayed using a "font glyph" for "A" and a "font glyph" for the "ring". In this case I think it is very clear that XSL should see it as only ONE glyph. In the Malayalan case cited I can see the display of "ideal glyph"s CW being rendered as the sequence w1cw2 of "font glyphs" (with an adjustment of the position of "c" to get appropriate spacing). One way to decide on the model would be to see if the AFII registry has one glyph or two glyphs to make up x0d4c. (Glenn do you have the registry handy - mine is in RI and I am im NY). Anders
Discussion message:
Message-ID: <3A19A187.481FBB7B@bitstream.com> Date: Mon, 20 Nov 2000 17:11:19 -0500 From: jcaruso@pageflexinc.com (Jeff Caruso) To: Anders Berglund <alrb@us.ibm.com> Subject: Re: fo:character needs to generate multiple glyph areas! Anders Berglund wrote: > I am not so sure that more than one glyph area should be > generated or if the actual display using GLYPHS IN THE FONT > (design and architecture dependent) is the place where one > "ideal glyph" (=XSL) is mapped into more for the distplay. I think > it is quite analogous to a case where the "ideal glyph" for > "A with ring" is displayed using a "font glyph" for "A" and > a "font glyph" for the "ring". In this case I think it is very > clear that XSL should see it as only ONE glyph. > In the Malayalan case cited I can see the display of "ideal glyph"s > CW being rendered as the sequence w1cw2 of "font glyphs" > (with an adjustment of the position of "c" to get appropriate spacing). > > One way to decide on the model would be to see if the AFII > registry has one glyph or two glyphs to make up x0d4c. > (Glenn do you have the registry handy - mine is in RI and I am > im NY). I think no further change is needed. Section 4.6.2 (Glyph-areas) already makes it clear that a glyph-area can come from more than one character: The most common inline-area is a glyph-area, which contains the representation for a character (or characters) in a particular font. The way this comes about is described in section 4.7.2 (Line-building), point 5: * S_i consists of inline-areas then B_i is a line-area whose child areas are the same as the inline-areas in S_i, 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. This basically asserts that the order of the inline-areas is unchanged from the fo tree to the area tree, except in these cases, which include the case that Glenn was referring to when he began this thread. Regards, -- JeffC ****************************************************** Dr. Jeffrey L. Caruso <jcaruso@pageflexinc.com> Pageflex, Inc. 215 First St. Cambridge, MA 02142 (A Bitstream company)
Discussion message:
Message-ID: <022d01c05341$cb713eb0$26020001@vgi.com> From: "Glenn Adams" <gadams@vgi.com> To: "Jeff Caruso" <jcaruso@pageflexinc.com>, "Anders Berglund" <alrb@us.ibm.com> Date: Mon, 20 Nov 2000 17:32:41 -0500 Subject: Re: fo:character needs to generate multiple glyph areas! My only comment to this would be: * add reordered to substituted and deleted in the text you quote below * fix the text that I referred to in my initial message (4.9.5 and 6.6.3) where it says "*a* glyph area"
Discussion message:
Message-ID: <022301c05340$abc52410$26020001@vgi.com> From: "Glenn Adams" <gadams@vgi.com> To: "Anders Berglund" <alrb@us.ibm.com> Date: Mon, 20 Nov 2000 17:24:38 -0500 Subject: Re: fo:character needs to generate multiple glyph areas! It's actually more complicated than I suggested earlier. One of glyphs from the multiple glyphs generated by a character may ligate with a glyph produced by a different character. For example, in Unicode 3.0, pg 231, under ligature rule 2, you will find 6 instances in Tamil where one of the glyphs (the one on the right of the consonant) generated from a "precomposed vowel" ligates with the glyph produced by the consonant character which precedes the precomposed vowel character.
Disposition: Accepted (bug in spec)
Links to the changed text in the XSL recommendation:
See link to changed text.
Message-ID: <004a01c046b7$98aabe20$47070001@vgi.com> From: "Glenn Adams" <gadams@vgi.com> To: "XSL Editors" <xsl-editors@w3.org> Date: Sat, 4 Nov 2000 18:31:39 -0500 Subject: Interpretation of left,right,top,bottom as used with CSS2 properties
In many cases, CSS2 specifies that left and right are to be interpreted with respect to the "direction" property, with left mapping to right and vice-versa for right-to-left directionality. Does this interpretation also apply for those CSS2 properties permitted in XSL?
Disposition: Explanation of XSL spec
The following are the places where CSS uses the value of "direction" to vary the behavior of a CSS construct:
1. For "compact" boxes, direction determines which margin the compact box is positioned within. (Not applicable to XSL)
2. For determination of the "containing block", Rule 4. If the element has 'position: absolute', the containing block is established by the nearest ancestor with a 'position' other than 'static', in the following way:
a. In the case that the ancestor is block-level, the containing block is formed by the padding edge [p. 82] of the ancestor.
b. In the case that the ancestor is inline-level, the containing block depends on the 'direction' property of the ancestor:
i. If the 'direction' is 'ltr', the top and left of the containing block are the top and left content edges of the first box generated by the ancestor, and the bottom and right are the bottom and right content edges of the last box of the ancestor.
ii. If the 'direction' is 'rtl', the top and right are the top and right edges of the first box generated by the ancestor, and the bottom and left are the bottom and left content edges of the last box of the ancestor. If there is no such ancestor, the content edge of the root element's box establishes the containing block.
In XSL these rules are handled by referring to the writing mode relative edges.
3. For 10.3.3 Block-level, non-replaced elements in normal flow, there is an equation that determines the unspecified values for margins, padding, borders and content width relative to the content width of the containing block:
'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' = width of containing block
If this equation is overconstrained, then the margin away from the start side of the containing block is relaxed to solve the constraint. Direction is used to determine the "start" side. This is handled in section 5.3.4 Overconstrained Geometry in the XSL spec.
4. For 10.3.7 Absolutely positioned, non-replaced elements and 10.3.8 Absolutely positioned, replaced elements, there is an equation similar to that in 3. above, but this new equation adds in 'left' and 'right' which are the offsets from the content edge of the containing block. These "offsets" are used to position the absolutely positioned block and may take the value 'auto'. There are two different direction based rules for handling 'left' and 'right'.
The first of these rules covers the case where 'left' (or 'right') is the start-edge and its value is "auto". In this case, 'left' (correspondingly 'right') is set to an amount that would put the starting margin edge where the starting margin edge of the first "box" of the content of the containing block would have been placed. It is not totally clear which cases this is supposed to cover, but experiments with the existing browsers indicate that setting 'text-indent' will change where the first (inline) box is placed in a block and, therefore, the absolutely positioned block has its starting margin edge aligned to that of the first (inline) box. This works whether the indent is into the block or back outside the block.
The second rule is a variant of the rule in 3. above, but instead of relaxing the margin value on the end edge, it relaxes the 'right' (or 'left') value that corresponds to the end edge of the containing block.
5. For Left and Right pages (13.2.4), the direction (and writing mode) will influence whether the first page is a left or right page. This is not a concern for XSL because we do not right or left pages, but instead use even or odd pages.
6. For 16.2 Alignment: the 'text-align' property, the initial value depends on direction. This is not a problem in XSL because we can describe the dependence by setting the initial value to 'start'.
7. For 17.5 Visual layout of table contents, direction controls on which side of the table the first column is placed and how cell spans are placed. This use of direction is explicitly covered by Writing-mode for XSL.
8. For 17.5.4 Horizontal alignment in a column, "Character directionality determines whether the string lies to the left or right of the axis" when aligning to a string, such as the decimal point, in the content of a column. This is really an observation.
Furthermore, does this extend to variable interpretations of top/bottom w.r.t. block-progression-direction?
Disposition: Explanation of XSL spec
Yes, but the XSL text does that automatically being expressed in terms of start and end edges which work for all writing-modes.
Finally, does this intepretation also apply to absolute position properties left, right, top, bottom?
Disposition: Explanation of XSL spec
This is a bit hard to answer. The cases above show that there are places where the absolute position properties behavior is influenced by direction. But, there is, in general, no relabeling of the absolute properties due to direction. See above for the details.
Regards, Glenn
Message-ID: <002301c04e16$57aa27b0$0a01a8c0@grig> From: "Nikolai Grigoriev" <grig@renderx.com> To: <xsl-editors@w3.org> Date: Tue, 14 Nov 2000 11:37:58 +0300 Subject: Column areas and span="all" Dear XSL Editors,
while implementing multi-column layouts, we have encountered problems in spec interpretation. Consider this case: <fo:block> <fo:block span="all">SPANNED</fo:block> <fo:block> The outer block has an implicit value of span="none". Therefore, by definition of the "span" property [WD 7.18.5], "this object does not span multiple columns". It looks like having children with span="all" is illegal in this case. If we swap the location of attributes, we still get interpretation problems: <fo:block span="all"> <fo:block>SOME TEXT</fo:block> <fo:block> The outer block "shall span all the columns of a multi-column region", and the inner one "does not span multiple columns" (because @span is not inheritable, with the initial value of "none"!). Therefore, for a layout to be consistent, one should never nest blocks with different values of span="all". This turned out to be extremely unpractical. When designing a stylesheet, you have to care about every block-level element if it will be placed into a spanned region, or into a normal one; you need either to switch modes, or to keep an extra parameter just to pass the @span value down to all block-level descendants of a spanned block. (Using "inherited" of "from-parent()" value does not help much - you should care to specify this on every wrapper inside your block, but not outside. And "from-nearest-specified-value()" risks to destroy floats/footnotes). My suggestion is to get rid of all these. If a flow-region should be subdivided into span-reference-areas, let us design a special formatting object to correspond to these areas - let us call it fo:flow-body: <!ELEMENT fo:flow (fo:flow-body+ | (%block;)+)> <!ELEMENT fo:flow-body+ (%block;)+> <!ATTLIST fo:flow-body column-count CDATA #IMPLIED column-gap CDATA #IMPLIED ... > This would also yield the formatting more flexible - you could alternate two-column regions with three-column ones. From the implementation point of view, there's little difference between having only two possible values for @column-count in a fo:flow, or having many - you still need to balance columns in every span-reference-area separately. And having a possibility to produce magazine-style layouts is a big plus for any formatter.
Disposition: Accepted (clarification)
A clarifying note has been added in the description of the "span" property.
Links to the changed text in the XSL recommendation:
See link to changed text.
Best regards, Nikolai Grigoriev RenderX
From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de> To: xsl-editors@w3.org Date: Tue, 14 Nov 2000 20:22:19 +0100 Message-ID: <3A119EFB.7084.20A2B9@localhost> Subject: space-treatment Hello,
in section 7.13.8 "space-treatment" the enumeration of possible values of space-treatment in the xsl definiton is not complete. the values ignore-if-before-linefeed etc. are missing.
Disposition: Accepted (editorial)
This correction was already made in the Candidate Recommendation.
imho the name space-treatment is rather unfortunate, because you are talking about the handling of "white space" and you kept this name for white-space-collapse
Disposition: Accepted (editorial)
The property has been renamed "white-space-treatment".
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
Fotis Jannidis
From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de> To: xsl-editors@w3.org Date: Thu, 16 Nov 2000 08:58:38 +0100 Message-ID: <3A13A1BE.14406.20E870@localhost> Subject: errors Hello,
In 6.6.5 fo:external-graphic in list after "The following properties apply to this formatting object:" the property [7.11.4 "display-align"] is listed twice.
Disposition: Accepted (editorial)
This correction was already done in the Candidate Recommendation.
In 7.11.4 "display-align" in the list "Applies to: fo:table-cell, fo:region-body, fo:region-before, fo:region-after, fo:region-start, fo:region-end" the fo external-graphic is missing or the reference in 6.6.5 is wrong.
Disposition: Accepted (editorial)
The following have been added to the list: fo:block-container, fo:inline-container, fo:external-graphic, fo:instream-foreign-object
Links to the changed text in the XSL recommendation:
See link to changed text.
Fotis Jannidis
From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de> To: xsl-editors@w3.org Date: Sat, 18 Nov 2000 22:50:48 +0100 Message-ID: <3A1707C8.25558.141AC59@localhost> Subject: error
Hello, in section 7.19.3 "leader-pattern-width" The sentence >>For leaders where the "leader-pattern" property is specified as "dot" or as "use-content", this property will be honored.<< must read: >>For leaders where the "leader-pattern" property is specified as "dots" or as "use-content", this property will be honored.<< "dot" -> "dots"
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
Fotis Jannidis
From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de> To: xsl-editors@w3.org Date: Mon, 20 Nov 2000 16:56:44 +0100 Message-ID: <3A1957CC.22626.1957541@localhost> Subject: question Hello,
between xsl:fo wd from 12 January 2000 you changed the explanation for "leader-length" in section 7.14.4 from "The specification of a minimum and maximum range of lengths allows leaders and inline rules to be used to "fill" or "justify" a line or to "fill" the remaining width of a table-cell. It also allows for specification of how multiple leaders appearing in a given line- area are to be balanced." to section 7.19.4 in wd 18 October 2000 to "User agents may choose to use the value of "leader- length.optimum" to determine where to break the line, then use the minimum and maximum values during line justification." My understanding of this option: One of the common uses of the length-range leader-length will be to construct table of contents. There the space between the text and the page reference should be filled with dots or other characters. Because of the different length of text and therefore the different space for the filler you need some "fill" option and this is where the length-range comes in. I have been looking for some possibility to solve this problem and the thought I could try it with using the length-range. By chance I discovered that in earlier working drafts you explicitly mentioned this usage. Have you changed plans? Should this effect now be achieved by other means?
Disposition: Accepted (clarification)
Leaders are intended for use in table of contents "filed" with dots, so our plans have not changed. An example has been added to the specification showing this usage. In addition more note text has been added to clarify this usage.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
btw, there seems to be a superfluous " at the end of the sentence in the latest wd.
Disposition: Accepted (editorial)
Fotis Jannidis
From: "Roger Neate" <alpha-dog@arfarfarf.com> To: <xsl-editors@w3.org> Date: Wed, 22 Nov 2000 09:57:37 -0800 Message-ID: <KJEEIHKPDLIHAJMJNFNDAEOKCCAA.alpha-dog@arfarfarf.com> Subject: XSL Formatting Objects DTD or Schema
Is there a downloadable DTD or schema for the formatting object elements as specified in the XSL candidate recommendation 11 Nov 2000? I have been able to find a DTD for the XSLT elements, but not for the formatting objects. Thanks for any help you can offer.
Disposition: Explanation of why no change will be made
The XSL WG has not made any DTD (or schema) available for the formatting objects. The reason is that any such DTD would be rather meaningless (and maybe even misleading) since;
a) there are additional constraints on the content that cannot be expressed in a DTD, e.g., an fo:footnote is not permitted to have an fo:float, fo:footnote, or fo:marker as a descendant. To quote from the XSL specification:
The content of a formatting object is described using XML content-model syntax. In some cases additional constraints, not expressible in XML content models, are given in prose.
b) the formatting properties are syntactically expressed as XML attributes. Only some of the properties APPLY to a particular formatting object, but they can be specified on any formatting object (one very common case is to specify some number of inheritable properties close to the root of the tree and letting the values inherit down). Formatting properties may also be expressions, e.g., background-color="inherited-property-value(color)", so every attribute value would have to be declared as CDATA for a formatting object document to be validated by an XML processor. Thus a DTD would have to list all properties as permitted on each element and the only "validation" one would get is spelling of the attribute names!
Roger Neate
Date: Fri, 24 Nov 2000 19:01:14 GMT Message-Id: <200011241901.TAA30585@cruzcampo.nag.co.uk> From: David Carlisle <davidc@nag.co.uk> To: xsl-list@mulberrytech.com Subject: XSL-FO: syntax for datatypes
I (rather late, sorry) noticed that in XSL-FO <integer> and <number> literals (as specified on page 59 of the CR pdf file) allow an optional + before the digits. This is a rather surprising difference from XSLT and XPath, considering how closely these specs are interrelated. Probably the spec ought at least note the difference.
Disposition: Accepted (editorial)
The "+" is permitted for CSS2 compatibility. A note to that effect has been added to the specification.
Links to the changed text in the XSL recommendation:
See link to changed text.
Also (page 61) id and idref are defined to take a Name, and references the XML spec for Name, however the namespace spec (rather weakly) specifies that IDs should be NCNames. An XML document conforms to this specification if all other tokens in the document which are required, for XML conformance, to match the XML production for Name, match this specification's production for NCName. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The effect of conformance is that in such a document: All element types and attribute names contain either zero or one colon. No entity names, PI targets, or notation names contain any colons. Strictly speaking, attribute values declared to be of types ID, IDREF(S), ENTITY(IES), and NOTATION are also Names, and thus should be colon-free. ^^^^^^^^^^ I believe that MSXML (at least) enforces this.
Disposition: Accepted (editorial)
IDs and IDREFs have been changed to NCNames.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
David (This message is being sent to xsl-list, copied to xsl-editors list) _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre. For further information visit
To: xsl-editors@w3.org From: MURAKAMI Shinyu <murakami@nadita.com> Message-Id: <200011270857.GGF08768.VBLNJSNB@nadita.com> Date: Mon, 27 Nov 2000 08:57:18 +0900 Subject: XSL-FO - Initial value of border/padding conditionality
The CR XSL 2000-11-21 says: 7.6.9 "border-before-width" ... The initial value of the .conditionality component is "retain". 7.6.12 "border-after-width" ... The initial value of the .conditionality component is "retain". 7.6.15 "border-start-width" ... The initial value of the .conditionality component is "discard". 7.6.18 "border-end-width" ... The initial value of the .conditionality component is "discard". 7.6.31 "padding-before" ... The initial value of the .conditionality component is "retain". 7.6.32 "padding-after" ... The initial value of the .conditionality component is "retain". 7.6.33 "padding-start" ... The initial value of the .conditionality component is "discard". 7.6.34 "padding-end" ... The initial value of the .conditionality component is "discard". ...... It lacks consistency!!! Why "retain" on before/after and "discard" on start/end? I believe that the initial value of the .conditionality should be "discard" on all edges.
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0297.html
To: xsl-editors@w3.org From: MURAKAMI Shinyu <murakami@nadita.com> Message-Id: <200012301437.BGI52863.BJBNVNLS@nadita.com> Date: Sat, 30 Dec 2000 14:37:18 +0900 Subject: Re: XSL-FO - Initial value of border/padding conditionality Dear XSL-Editors, I wrote: >To: xsl-editors@w3.org >From: MURAKAMI Shinyu <murakami@nadita.com> >Message-Id: <200011270857.GGF08768.VBLNJSNB@nadita.com> >Date: Mon, 27 Nov 2000 08:57:18 +0900 >Subject: XSL-FO - Initial value of border/padding conditionality > >The CR XSL 2000-11-21 says: > >7.6.9 "border-before-width" >... The initial value of the .conditionality component is "retain". > >7.6.12 "border-after-width" >... The initial value of the .conditionality component is "retain". > >7.6.15 "border-start-width" >... The initial value of the .conditionality component is "discard". > >7.6.18 "border-end-width" >... The initial value of the .conditionality component is "discard". > >7.6.31 "padding-before" >... The initial value of the .conditionality component is "retain". > >7.6.32 "padding-after" >... The initial value of the .conditionality component is "retain". > >7.6.33 "padding-start" >... The initial value of the .conditionality component is "discard". > >7.6.34 "padding-end" >... The initial value of the .conditionality component is "discard". > >...... > > >It lacks consistency!!! Why "retain" on before/after and "discard" on >start/end? > >I believe that the initial value of the .conditionality should be >"discard" on all edges. > When I wrote that, I had not read [Disposition of Comments on XSL 1.0 Last Call] yet, sorry. http://www.w3.org/Style/XSL/XSL1/comments.html >Disposition: Explanation of why no change will be made > >We agree that for many publishing applications the "discard" >value is more commonly used. In CSS2, however, "retain" is >the only behavior when a "block" is split. Thus we prefer to >keep the initial value as "retain". > However, I cannot agree to this. I could not find in CSS2 spec the behavior when a block is split. Then, I tested major CSS implementations, MSIE 5.5, Netscape 6.0, Opera 5.0, and I found "discard" is the behavior when a block is split on all these products. Therefore, I still believe that the initial value of the .conditionality should be "discard" on all edges. Regards, MURAKAMI Shinyu XSL-Dev, Antenna House, Inc.
Disposition: Accepted (clarification)
This question was discussed at a joint XSL/CSS face to face meeting and it was agreed that, even though the CSS2 recommendation does not state the behaviour for blocks being split one should assume the same rules as for inlines. The initial values have been changed to "discard" as you request.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
Regards, MURAKAMI Shinyu
From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de> To: xsl-editors@w3.org Date: Sat, 2 Dec 2000 14:55:15 +0100 Message-ID: <3A290D53.10638.E38766@localhost> Subject: typo
In section 7.20.5 "rule-style" >>> double: The rule is two solid lines. The sum of the two lines and the space between them eqThe rule is two solid lines. The sum of the two lines and the space between them equals the value of "rule-thickness". <<< The texts has been inserted twice and broken too.
Disposition: Explanation of why no change will be made
The doubling is not present in the HTML files, nor in the PDF version of the Candidate Recommendation. Was the incorrect display a browser (or other User Agent) error?
Fotis Jannidis
From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de> To: xsl-editors@w3.org Date: Thu, 14 Dec 2000 23:09:33 +0100 Message-ID: <3A39532D.22475.32254E4@localhost> Subject: typo
In: 7.28.1 "background" Applies to: all elemeall elements
Disposition: Explanation of why no change will be made
The doubling is not present in the HTML files, nor in the PDF version of the Candidate Recommendation. Was the incorrect display a browser (or other User Agent) error?
Fotis
Message-Id: <4.3.1.2.20001223105334.00ba3c20@127.0.0.1> Date: Sat, 23 Dec 2000 11:01:19 +0000 To: xsl-editors@w3.org From: Dave Pawson <daveP@dpawson.freeserve.co.uk> Subject: master-name property
The use of the master-name property within fo:simple-page-master , fo:page-sequence-master and fo:page-sequence I find very confusing. Within fo:single-page-master-reference you specify master-name, but element indicates its a reference, not a 'name' or identifier. For the previous 3 elements, I'm not sure if each is a reference or an identifier. I would find it far more helpful if the property were changed to clearly indicate to users that the first two are idenfiers, and in the third case its a reference, perhaps by changing the property name to master-name-reference. If this is done, the practice could be made common by renaming the master-name property in the sub-sequence elements of page-sequence-master. E.g. <fo:page-sequence-master master-name="master-sequence"> <fo:single-page-master-reference master-name-reference="first"/> <fo:repeatable-page-master-reference master-name-reference="red" maximum-repeats="10"/> <fo:repeatable-page-master-reference master-name-reference="green" maximum-repeats="no-limit"/> </fo:page-sequence-master> Then fo:page-sequence would read <fo:page-sequence master-page-reference="master-sequence" Its difficult enough to understand without adding to the complexity by misleading readers with poorly named properties.
Disposition: Accepted (clarification)
"master-name" has been changed to "master-reference" on the FOs that refer. "master-name-reference" was rejected to avoid "x" and "x-qualified" names. "master-page-reference" was rejected as the value can be referring to either a page master or a sequence master.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
Regards DaveP AC, RNIB.
Message-Id: <4.3.1.2.20001230164305.00bbe830@127.0.0.1> Date: Sat, 30 Dec 2000 16:50:49 +0000 To: xsl-editors@w3.org From: Dave Pawson <daveP@dpawson.freeserve.co.uk> Subject: fo:if ! feature request Not sure its 1.0, but definately for 1.1/2.0, whichever is next.
Use case: We (RNIB, www.rnib.org.uk) print large print bank statements for our customers. I had to pass when a chance came up to use XML/XSL-FO because a simple requirement could not be met. The table of date/item/amount has, at the top of each page a 'sum' of transactions to date. NO NOT IN THE HEADER. fo:marker won't do it. In the body of the content, I needed a simple calculation to say 'transactions to date' . XSLT allows me to calculate it, but XSL won't allow me to add the content at the right time. We need interaction with the formatter. Requirement. That it be possible to interface with the formatter to insert content as and when 'top of new page' is true. Syntax down to you, I envisage something like <fo:if test="top-of-page"> <fo:block/> </fo:if> I want the conditional block to be available as and when the formatter has determined that a new page is 'about to start', so I can get my odd bits in at the right place.
Disposition: Future XSL version
The functionality asked for is one aspect of a much larger area of "layout driven" formatting. The XSL WG decided not to include it in 1.0 but it will be considered for a subsequent XSL version.
If I'm not clear in the requirement/use case, please come back to me with questions. I would appreciate an acknowledgement. Regards DaveP AC RNIB.
Message-ID: <3A4E8A6F.79697108@metalab.unc.edu> Date: Sat, 30 Dec 2000 17:22:55 -0800 From: Elliotte Rusty Harold <elharo@metalab.unc.edu> To: xsl-editors@w3.org Subject: fo:page-sequence; How many fo:flow children can it have?
In section 6.4.5, fo:page-sequence, the content model is given as: (title?,static-content*,flow) This says that each fo:page-sequence has *exactly one* fo:flow child element. However, the prose in that section repeatedly refers to "the child fo:flow objects", the "flow children of the fo:page-sequence", "the flow-object children of the fo:page-sequence", and other plural forms of fo:flow that suggest a fo:page-sequence can have more than one fo:flow child. I suspect the content model for fo:page-sequence should be (title?,static-content*,flow+) ^^^ Or if not, then the prose should be tightened up to indicate that at most one fo:flow is allowed in each fo:page-sequence.
Disposition: Accepted (clarification)
The intent is to have only ONE fo:flow per fo:page-sequence. The text has been "tightened" to reflect that. Note, however, that "flow" (as opposed to fo:flow) refers to content from both fo:flow and fo:static-content and it does occur in the plural intentionally.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
-- +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | Java I/O (O'Reilly & Associates, 1999) | | http://metalab.unc.edu/javafaq/books/javaio/ | | http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java news: http://metalab.unc.edu/javafaq/ | | Read Cafe con Leche for XML news: http://metalab.unc.edu/xml/ | +----------------------------------+---------------------------------+
Message-ID: <3A54F6A2.503C04B4@club-internet.fr> Date: Thu, 04 Jan 2001 23:18:10 +0100 From: Karen Lease <klease@club-internet.fr> To: xsl-editors@w3.org Subject: fo:block-container, padding and borders- request for clarification Hello,
I'd like to make sure I have the correct understanding of how to handle padding and border on block-container formatting objects. In section 6.5.3 I read: "The fo:block-container formatting object generates one or more viewport/reference pairs. ... The following properties apply to this formatting object: [7.4 Common Absolute Position Properties] [7.6 Common Border, Padding, and Background Properties] " In the general explanation of the area model (Chapter 4.9.4), it says that the border is not rendered for areas which are children of viewport-areas. Since border and padding can be specified on block-container, should they be applied to the viewport-area? For example, suppose I have an absolutely positioned block-container. The values for left,top etc. position its content rectangle. Assuming no scrolling, the content rectangle for the reference area and its parent viewport area should be the same (at least their start and before edges are the same). If non-zero padding and border were specified for the block container, are they to be rendered outside the content rectangle of the viewport area?
Disposition: Explanation of XSL spec
The answer to both your questions is yes. The border and padding should be applied to the viewport-area and rendered outside its content rectangle.
Thanks in advance, Karen Lease, FOP'er
Message-ID: <3A54FF06.A6DF2976@club-internet.fr> Date: Thu, 04 Jan 2001 23:53:58 +0100 From: Karen Lease <klease@club-internet.fr> To: xsl-editors@w3.org Subject: Inherited values where percent is legal Hello,
In working on FOP's FO property handling, I've run across a few issues involving lengths which can be specified as percentages, especially when the property can be inherited. My list of such properties and their reference dimensions is as follows: start-indent, end-indent width of containing reference area text-indent, last-line-text-indent width of containing block line-height font-size of the FO (inherits specified?) font-size font-size of parent (inherits computed) leader-length width of content-rectangle of parent area leader-pattern-width width of containing box provisional-distance-between-starts width of containing box provisional-label-separation width of containing box I know that the general rule is that computed values are inherited. This is explicitly stated for font-size. On the other hand, for line-height, when it is specified as a number the specification says that the specified value is inherited. In this case, I'm inclined to treat a percentage in the same way as a number (and a relative length too for that matter). For the other properties above, there is no specific mention of the inherited value, implying that the computed value is inherited. This bothers me a bit, especially for a property like leader-length where the default value for leader-length.maximum is "100%". I would feel more comfortable if the specified percentage value were inherited and recalculated on each flow object. I'd appreciate any explanations or justifications you can offer for this.
Disposition: Explanation of XSL spec
For compatibility with CSS2 the general rule, even for percentages, is that the computed value is inherited. We have added a section specifying in detail which area is used as reference when the "general rule" is not sufficient, e.g. a percentage specified on fo:root.
Links to the changed text in the XSL recommendation:
See link to changed text.
A related question: in the list above, there are several different ways of designating the base length for a percentage. My interpretation is : a) the dimension in question is always the content-rectangle, unless explicitly stated otherwise, b) "containing block" means the nearest block-area ancestor c) "containing box" and "parent area" are basically equivalent and could be either an inline-area or block-area. Is this correct? Or is there some distinction I'm missing?
Disposition: Accepted (bug in spec)
A section has been added to specify in detail which rectangle (which in almost all cases is the content-rectangle) is used as reference for the calculation of the computed value of a percentage. The different ways it was designated in the text has been rationalized.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
Thanks in advance for any information, Karen Lease, FOP'er
Message-ID: <3A59C4E4.EED525AA@isu-gmbh.de> Date: Mon, 08 Jan 2001 14:47:16 +0100 From: Christian Geisert <Christian.Geisert@isu-gmbh.de> To: xsl-editors@w3.org Subject: fo:inline - no text-transfom/text-shadow? Hi,
I'm wondering why the formatting properties "text-transform" and "text-shadow" are not in the list of properties which apply to fo:inline? (see 6.6.7)
Disposition: Explanation of XSL spec
These properties apply to the content, fo:character, of the fo:inline and not to the inline itself.
These properties have been removed from "bidi-override" for the same reason.
Christian Geisert
To: xsl-editors@w3.org Cc: xsl-list@lists.mulberrytech.com From: MURAKAMI Shinyu <murakami@nadita.com> Message-Id: <200101100311.EDC35279.BSLVJNNB@nadita.com> Date: Wed, 10 Jan 2001 03:11:39 +0900 Subject: XSL-FO - start-indent and end-indent I've found some problems of XSL-FO CR spec about start-indent and end-indent.
Problem 1: Formulae for indents (indent=margin+padding+border?) =============================================================== In [5.3.2 Margin, Space, and Indent Properties] of XSL-FO CR spec: <quote> The formulae for calculating the computed value of the "start-indent", and "end-indent" properties are as follows (where "margin-corresponding" is a variable for the corresponding absolute "margin" property): end-indent = margin-corresponding + padding-end + border-end-width start-indent = margin-corresponding + padding-start + border-start-width </quote> I understand that the margin- properties and the above formulae are provided for compatibility with CSS. However the compatibility is imperfect. Case 1: Indents on nested blocks CSS (with HTML): <div style="margin-left: 0pt; padding-left: 9pt; border-left: 6pt solid red"> Outer Block <div style="margin-left: 0pt; padding-left: 9pt; border-left: 6pt solid blue"> Inner Block </div> </div> Formatted as: | Outer Block | | Inner Block XSL-FO (simply converted): <fo:block margin-left="0pt" padding-left="9pt" border-left="6pt solid red"> Outer Block <fo:block margin-left="0pt" padding-left="9pt" border-left="6pt solid blue"> Inner Block </fo:block> </fo:block> Then, let's calculate the start-indents using the formula: start-indent = margin-corresponding + padding-start + border-start-width = 0pt + 9pt + 6pt = 15pt (on both outer and inner blocks) and the equivalent XSL-FO will be: <fo:block start-indent="15pt" padding-left="9pt" border-left="6pt solid red"> Outer Block <fo:block start-indent="15pt" padding-left="9pt" border-left="6pt solid blue"> Inner Block </fo:block> </fo:block> Formatted as: | Outer Block | Inner Block Problem: Both start-indents have same value and the two borders overlap. (because indents are measured from the containing reference-area, not the containing block) To solve the problem -------------------- The formulae should be corrected as: end-indent = inherit + margin-corresponding + padding-end + border-end-width start-indent = inherit + margin-corresponding + padding-start + border-start-width Then, outer block: (here, inherit=0pt) start-indent = 0pt + 0pt + 9pt + 6pt = 15pt inner block: (here, inherit=(outer start-indent)=15pt) start-indent = 15pt + 0pt + 9pt + 6pt = 30pt <fo:block start-indent="15pt" padding-left="9pt" border-left="6pt solid red"> Outer Block <fo:block start-indent="30pt" padding-left="9pt" border-left="6pt solid blue"> Inner Block </fo:block> </fo:block> and the formatted results are same as the original.
Disposition: Accepted (bug in spec)
The formula has been corrected by adding "inherited end-indent +" and "inherited start-indent +" respectively.
Links to the changed text in the XSL recommendation:
See link to changed text.
Case 2: Indents on blocks without margin-corresponding specified On the previous case, I did not omit margin-left:0pt. In CSS, it can be omitted because zero is the initial value of margin- properties and these are not inheritable. But in XSL-FO, it's not so easy since start- and end-indent are inheritable. In CSS (with HTML): <div style="padding-left: 9pt; border-left: 6pt solid red"> Outer Block <div style="padding-left: 9pt; border-left: 6pt solid blue"> Inner Block </div> </div> Formatted as: | Outer Block | | Inner Block (same as when margin-left:0pt is specified on both block) In XSL-FO (simply converted): <fo:block padding-left="9pt" border-left="6pt solid red"> Outer Block <fo:block padding-left="9pt" border-left="6pt solid blue"> Inner Block </fo:block> </fo:block> The problem is how to get the start-indent values. Since the margin-corresponding (margin-left) is not specified, the formulae for indents are not applicable. In the XSL-FO spec, start/end-indent properties are inheritable and its initial value is 0pt. Therefore, start-indent="0pt" is the answer (?) If this is the correct interpretation, the above XSL-FO is equivalent to: <fo:block start-indent="0pt" padding-left="9pt" border-left="6pt solid red"> Outer Block <fo:block start-indent="0pt" padding-left="9pt" border-left="6pt solid blue"> Inner Block </fo:block> </fo:block> Formatted as: Outer Block Inner Block (borders are outside of the containing reference-area!!) The results are very different from the original CSS. I think this is very serious problem of compatibility with CSS. To solve the problem -------------------- The formulae should be used although margin-corresponding are not explicitly specified. end-indent = inherit + margin-corresponding + padding-end + border-end-width start-indent = inherit + margin-corresponding + padding-start + border-start-width (in this case, margin-corresponding defaults to 0pt) Then, the start-indents are computed as follows: outer block: (here, inherit=0pt) start-indent = 0pt + 0pt + 9pt + 6pt = 15pt inner block: (here, inherit=(outer start-indent)=15pt) start-indent = 15pt + 0pt + 9pt + 6pt = 30pt The omitted start-indents are filled as follows: <fo:block start-indent="15pt" padding-left="9pt" border-left="6pt solid red"> Outer Block <fo:block start-indent="30pt" padding-left="9pt" border-left="6pt solid blue"> Inner Block </fo:block> </fo:block>
Disposition: Explanation of XSL spec
In XSL you have to explicitly specify margin=0 in order for the indent to be computed from the margin value. start- and end-indents are inherited properties and the traits are the indents not the margins. The current text has been expanded to make the computation rules clearer.
Links to the changed text in the XSL recommendation:
See link to changed text.
Problem 2: Inherited start-indent and end-indent on reference areas =================================================================== This problem has already been pointed out by other people. In http://www.renderx.com/Tests/doc/html/spec.html [XSL FO in XEP 2.01] <quote> Another situation where holistic inheritance scheme adopted in XSL FO CR produces indesirable side effects. According to the spec, indents are inherited from fo:table to its descendants, i.e. table cells. But inside cells, indents are measured from another reference edge! Apparently, this has the following effect: when you specify an indent for the table, the contents of each cell is shifted by the same amount from the edge of the cell. In XEP 2.01, the inheritance is broken at this point: if an object introduces a new reference area, start-indent and end-indent for it are not inherited from its parent. In particular, this applies to fo:table- cell, fo:block-container, and fo:inline-container. </quote> In my implementation, too.
Disposition: Explanation of why no change will be made
The design approach taken for XSL was to have a simple inheritance model. Making this change would obviously introduce an exception to this model. There are many other properties that one MIGHT not want to inherit from e.g. a table-and-caption to the content of the cells so why single out indent? If one, for example, wants to center a table-and-caption one specifies text-align="center" for the table-and-caption, which inherits to the cells.
There are also cases where it is necessary to be able to use the value of an indent value in effect outside a reference area inside it. One example is for "CSS side floats" where the floated object is to have the same indent as where the float was defined. In XSL this means that the indent of the content of the reference area generated by the fo:float should be the same as the indent of the fo in which the float occurred. In other cases, eg when using an "offset" style where paragraphs are indented, but "headings" are not, it is also more convenient to inherit the indents.
The consensus of the working group was to not introduce this breaking of the inheritance as it is sometimes very useful and in the cases where it is not what the stylesheet author wishes it is very easy to make an explicit specification of the desired indent. An example, using attribute-sets, has been added to the specification to show this.
Links to the changed text in the XSL recommendation:
See link to changed text.
Problem 3: Indents on list-item-label and list-item-body ======================================================== As shown in the above, inherited start- and end-indent values are sometimes not useful and should be modified. I request the following modification for solving the problem of inherited indents on list-item-label and list-item-body (label and body overlap when indents are not specified). on list-item-label: end-indent defaults to label-end() on list-item-body: start-indent defaults to body-start() Then, <fo:list-block> <fo:list-item> <fo:list-item-label> <fo:block>(1)</fo:block> </fo:list-item-label> <fo:list-item-body> <fo:block>List Item Body</fo:block> </fo:list-item-body> </fo:list-item> </fo:list-block> is now not an error and equivalent to: <fo:list-block> <fo:list-item> <fo:list-item-label end-indent="label-end()"> <fo:block>(1)</fo:block> </fo:list-item-label> <fo:list-item-body start-indent="body-start()"> <fo:block>List Item Body</fo:block> </fo:list-item-body> </fo:list-item> </fo:list-block>
Disposition: Explanation of why no change will be made
The working group felt that also in this case it was better to preserve the simple inheritance model.
Conclusion ========== This comment contains some requests to XSL-FO spec, and these features have already been built into my implementation, as well as my last comments: "XSL-FO - Initial value of border/padding conditionality" http://lists.w3.org/Archives/Public/xsl-editors/2000OctDec/0297.html Therefore, my implementation does not completely conform to the XSL-FO CR. IMHO, the XSL-FO spec is not complete yet and should be improved. Regards, MURAKAMI Shinyu "Antenna House XSL Formatter" - http://www.antennahouse.com/xslformatter.html
From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de> To: xsl-editors@w3.org Date: Fri, 12 Jan 2001 16:04:32 +0100 Message-ID: <3A5F2B10.2214.DE6DC2@localhost> Subject: small errors
In the following 2 paragraphs from section 6.10.1.3 it should be "flow-name" instead of "region-name" "If there is a fo:static-content in a page-sequence whose "region- name" property value is"xsl-before-float-separator", then the areas returned by formatting thefo:static-content are inserted in the proper order as the last children ofa before-float-reference- area that is generated using the same page-master,provided the main-reference-area on the page is not empty. If there is an fo:static-content whose "region-name" property value is"xsl-footnote-separator", then the areas returned by formatting thefo:static-content are inserted in the proper order as the initial children ofa footnote-reference-area that is generated using the same page-master.
Disposition: Accepted (editorial)
"region-name" changed to "flow-name" in two places.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
Fotis Jannidis
From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de> To: xsl-editors@w3.org Date: Fri, 12 Jan 2001 16:25:29 +0100 Message-ID: <3A5F2FF9.11052.F19CF6@localhost> Subject: small errors 2 (delete 1)
In the following 2 paragraphs from section 6.10.1.3 there is some problem. Either it should be "flow-name" instead of "region-name" in both cases, or the first paragraph is correct as it is (besides of 'a fo:' -> 'an fo:'), but then the sentence part "whose "region- name" property value is"xsl-before-float-separator"" refers to the page-sequence and I understood that the 'xsl' prefix is mostly used in flow-names. imho the second paragraph has to be corrected in any case. "If there is a fo:static-content in a page-sequence whose "region- name" property value is"xsl-before-float-separator", then the areas returned by formatting thefo:static-content are inserted in the proper order as the last children ofa before-float-reference- area that is generated using the same page-master,provided the main-reference-area on the page is not empty. If there is an fo:static-content whose "region-name" property value is"xsl-footnote-separator", then the areas returned by formatting thefo:static-content are inserted in the proper order as the initial children of a footnote-reference-area that is generated using the same page-master."
Disposition: Accepted (editorial)
"region-name" should be changed to "flow-name" in both places.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
btw, I don't think it would be horrible redundant to list all the flow- names which xsl:fo predefines (like xsl-region-body, xsl-region- before, xsl-before-float-separator, xsl-footnote-separator etc.) in section 7.24.5
Disposition: Accepted (editorial)
The list has been added as a note.
Links to the changed text in the XSL recommendation:
See link to changed text.
Fotis Jannidis
From: "Fotis Jannidis" <fotis.jannidis@lrz.uni-muenchen.de> To: xsl-editors@w3.org Date: Fri, 12 Jan 2001 16:42:53 +0100 Message-ID: <3A5F340D.32587.1018A45@localhost> Subject: addition to last msg
In the following paragraph from section 6.4.1.4. the spec also uses "region-name" instead of "flow-name": >>> In addition, an fo:static-content formatting object may have a "region-name" property value of "xsl-before-float-separator" or "xsl- footnote-separator". If a conditional sub-region of the region-body is used to generate a reference-area on a particular page, the fo:static-content whose name corresponds to the conditional sub- region shall be formatted into the reference-area associated with the sub-region, as specified in section [6.10.1.3 Conditional Sub- Regions]. <<<
Disposition: Accepted (editorial)
"region-name" changed to "flow-name".
Links to the changed text in the XSL recommendation:
See link to changed text.
fj
From: AndrewWatt2001@aol.com Message-ID: <14.e638c3f.27956ce0@aol.com> Date: Tue, 16 Jan 2001 04:22:40 EST To: XSL-FO@egroups.com CC: xsl-editors@w3.org Subject: Re: [XSL-FO] 1.1.2 Formatting ...please help
In a message dated 16/01/01 03:01:30 GMT Standard Time, r_diblasi@hotmail.com writes: Hi Robert, My $0.02 follows below. > Hello, > > What the hell.........I have been reading this sentence over and > over > and I understand each part but I do not understand the whole..... > > Formatting 1.1.2 > "Formatting interprets the result tree in its formatting object > tree form to produce the presentation intended by the designer of the > stylesheet from which the XML element and attribute tree in the "fo" > namespace was constructed." I think the short answer is that it is a badly drafted sentence. There are, IMHO, more than a few them in the current XSL-FO CR. If you examine the XSL-FO CR you will see that there is no identified "editor", unlike the position with a typical W3C spec in development. The absence of mention of an identified editor seems to be reflected in the absence, at this stage, of consistently tight editing of the text. > I think the last part is driving me crazy..... > > "the stylesheet from which the XML element and attribute tree in > the "fo" namespace was constructed." I think you have probably broken the sentence at the wrong place. Having said that try reading the whole sentence replacing "stylesheet from which" with "stylesheet using which". That is closer to what I think the editors mean. > Someone with a good heart help me..... > > I believe it to mean > Formatting interprets the result tree in its formatting object > form......(with Formating objects in the the result tree) ..... > to product the presentation intended by the designer of the > spreedsheet.......it all goes to hell after this point :-).... BTW when writing out the sentence you replace "produce" with "product" which makes it worse. :) LOL ... I have just scrubbed the reply I was about to make. I thought I had cracked it, but then it slipped through my fingers. :) Proves your point I guess. It's a horrible sentence. :) My attempt at a better version: "Formatting is the final step of a multi-step process. The first step is the production of an XML element and attribute tree (also known as a "result tree"), using an XSL style sheet and XML source document. The result tree is "objectified" into a tree in the XSL-FO Namespace. Formatting is the process of interpreting the result tree (the XML element and attribute tree), in its formatting object form, into a display [or visual presentation].". Just my $0.02. I would also say that for the XSL editors to attempt to equate the "intention" of the designer with the actual process of formatting/presentation is unwise. That only applies if the designer correctly writes a stylesheet to actually produce the result. In addition there is a further background suspicion I have (but haven't yet had time to look at properly) - that the term "formatting" is being used in more than one sense in the XSL-FO CR. > Help.... > Robert A. DiBlasi I hope that's clearer. BTW if you look at the diagram a little later in Section 1.1.2 that might help you visualise it. I have copied this reply to the XSL-editors at W3C. Hopefully they will take the problems with this sentence into account when further drafting/editing takes place. And if we have both failed to understand the meaning that is intended they may, hopefully, provide a response which can be posted on list.
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0048.html
From: AndrewWatt2001@aol.com Message-ID: <1e.100a798d.2796045d@aol.com> Date: Tue, 16 Jan 2001 15:09:01 EST To: XSL-FO@egroups.com CC: xsl-editors@w3.org Subject: Re: [XSL-FO] Re: 1.1.2 Formatting ...please help In a message dated 16/01/01 19:14:49 GMT Standard Time, r_diblasi@hotmail.com writes: > "with objects primarily in the "formatting object" namespace."???? > > What is the spec trying to say???? Robert, Due to time constraints I will respond only to this question at present. The XSL-FO spec uses three terms (as I read it) for the same thing - in each case the namespace URI is http://www.w3.org/1999/XSL/Format. The spec, as I recall, uses three terms each of which appears to me to refer to that same namespace URI and therefore mean the same. The three terms are: 1. XSL Namespace 2. "fo" namespace 3. "formatting objects" namespace I am doing all this from memory so forgive me if I slip up on a word or two. The spec also goes on to refer to "the" XSL Namespace. But there are, in fact, two "XSL" Namespaces. XSL consists of both XSLT and XSL-FO. The CR needs to edited more tightly in my opinion to reflect that reality. There is (my terms) 1. An XSLT namespace for which the namespace URI is http://www.w3.org/1999/XSL/Transform and 2. An XSL-FO namespace for which the namespace URI is http://www.w3.org/1999/XSL/Format Since both XSLT and XSL-FO **together** constitute "XSL" we have two distinct "XSL" namespaces with the respective namespace URIs which I have just given. In my view the XSL spec editors need to take that on board and introduce greater precision and consistency in the use of terms. I posted on another list recently about a related issue. I will try to dig that out and post it within the next hour or two. Andrew Watt
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0049.html
From: AndrewWatt2001@aol.com Message-ID: <55.fe42611.27960c74@aol.com> Date: Tue, 16 Jan 2001 15:43:32 EST To: XSL-FO@egroups.com CC: xsl-editors@w3.org Subject: A need for consistency and precision when referring to "XSL" Robert & others, The issue addressed in this post may go some way to help some list members understand why they are having problems understanding parts of the "XSL" Candidate Recommendation, which in my view would be better termed as the "XSL-FO" CR. What follows is a slight re-edit of a past post on another list. ***Re-edited quote begins*** This post is a plea for a beginning in consistent use of the term "XSL" in W3C documents. The current CR stage of XSL-FO and the first WD of XSLT 1.1 give an opportunity to W3C to remove longstanding inconsistent usage and to introduce coherence and consistency. For those who have not yet considered the problem let me summarise the difficulty and inconsistency by the use of two "equations" which summarise two mutually contradictory positions about what "XSL" is which are taken (implicitly or explicitly) in the current versions of W3C documents. To avoid ambiguity I use the term "XSLT" to indicate XSL Transformations and the term "XSL-FO" to indicate XSL Formatting Objects. The two equations are: 1. XSL = XSLT + XSL-FO (see e.g. Abstract of XSL-FO CR) 2. XSL = XSL-FO Stated as baldly as this I expect to potentially elicit howls of protest along the lines of "Of course XSL is the summation of XSLT and XSL-FO". But the statements currently present in various W3C documents contradict this assumed clarity and consistency. Let me illustrate. .... In the XSLT 1.0 Recommendation of November 1999 it is stated in the Abstract, "XSLT is also designed to be used independently of XSL.", a statement which cannot be true if XSL = XSL-FO + XSLT (XSLT cannot be used independently of "XSL" since XSLT is _part of_ "XSL") and contradicts, for example, the Abstract of the XSL-FO CR. However the statement also contradicts the position taken earlier in the Abstract of XSLT 1.0: "In addition to XSLT, XSL includes ....". So, XSLT seems to be "included in" XSL but is also can be used "independent of" it. Something doesn't add up. What is happening is that the first part of the preceding sentence refers implicitly to equation 1. and the latter part to equation 2. Thus, in theXSLT 1.0 Recommendation (and repeated verbatim in the XSLT 1.1 WD) we have the use of both "equations". Which equation is true? Does XSL = XSL-FO + XSLT or is XSL = XSL-FO? XSLT 1.0 effectively uses these two mutually contradictory positions within a few lines of each other. The same inconsistency also appears in the current XSL-FO CR. As mentioned above the Abstract indicates unequivocally that XSL includes both XSLT and XSL-FO. But in Section 2, confusingly labelled "Introduction to XSL Transformations" it is stated, "The XSL namespace has the URI http://www.w3.org/1999/XSL/Format.". The placement of a statement about what I would call the XSL-FO namespace in a section on XSLT is confusing enough. But if, as the Abstract of the CR implicitly states, XSL = XSL-FO + XSLT then there are two "XSL" namespaces viz. http:www.w3.org/1999/XSL/Format AND http://www.w3.org/XSL/Transform, not one as the XSL-FO CR states. There are many ways of slicing up these inconsistencies but, in my view, they are founded in the use of "XSL" in the same documents to have two distinct meanings. Is "XSL" the same as "XSL-FO + XSLT"? Or is "XSL" the same as "XSL-FO"? I would suggest that the W3C "XSL" editors ... by which I mean the editors for the XSL-FO CR and the new XSLT 1.1 WD need to decide what "XSL" is and then use the term precisely and consistently. At present neither precision nor consistency is achieved. I hope these two examples serve to illustrate the ambiguity or inconsistency of the use of the term "XSL" in current W3C documents. I could, quite possibly, go on at length about how the inconsistency plays out in various W3C documents. Rather, I think it is more important to find a solution that is logical, clear and consistent. Suffice to say that the inconsistency within XSL/XSL-FO/XSLT specs plays out to some degree in other specs too. My suggestion for how to move toward coherence would be: 1. Confine the generic term "XSL" to situations which refer to XSLFO _and_ XSLT collectively. 2. When referring to XSL Formatting Objects the abbreviation to be used should be either "XSL-FO" or "XSLFO". 3. When referring to XSL Transformations the abbreviation used should be "XSL-T" or "XSLT". 4. It should be recognised that there are two "XSL Namespaces". The XSLT Namespace has a namespace URI of http://www.w3.org/1999/XSL/Transform. The XSL-FO Namespace has a namespace URI of http://www.w3.org/1999/XSL/Format. 5. The confusing "indicative prefix" (my term) for those two namespaces should be corrected/made consistent. I would suggest that the XSLT namespace use the "indicative prefix" of "xslt" rather than "xsl" i.e. as an example, the present <xsl:stylesheet> element would become <xslt:stylesheet>. Similarly the "fo" indicative prefix would become "xslfo" i.e. <fo:root> would become <xslfo:root>. I would propose that the W3C Core XML Group (do I have the terminology correct?) review the current inconsistency in terminology across W3C specs currently in draft or under revision and give clear, unambiguous guidance on which meaning "XSL" has in W3C documents. <side_issue> [ With regard to the more specific problem relating to the naming of the current XSL-FO CR could that not be called the "Extensible Stylesheet Language Formatting Objects, XSL-FO" Recommendation in due time? And could another very short "XSL" REC indicate that XSL version 1.0 subsumes the XSLT REC of November 1999 and the XSL-FO REC, currently at CR stage? Then when XSLT 1.1 is finalised "XSL 1.1" could be defined as "XSL-FO 1.0" plus "XSLT 1.1"? Just a thought. :) ] </side_issue> Consistent usage of the term "XSL" is desirable. With the current fluidity of a XSL-FO CR and an XSLT 1.1 WD there is an early opportunity for W3C to introduce consistency where hitherto inconsistent and confusing usage of the term "XSL" has been rather too visible. *** Re-edited quote ends *** Returning to Robert's question about the "fo" namespace and the confusion that that term caused him - If my suggestions were adopted we would refer to that as the XSL-FO namespace with, in my view, much less ambiguity than a supposed but essentially spurious "XSL namespace". Sorry, to those for which this is pretty hard going. You need to be fairly familiar with how the specs use the terms to see that there is a problem. And perhaps more familiar to diagnose it and suggest a (hopefully coherent) remedy. I hope that the XSL-editors wil prove responsive to these suggestions. It would make teaching some parts of XSL/XSL-FO/XSLT to relative beginners just a little bit easier if the "standard" terms were used consistently in the definitive documents. Andrew Watt
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0056.html
To: AndrewWatt2001@aol.com Cc: XSL-FO@egroups.com, xsl-editors@w3.org From: Max Froumentin <mf@w3.org> Date: 22 Jan 2001 12:43:48 +0100 Message-ID: <878zo37qx7.fsf@sophia.inria.fr> Subject: Re: A need for consistency and precision when referring to "XSL" AndrewWatt2001@aol.com writes: > XSLT cannot be used independently of "XSL" since XSLT is _part of_ > "XSL" Why not? XPath is part of XSLT, but is used independently (by XLink, as it happens). > Does XSL = XSL-FO + XSLT or is XSL = XSL-FO? XSL = XSLT + XPath + XSL, hence XSLT+XPath=0! Just kidding :) XSL includes XSLT, and that's the only 'equation' one should write (or you could as well write XSL = XSLT+Xpath+FOs+CSS+XMLNameSpaces+XML, etc.) > The same inconsistency also appears in the current XSL-FO CR. Again, I don't see why a subset of a spec can't be used independently and hence use a different namespace. > At present neither precision nor consistency is achieved. It seems that things would be clearer to you if XSL was renamed XSL-FO or something similar and if the two specs were made independent. Well, one doesn't want that, as that would mean that XSL-FO can be used without XSLT, and that is just Wrong (as it's explained in the XSL spec). > 1. Confine the generic term "XSL" to situations which refer to XSLFO > _and_ XSLT collectively. It seems to me that this is most people's understanding. > 2. When referring to XSL Formatting Objects the abbreviation to be > used should be either "XSL-FO" or "XSLFO". That's also the case. > 3. When referring to XSL Transformations the abbreviation used > should be "XSL-T" or "XSLT". ditto. > 4. It should be recognised that there are two "XSL Namespaces". The > XSLT Namespace has a namespace URI of > http://www.w3.org/1999/XSL/Transform. The XSL-FO Namespace has a > namespace URI of http://www.w3.org/1999/XSL/Format. But everybody knows that! If you want, I hereby recognise that there are two XSL Namespaces. > 5. The confusing "indicative prefix" (my term) for those two > namespaces should be corrected/made consistent. I would suggest that > the XSLT namespace use the "indicative prefix" of "xslt" rather than > "xsl" i.e. as an example, the present <xsl:stylesheet> element would > become <xslt:stylesheet>. Similarly the "fo" indicative prefix would > become "xslfo" i.e. <fo:root> would become <xslfo:root>. The namespace prefix is something you decide when you write your XML file. It can be 'xslt:', 'britneyspears:', you name it. And you can write '<xslt:transform ...>' rather than '<xsl:stylesheet>' if you want. I agree that using xsl: in the text of the xslt spec is probably not the best choice. You might want to re-submit that to xsl-editors (in a shorter message). > [ With regard to the more specific problem relating to the naming of > the current XSL-FO CR could that not be called the "Extensible > Stylesheet Language Formatting Objects, XSL-FO" Recommendation in > due time? no. BTW, what's XSL-FO@egroups.com? Max. W3C XSLTFO working group.
Disposition: Explanation of why no change will be made
XSL is the umbrella name for the eXtensible Stylesheet Language that includes XSLT and XSL Formatting Objects. XSLT includes Xpath as the addressing and navigation mechanism. XSL Formatting Objects represent the set of typographic abstractions available to the designer. Sometimes people use these terms interchangeably. For example, XSL may be used to talk about XSLT only; this is inappropriate. To talk about XSL Formatting Objects people use the terms "XSL" and "XSL FO" interchangeably. We believe that this is where the confusion arises. For many reasons, we have not been able to develop an alternate nomenclature that works. We hope we have clarified the appropriate usage of the terms.
Andrew Watt
Date: Tue, 23 Jan 2001 11:09:28 -0500 (EST) Message-ID: <3A6DACBA.515EEB59@powerup.com.au> From: "Peter B. West" <pbwest@powerup.com.au> To: xsl-editors@w3.org Subject: [Fwd: Typo in 4.2.5 Stacking Constraints] Forwarded on advice from Max Froumentin. -------- Original Message -------- Subject: Typo in 4.2.5 Stacking Constraints Date: Sun, 21 Jan 2001 17:57:38 +1000 From: "Peter B. West" <pbwest@powerup.com.au> Reply-To: pbwest@powerup.com.au Organization: Dis To: fop-dev@xml.apache.org References: <3A681DEA.18886.840F8E@localhost> <3A6A8DBD.CF39F0F2@powerup.com.au>
There is a small typo in the above section. Compare b. and c. b. B is the first normal child of a block-area, B is not a line-area, P, there is no fence preceding P, A and P have a block-stacking constraint S', and S consists of S' followed by the space-before of B; or c. A is the last normal child of a block-area P, A is not a line-area, there is no fence following P, P and B have a block-stacking constraint S'', and S consists of the space-after of A followed by S''.
Disposition: Accepted (editorial)
The "P" in the first case has been moved to be after "block-area".
Links to the changed text in the XSL recommendation:
See link to changed text.
Peter -- Peter B. West pbwest@powerup.com.au "Lord, to whom shall we go?"
Date: Tue, 23 Jan 2001 11:11:13 -0500 (EST) Message-ID: <3A6DAD33.6FF2902B@powerup.com.au> From: "Peter B. West" <pbwest@powerup.com.au> To: xsl-editors@w3.org Subject: [Fwd: Adjacent edges in 4.2.5 Stacking Constraints] -------- Original Message -------- Subject: Adjacent edges in 4.2.5 Stacking Constraints Date: Mon, 22 Jan 2001 22:47:12 +1000 From: "Peter B. West" <pbwest@powerup.com.au> Reply-To: pbwest@powerup.com.au Organization: Dis To: fop-dev@xml.apache.org References: <3A681DEA.18886.840F8E@localhost><3A6A8DBD.CF39F0F2@powerup.com.au> <3.0.6.32.20010121144340.007ff600@chebucto.ns.ca>
A question about the definition of adjacent edges in 4.2.5. The following definitions refer to the block-stacking-constraints.gif image. (Wouldn't it be useful to have numbered figures? Wouldn't it be useful to have an index?) Adjacent Edges with Block-stacking When A and B have a block-stacking constraint, the adjacent edges of A and B are an ordered pair recursively defined as: * In case 1, the before-edge of the content-rectangle of A and the before-edge of the allocation-rectangle of B. * In case 2, the after-edge of the content-rectangle of A and the after-edge of the allocation-rectangle of B. I don't have much of a grasp of this section, but shouldn't case 2 read: * In case 2, the after-edge of the allocation-rectangle of A and the after-edge of the content-rectangle of B? I.e., for contained areas, the appropriate relationship is between the content-rectangle of the containing area, and the allocation-rectangle of the contained area?
Disposition: Accepted (editorial)
Yes there is a typo in the spec.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
Peter -- Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest "Lord, to whom shall we go?"
Date: Tue, 23 Jan 2001 11:11:09 -0500 (EST) Message-ID: <3A6DAD01.D99AE3FB@powerup.com.au> From: "Peter B. West" <pbwest@powerup.com.au> To: xsl-editors@w3.org Subject: [Fwd: large-allocation-rectangle of inline-area] Forwarded on advice from Max Froumentin. -------- Original Message -------- Subject: large-allocation-rectangle of inline-area Date: Sun, 21 Jan 2001 17:20:29 +1000 From: "Peter B. West" <pbwest@powerup.com.au> Reply-To: pbwest@powerup.com.au Organization: Dis To: fop-dev@xml.apache.org References: <3A681DEA.18886.840F8E@localhost>
The diagram AllocationRectInline-large.gif which illustrates the large-allocation-rectangle of an inline-area in 4.2.3 Geometric Definitions, appears to contradict the text. The text has: The large-allocation-rectangle is the border-rectangle. The diagram puts this rectangle in black around Spaces, outside the Border Rectangle. In addition, in the distributed multi-file HTML set, the diagram is incorrectly named, and does not appear in the text. (I think the "large" was capitalised in the file name.)
Disposition: Accepted (clarification)
The figure is very unclear and has been replaced with one where arrows indicate for each label which rectangle is meant.
Links to the changed text in the XSL recommendation:
See link to changed text.
Peter -- Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest "Lord, to whom shall we go?"
Date: Tue, 23 Jan 2001 11:12:06 -0500 (EST) Message-ID: <3A6DAD51.8349EB0C@powerup.com.au> From: "Peter B. West" <pbwest@powerup.com.au> To: xsl-editors@w3.org Subject: [Fwd: Block-stacking constraint example in 4.2.5] -------- Original Message -------- Subject: Block-stacking constraint example in 4.2.5 Date: Mon, 22 Jan 2001 22:57:18 +1000 From: "Peter B. West" <pbwest@powerup.com.au> Reply-To: pbwest@powerup.com.au Organization: Dis To: fop-dev@xml.apache.org References: <3A681DEA.18886.840F8E@localhost><3A6A8DBD.CF39F0F2@powerup.com.au> <3.0.6.32.20010121144340.007ff600@chebucto.ns.ca>
The tree node diagram at the beginning of the above example (mantree.gif), I personally would prefer to see replaced by nested block diagrams as are used (block-stacking-constraints.gif) to illustrate the concept of block-stacking constraints. I.e., block diagrams including the stacking constraints, and also the fence-after B which eliminates the D-E constraint.
Disposition: Explanation of why no change will be made
The idea behind this form of the diagram is to emphasize that this relationship is deducible from the tree structure and trait values, not the geometric proximity of the areas.
Peter -- Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest "Lord, to whom shall we go?"
Date: Sat, 27 Jan 2001 07:13:42 -0500 (EST) Message-ID: <3A72BB5B.12843B4C@powerup.com.au> From: "Peter B. West" <pbwest@powerup.com.au> To: fop-dev@xml.apache.org CC: xsl-editors@w3.org Subject: 5.3.2 Margin, Space, and Indent Properties
The above section seems to define the relationship between, say, end-indent and padding/border/space-end shown in the diagram RectsForModel.gif in 4.4.1 Stacked Block-areas. I.e., end-indent = padding-end + border-end + space-end, where, according to 5.3.2, space-end has a corresponding margin property. 5.3.2 has end-indent = margin-corresponding + padding-end + border-end-width What does this do to the following announcement in 4.4.1? 1. For each block-area B which is a descendant of P, the following hold .... * the end-edge of its allocation-rectangle is parallel to the end-edge of the content-rectangle of R, and offset from it inward by a distance equal to the block-area's end-indent plus its end-intrusion-adjustment (as defined below), minus its border-end, padding-end, and space-end value Isn't that saying, "...a distance equal to the block-area's end-indent plus its end-intrusion-adjustment minus its end-indent"? That's what the diagram seemed to indicate when I first read 4.4.1, and now, having just read 5.3.2 (I'm a slow reader of specifications) that initial impression is confirmed. What am I missing?
Disposition: Explanation of XSL spec
Section 5.3.2 has an error in that one should also add inherited-*-indent to obtain the *-indent from the *-margin. (Murakami pointed this out in a posting to the editor's list).
Indents are "absolute" i.e. with respect to the containing reference area. Margins are with respect to the "containing block" and as such an indent is equal to the sum of the ancestor blocks' margins.
Links to the changed text in the XSL recommendation:
See link to changed text.
Peter -- Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest "Lord, to whom shall we go?"
Date: Sat, 27 Jan 2001 09:14:33 -0500 (EST) Message-ID: <3A72D7D8.4ECB0A08@powerup.com.au> From: "Peter B. West" <pbwest@powerup.com.au> To: fop-dev@xml.apache.org CC: xsl-editors@w3.org Subject: 5.3.3 Height, and Width Properties
The above section has a number of paragraphs like: * If any of "height", "min-height", or "max-height" is specified: * If "height" is specified then first set: block-progression-dimension.minimum=<height> block-progression-dimension.optimum=<height> block-progression-dimension.maximum=<height> * If "height" is not specified, then first set: block-progression-dimension.minimum=auto block-progression-dimension.optimum=auto block-progression-dimension.maximum=auto * Then, if "min-height" is specified, reset: block-progression-dimension.minimum=<min-height> * Then, if "max-height" is specified, reset: block-progression-dimension.minimum=<max-height> Shouldn't the last read: Then, if "max-height" is specified, reset: block-progression-dimension.MAXimum=<max-height> ? There are four such instances.
Disposition: Accepted (bug in spec)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
Peter -- Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest "Lord, to whom shall we go?"
Message-ID: <3A8C62BE.7A5C29AC@club-internet.fr> Date: Fri, 16 Feb 2001 00:14:06 +0100 From: Karen Lease <klease@club-internet.fr> To: xsl-editors@w3.org CC: fop-dev@xml.apache.org Subject: Interaction of shorthand and corresponding properties Dear editors,
Could you one of you please comment on the following cases assuming the block progression direction is top to bottom : A <fo:block padding="3pt" padding-top="4pt">.... According to 5.2 and 5.3.1, I see the following property values being set for padding-top and padding-before. padding-before=0pt, padding-top=0pt (initial values) padding-top=3pt (from the shorthand) padding-top=4pt (set explicitly) padding-before=4pt (set from the corresponding padding-top property) Now supposing we have this: B <fo:block padding="3pt" padding-before="4pt">.... This seems to imply the following values being set padding-before=0pt, padding-top=0pt (initial values) padding-top=3pt (from the shorthand) padding-before=3pt (set from the corresponding padding-top property, so the explicit setting of 4pt is ignored!) What I (as a user) expect to happen is this: padding-before=4pt (set explicitly) padding-top=4pt (set from the corresponding padding-before property ???) In 5.3.1, the CR says: "If the corresponding absolute variant of the property is specified on the formatting object, its computed value is used to set the computed value of the corresponding relative property. If the corresponding absolute property is not explicitly specified, then the computed value of the absolute property is set to the computed value of the corresponding relative property." This rule works fine for case A. In case B, it seems that I can only get padding-before (and padding-top) set to 4pt if I consider that the shorthand is not equivalent to setting the absolute property explicitly, so that the explicit value of the relative property is used (for both). But then what about this? C <fo:block padding="3pt">.... This seems to imply the following values should be set: padding-before=0pt, padding-top=0pt (initial values) padding-top=3pt (from the shorthand) padding-before=3pt (set from the corresponding padding-top property) But here, I want to use the value set by the shorthand to set the relative property. In other words, the behavior that seems natural is that the shorthand setting of the absolute property is "weaker" than the explicit setting of the corresponding relative property. If that's what you meant, perhaps you could make it clearer in the next (final?) version.
Disposition: Accepted (clarification)
Text to clarify that your last paragraph is indeed the intended meaning has been added.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
Thanks in advance for your feedback, Karen Lease (FOP contributer) --------------------------------------------------------------------- To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org For additional commands, email: fop-dev-help@xml.apache.org
Date: Thu, 15 Feb 2001 18:18:33 -0500 (EST) Message-ID: <3A8C6559.17344CA4@club-internet.fr> From: Karen Lease <klease@club-internet.fr> To: xsl-editors@w3.org CC: fop-dev@xml.apache.org Subject: Meaning of keyword "inherit" for non-inheritable properties Hello again,
I suppose this has been mentioned before, but it still bothers me to be able to specify xxx="inherit" when xxx isn't inheritable. (Of course, if it is inheritable, there's no reason to say so, since if xxx isn't specified, it will get the value from its parent.) The meaning seems to be identical to xxx="from-parent(xxx)", including the case of shorthand properties. So is this just to simplify life for users?
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0099.html
Message-Id: <4.2.0.58.J.20010218171618.03cec830@sh.w3.mag.keio.ac.jp> Date: Sun, 18 Feb 2001 17:18:35 +0900 To: Karen Lease <klease@club-internet.fr>, xsl-editors@w3.org From: Martin Duerst <duerst@w3.org> Cc: fop-dev@xml.apache.org Subject: Re: Meaning of keyword "inherit" for non-inheritable properties At 18:18 01/02/15 -0500, Karen Lease wrote: >Hello again, > >I suppose this has been mentioned before, but it still bothers me to be >able to specify xxx="inherit" when xxx isn't inheritable. Please change 'inheritable' to 'inherited', and everything looks much more reasonable (I'm not sure where you got the word 'inheritable' from, I hope it's not in the spec itself.) Either a property is (by default) inherited, or it can be inherited by specifying 'inherit' as a property value. Regards, Martin. >(Of course, if >it is inheritable, there's no reason to say so, since if xxx isn't >specified, it will get the value from its parent.) > >The meaning seems to be identical to xxx="from-parent(xxx)", including >the case of shorthand properties. > >So is this just to simplify life for users? > >Karen Lease (FOP contributor)
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0107.html
To: Karen Lease <klease@club-internet.fr> Cc: xsl-editors@w3.org From: Max Froumentin <mf@w3.org> Date: 20 Feb 2001 13:37:21 +0100 Message-ID: <yq8elwtv8ce.fsf@jfouffa.inria.fr> Subject: Re: Meaning of keyword "inherit" for non-inheritable properties Karen Lease <klease@club-internet.fr> writes: > I suppose this has been mentioned before, but it still bothers me to be > able to specify xxx="inherit" when xxx isn't inheritable. I guess one should read 'Inherited by default: none' where the spec says 'Inherited: no'. > (Of course, if it is inheritable, there's no reason to say so, since > if xxx isn't specified, it will get the value from its parent.) In CSS, it makes sense to specify 'inherit' as a value even though the property is inheritable because the value may have been set to something else in the cascading process and you want to override it. In XSL it also makes sense, but for shorthand properties. For example you might have (probably as the result of the expansion of a use-attribute-set): font="bold 12pt helvetica" font-size="inherited". font-size is inherited by default but you still have to specify it to override the shorthand property. Does this answer your question? Max.
Disposition: Explanation of why no change will be made
The "inherit" keyword, as well as the term "inheritable", are both used in CSS2 and for compatibility reasons are used in XSL as well (even if "copy from parent" would have been more natural).
Karen Lease (FOP contributor)
Message-Id: <p05010404b6ba642a6c1b@[204.210.33.45]> Date: Wed, 21 Feb 2001 22:40:56 -0800 To: xsl-editors@w3.org From: Susan Lesch <lesch@w3.org> Subject: Comments for CR-xsl-20001121 These are comments for your XSL 1.0 Candidate Recommendation [1] "work in progress," based on one reading. It is a beautiful piece of work. Most likely I missed a few things, and hope to read this again when/if it reaches Proposed Recommendation. General -------
There appears to be a glitch in a production script or DTD that is adding unneeded table markup in the form of default and empty HTML attribute values. For example, there are over 5000 occurrences of "rowspan="1" colspan="1" align="left"." Removing extraneous table markup will cut the HTML version by 15%, from 1.5 down to 1.2MB (more than 25% for section 7 alone).
Disposition: Accepted (editorial)
Chapter 2, Introduction to XSL Transformation, has little to do with XSLT and a lot about Namespaces in XML. Should this chapter have a new title?
Disposition: Accepted (editorial)
The title has been changed to "XSL Transformation", which is a more appropriate title and does more naturally contain namespace information pertinent to xsl transformation usage.
Links to the changed text in the XSL recommendation:
See link to changed text.
I would save 10k and omit 6.3 Formatting Objects Summary, since this information is repeated on the same page.
Disposition: Explanation of why no change will be made
6.3 provides a short summary for each formatting object to aid the reader in finding which object he may be searching for; the WG feels it a useful navigation aid.
In the 7.2 table, the top row should be th elements to meet level-A Web Content Accessibility Guidelines; (see checkpoint 5.1 on http://www.w3.org/TR/WAI-WEBCONTENT/#gl-table-markup). <th>Box</th><th>Area</th>
Disposition: Accepted (editorial)
Colors as well as border widths would help to differentiate the three kinds of property descriptions in section 7. (I'm not certain that they need to be differentiated at all since they are labeled, but was mildly confused by the presence and absence of two different yet similar black borders.)
Disposition: Accepted (editorial)
The border has been changed to be black for CSS2 properties, and gray for CSS2 derived properties.
Globally --------
Reserved words like fo and property names, datatype names, units and boolean values are sometimes plain text, sometimes in double quotes, sometimes in single quotes, sometimes in angle brackets, sometimes bold, and once in a while monospace. (Some of these treatments come from CSS2.) It's a big job to change them all, but it would help the reader if you could establish and stick to a pattern.
Disposition: Explanation of why no change will be made
We agree that it would be nice if the quotation and font weight was consistent, but in addition to changes in the XSL text it would require changes to quoted CSS2 text as well.
"White space" is two words. DSSSL has it as one word, and Merriam-Webster, American Heritage, and XML give it as two. (See http://www.w3.org/TR/REC-xml#sec-white-space.) "Word space" and "letter space" are two words also, and not hyphenated.
Disposition: Accepted (editorial)
The convention for text, except for text quoted from CSS2, has been changed to "white space", "word space", "letter space". For property names and values hyphens are used to separate the parts.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
Globally and in particular in 7.14.7 "linefeed-treatment", line feed is two words; (see http://www.unicode.org/charts/PDF/U0000.pdf). Maybe this property should be named line-feed-treatment. Also, in 7.14.8, ignore-if-before-linefeed -> ignore-if-before-line-feed, etc.
Disposition: Explanation of why no change will be made
The WG feels that linefeed as one word is better in the property name.
As far as I know, user agent is not a proper noun. Throughout the spec, it is most often capitalized, sometimes not. It could be lowercase always, or always one way or the other.
Disposition: Explanation of why no change will be made
We tried to match CSS "cap U cap A". CSS is, however, inconsistent and we cannot change it there.
When referring to a W3C Recommendation, "Recommendation" is capitalized (following Process Document usage, see http://www.w3.org/Consortium/Process/).
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
Mentions of the Unicode bidirectional algorithm need to be uniform. Maybe these notes will help. Unicode is capitalized and the other two words are not. UAX#9 has two occurrences of "BIDI" and none for "bidi." So, for its first occurrence, say Unicode bidirectional (BIDI) algorithm and then Unicode BIDI algorithm or else spell out the whole name each time.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
Images ------
If there is time, could all the images match? For example in section 4 they look like the work of a few different people.
Disposition: Explanation of why no change will be made
For practical reasons the graphics have indeed been created by several people using different tools.
It would be very nice if the W3C, in addition to supplying excellent editorial review support, also offered a drawing service to ensure that the illustrations in all W3C Recommendations were of uniform style.
In sections 1, 4, 6 and 7, all images need alt text and real rather than GIF text so that people who cannot see the illustrations can follow. Section 7 looks good and may need only minor changes. Here's one way, for section 1. <div class="image"> <p class="caption">XSL Two Processes: Transformation and Formatting</p> <p><img src="two-process.gif" alt="Diagram of XSL conceptual model, showing a source tree, a result tree with element and attribute nodes, and XSL formatters including a printer, a cell phone, and a Web browser."></p> <p class="explanation">The result tree is the result of XSLT processing.</p> </div>
Disposition: Accepted (editorial)
Alt text has been added to all the graphics.
In 4.10, in the sample area tree image, letter spacing is off and some text is covered. Could this image (page-area-tree.gif) be fixed? Some labels in japaneseblock3.gif in section 4.2.3 also have minor letter spacing problems. In 6.4.1.6, the top of the top "f" and the right side of the right-hand "w" are missing.
Disposition: Accepted (editorial)
These "problems" are due to rasterization difficulties in the graphics packages used to create a gif image of a size that would fit into a normal browser window. For detailed studies of the graphics the PDF version of the Recommendation should be used, as these graphics can be made at a higher resolution.
page-area-tree and PageTree have been replaced by gif files rasterized using a different graphics package and this has made some improvements.
In 6.4.12, the vertical labels are unreadable in the peach colored part of PageAndRegion-bodyWithOrientationOnPage.gif (third image). Otherwise, this is a really nice diagram.
Disposition: Accepted (editorial)
The size of the text has been increased, while keeping the graphic at its current size to fit in a typical browser window.
References ----------
You might alphabetize references.
Disposition: Explanation of why no change will be made
The references are grouped by topic, which the WG feels is more appropriate than alphabetical.
In "W3C XML," "W3C XML Names," and "W3C XML Stylesheet," why say "W3C" in the short name of some and not all W3C references? W3C can be omitted.
Disposition: Accepted (editorial)
W3C has been omitted in the short name.
In D.1, XML 1.0 is of course now in its second edition, and "See http://www.w3.org/TR/1998/REC-xml-19980210" can read "See http://www.w3.org/TR/2000/REC-xml-20001006".
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
In D.2 W3C XML Stylesheet W3C Working Draft. See http://www.w3.org/TR/WD-xml-stylesheet becomes: W3C Recommendation. See http://www.w3.org/TR/xml-stylesheet/
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
In D.1, the citation would be: Unicode Standard Annex #9: The Bidirectional Algorithm (see http://www.unicode.org/unicode/standard/versions/)
Disposition: Accepted (editorial)
The reference has been changed to conform to the reference format given in http://www.unicode.org/unicode/standard/versions/.
Links to the changed text in the XSL recommendation:
See link to changed text.
In D.2, UNICODE TR10 is Unicode Technical Standard #10 (a UTS rather than UTR and no longer a draft).
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
In D.2, UNICODE TR20 is Unicode Technical Report #20 (no longer a draft).
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
Also for the three Unicode references, index.html can be cut from the URI.
Disposition: Accepted (editorial)
For 7.8.1, 7.8.2, 7.28.24, and D.1, the reference can be RFC 3066; (RFC 1766 is obsolete). See http://www.ietf.org/rfc/rfc3066.txt.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
RFC 2119 can be a normative reference, and section 8 could say: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Please see RFC 2119 at http://www.ietf.org/rfc/rfc2119.txt. If you don't want to use the RFC, those words need definitions if used in section 8.
Disposition: Accepted (editorial)
Text has been added to section 8 to state that the words in the section are used in accordance with RFC 2119.
Links to the changed text in the XSL recommendation:
See link to changed text.
Minor typos ----------- From here down, a section number is followed by a quote and then a suggestion.
Authors and Contributors ArborText Arbortext
Disposition: Accepted (editorial)
Status of this document encourges encourages
Disposition: Accepted (editorial)
1.2.1 XPath (first occurrence) <a href="sliceD.html#XPATH">[XPath]</a>
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
1.2.1 par. 5 line-feeds line feeds
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
1.2.5 last par. (they are dictionary words) used for sub- and super-scripts used for sub- and superscripts
Disposition: Accepted (editorial)
The full form has been used for both (to make it easier for non-native English speakers).
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
4.2.2 last list item needs closing parenthesis.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
5.2 Note (first occurrence of conformance) and 7.28 par. 1 Shorthands are only included in the highest XSL conformance level: "complete". could link to <a href="slice8.html">[8. Conformance]</a>
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
5.8 par. 2 based on both of an implicit part based on both an implicit part
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
5.8 par. 4 UNICODE TR-9 Unicode Standard Annex #9 or UAX#9 or [UNICODE TR9] (not sure which is best but I don't think it's hyphenated)
Disposition: Accepted (editorial)
Replaced with a bibliography reference.
Links to the changed text in the XSL recommendation:
See link to changed text.
5.8 last Note spliting splitting
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
5.9.6 last par. value of property value of a property
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
5.9.7 needs an ending period.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
5.9.9 (link needed at first occurrence) Only RGB (Red, Green, Blue) and ICC (International Color Consortium) Only RGB (Red, Green, Blue) [sRGB] and ICC (International Color Consortium) [ICC] (adding a new reference, http://www.w3.org/Graphics/Color/sRGB.html)
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
5.11 <uri-specification> URI-reference URI reference
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.3 bidi-override Unicode-bidirectionality algorithm direction Unicode-bidirectional-algorithm direction
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.4 par. 3 function[5.10.2 Color Functions] function [5.10.2 Color Functions]
Disposition: Accepted (editorial)
6.4.4 list item 2 sRGB Needs a link to references [sRGB].
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.7 Constraints Note that the mapping of sub-sequences of the sequence of pages to sub-sequence-specifiers need not be onto; ^ (I wasn't sure if "onto" meant one to one.)
Disposition: Accepted (editorial)
The intention is "onto". The text has, however, been changed to make the reading easier.
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.10 Constraints the sub-sequence of pages consist the sub-sequence of pages consists
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.4.19 Constraints if P is a page-reference-area C is an area-class, and if P is a page-reference-area, C is an area-class, and
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.5.2 Note after Trait Derivation: uasge usage
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.6.3 par. 4 Unicode Special-use tag characters Unicode special-use tag characters (see http://www.unicode.org/unicode/reports/tr7/index.html)
Disposition: Accepted (editorial)
Unicode 3.1 calls these "Tag Characters" and the text is included in the Standard obsoleting TR 7. The sentence and note have been reworded to take this into account.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
6.6.3 Constraints The dimensions of the area is The dimensions of the area are
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.6.5 last Note For example, using a size of 1/96" as the size of one pixel for rasterized images. is an incomplete sentence.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.6.7 Contents a descendant an fo:leader a descendant of an fo:leader
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.7.1.1.1 par. 1 specificed specified
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.10.3 Constraints par. 3 fo:foonote fo:footnote
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
6.11.1.1 the "code" elements are using a Courier font the "code" elements using a Courier font
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.3.1 second to last par. W3C Accessibility guidelines W3C accessibility guidelines (which ones? Can you link to them?)
Disposition: Accepted (editorial)
What is meant is the collection of guidelines developed by the W3C WAI Initiative. Links have been added in the text.
Links to the changed text in the XSL recommendation:
See link to changed text.
7.3.2 An URI-specification A URI-specification
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.3.2 second to last par. (QName [W3C XML Names] Needs a closing parenthesis.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.7.1 par. 8 Far-Eastern (twice) Far Eastern (not sure eastern and western have global meaning either)
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
7.7.1 caption for second illustration EM Box EM box
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
Example 4 example 4
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.7.4 last par. rounded the nearest whole pixel rounded to the nearest whole pixel
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.7.7 backslant and 7.7.8 second to last par. (http://www.w3.org/TR/REC-CSS2/fonts.html#algorithm") (http://www.w3.org/TR/REC-CSS2/fonts.html#algorithm)
Disposition: Accepted (editorial)
7.12 par. before last illustration super-script (or sub-script) superscript (or subscript)
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
In 7.20.4, ending double quote can be cut.
Disposition: Accepted (editorial)
7.21.2 Note sub-title subtitle (It's a dictionary word. Not sure that is what is meant.)
Disposition: Accepted (editorial)
Yes it is meant to be "subordinate" titles.
Links to the changed text in the XSL recommendation:
See link to changed text.
7.24.8 media: viaual visual
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.24.10 bounded-in-one-dimension second par. can have an ordered list: ...There are four cases: 1. the "reference-orientation" is "0" or "180" and the "writing-mode" is horizontal; 2. the "reference-orientation" is "0" or "180" and the "writing-mode" is vertical; 3. the "reference-orientation" is "90" or "270" and the "writing-mode" is horizontal; 4. the "reference-orientation" is "90" or "270" and the "writing-mode" is vertical. For cases 1 and 3, the "page-width" is bounded and the "page-height" is not bounded. For case 2 and 4, the "page-height" is bounded and the "page-width" is not bounded....
Disposition: Explanation of why no change will be made
There seems to be little gain in presenting the information in a list form and for a typical browser/page size it risks taking up more space and XSL is long as it is...
7.24.12 and 7.24.14 auto: continous continuous
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
A fallback to 11.0in would fit on both 8+1/2x11 and A4 pages). A fallback to 11in would fit on both 8 1/2 x 11 and A4 pages. (not sure there)
Disposition: Accepted (editorial)
Changed to "11.0in would fit on both Letter size (8.5in by 11.0in) and A4 size pages.".
Links to the changed text in the XSL recommendation:
See link to changed text.
7.26 Note list item 2 Table table
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.26.4 use-font-metrics dominat dominant
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.26.5 <length> domiant dominant
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.26.7 please see the "Internationalization Appendix". please see <a href="sliceA.html">[A Internationalization]</a>.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
7.28.13 "smallcaption" small-caption or small caption
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
In B.7, there's an extra period after the aural fallback.
Disposition: Accepted (editorial)
C.1 Refine Refinement refinement
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
[1] http://www.w3.org/TR/2000/CR-xsl-20001121/ Best wishes for your project, -- Susan Lesch - mailto:lesch@w3.org tel:+1.858.483.4819 World Wide Web Consortium (W3C) - http://www.w3.org/
From: Tony Graham - Sun Ireland - Staff Engineer <Tony.Graham@ireland.sun.com> Message-ID: <15015.37303.193881.935018@gargle.gargle.HOWL> Date: Thu, 8 Mar 2001 14:05:43 +0000 (GMT) To: xsl-editors@w3.org Subject: W3C XML Stylesheet in CR-xsl-20001121
The non-normative reference [W3C XML Stylesheet] in CR-xsl-20001121 refers to the working draft of what is now a W3C Recommendation. The URL for the Recommendation is http://www.w3.org/TR/xml-stylesheet/.
Disposition: Accepted (editorial)
The reference has been updated.
Regards, Tony Graham ------------------------------------------------------------------------ Tony Graham mailto:tony.graham@ireland.sun.com Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708
Date: Sat, 31 Mar 2001 00:20:08 -0500 (EST) Message-ID: <3AC5593A.8C0FF1C6@powerup.com.au> From: "Peter B. West" <pbwest@powerup.com.au> To: xsl-editors <xsl-editors@w3.org> CC: fop-dev <fop-dev@xml.apache.org> Subject: Ambiguities in XSL 1.0 spec
6.4.14 fo:region-before Areas: The inline-progression-dimension of the region-viewport-area is determined by the precedence trait on the fo:region-before. If the value of the precedence trait is true, then the inline-progression-dimension extends up to the **start- and after-edges** of the content-rectangle of the page-reference-area. In this case, the region-before region-viewport-area acts like a float into areas generated by the region-start and region-end. Should `start- and after-edges' be `start- and end-edges'? Likewise for 6.4.15 fo:region-after.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
7.12 Area Alignment Properties
Diagram Baselines-rev.gif Note position of text-before-edge and text-after-edge. Discussion in NOTE to text-before-edge for ideographic scripts seems to contradict the diagram. 'For ideographic fonts, the position of this baseline is normally 1 EM in the shift-direction from the "ideographic" baseline.' In the diagram, possibly due to the presence of non-ideographic fonts, the text-before-edge seems to be 1 EM in the shift-direction from the text-after-edge, and inside the EM box which is based on the ideographic baseline.
Disposition: Explanation of XSL spec
The "text-before-edge" and "text-after-edge" shown in the figure is, as is stated in the text, computed under the assumption that it is the "alphabetic" baseline that is the dominant-baseline. IF the assumption had been instead that it was the "ideographic" baseline then the edge would have been as you describe.
The first NOTE to the discussion of after-edge is unclear. 'If all the inline-areas in a line-area are aligned to the "after-edge" then the specification for the "before-edge" will set the "before-edge" baseline to coincide with the "text-before-baseline" of the line. Then, case (2) above will determine an offset to the "bottom-edge" baseline that will align the "before-edge" of the area with the greatest height to its allocation-rectangle to "before-edge" baseline.' Perhaps something along the lines of: 'Then, case (2) above will determine the offset to the "bottom-edge" baseline so as to fit the area with the tallest allocation-rectangle (in the block-progression direction.) When the "after-edge" of that tallest area is aligned to the "after-edge" baseline, the "before-edge" of the area coincides with the "before-edge" baseline.'
Disposition: Accepted (editorial)
The sentence has been rewritten, but the formulation suggested by the commentator cannot be used verbatim as it mixes absolute-direction terms like "bottom" and "tallest" with the relative designations of "before-edge" and "after-edge".
Links to the changed text in the XSL recommendation:
See link to changed text.
Peter -- Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest "Lord, to whom shall we go?"
From: Tony Graham - Sun Ireland - Staff Engineer <Tony.Graham@ireland.sun.com> Message-ID: <15069.24449.973975.186838@gargle.gargle.HOWL> Date: Wed, 18 Apr 2001 10:33:53 +0100 (BST) To: xsl-editors@w3.org Subject: Minor typo in abs() description in XSL CR
The description of abs() in Section 5.10.1 begins: The abs functions returns... "functions" should be "function".
Disposition: Accepted (editorial)
The description of system-font() in Section 5.10.3 has the same problem.
Disposition: Accepted (editorial)
Regards, Tony Graham ------------------------------------------------------------------------ Tony Graham mailto:tony.graham@ireland.sun.com Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708
From: Tony Graham - Sun Ireland - Staff Engineer <Tony.Graham@ireland.sun.com> Message-ID: <15069.34479.174156.202345@gargle.gargle.HOWL> Date: Wed, 18 Apr 2001 13:21:03 +0100 (BST) To: xsl-editors@w3.org Subject: "min" in definition of max() in XSL CR
The definition of max() in Section 5.10.1 begins: The min function returns... "min" should be "max".
Disposition: Accepted (editorial)
Regards, Tony Graham ------------------------------------------------------------------------ Tony Graham mailto:tony.graham@ireland.sun.com Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708
The list definitions of of "primitive" datatypes in section 5.11 is not complete.
Disposition: Accepted (editorial)
Definitions for <time> and <frequency> have been added.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
Composite properties: it is not clearly stated what a specification of only one component of an inherited property means.
Disposition: Accepted (clarification)
Links to the changed text in the XSL recommendation:
See link to changed text.
The name of the "icc color" function is the same in SVG and XSL, but the arguments are different. This appears undesirable.
Disposition: Accepted (clarification)
The xsl "icc-color" function has been renamed "rgb-icc".
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
Demanding the implementation of all three linestacking strategies for basic conformance is too onerous and prevents the use of many existing formaters with XSL.
Disposition: Accepted (bug in spec)
The basic conformance requirement has been relaxed.
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
The semantics of omitting the, optional, NCName, in from-nearest-specified-value, from-table-column, merge-property-values functions is not defined. Also in the inherited-property-value, and from-parent functions should have the NCName optional for consistency.
Disposition: Accepted (bug in spec)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
Tables: for collapsing borders it is not specified where the border is placed on a pixel device in the case of a border thickness of an uneven number of pixels.
Disposition: Accepted (editorial)
Text to the effect that it is implmenentation defined has been added.
Links to the changed text in the XSL recommendation:
See link to changed text.
It shold be clarified that table cells may not overlap geometrically.
Disposition: Accepted (clarification)
Links to the changed text in the XSL recommendation:
See link to changed text.
Disposition: Accepted (editorial)
The text-altitude and text-depth labels are reversed in the figure showing "Nominal and Maximum Line Rectangles".
Links to the changed text in the XSL recommendation:
See link to changed text.
The specification of "side floats" need to be revised and be more precise.
Disposition: Accepted (bug in spec)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
Alignment baselines need some review and clarification.
Disposition: Accepted (clarification)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
In CSS2 spaced around "empty" blocks and inlines merge with the spaces before and after the "empty" area. XSL should do the same for compatibility. The text for merging spaces could be made clearer.
Disposition: Accepted (bug in spec)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
See link to changed text.
The text for the constraints on block-progression-dimension should be clarified and it should be made clear that block-areas are properly stacked, unless the FO description states otherwise.
Disposition: Accepted (editorial)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
The block-progression-dimension of the area generated by an fo:list-item should be clarified.
Disposition: Accepted (clarification)
Links to the changed text in the XSL recommendation:
See link to changed text.
There appears to be a typo in the error recovery for a "bounded-in-one-direction value; should it not be "(1) and (4)" and "(2) and (3)"?
Disposition: Accepted (editorial)
Yes.
Links to the changed text in the XSL recommendation:
See link to changed text.
The first and last line needs to be defined more rigorously for "last-line-end-indent", "text-aling-last", and "text-align".
Disposition: Accepted (clarification)
Links to the changed text in the XSL recommendation:
See link to changed text.
See link to changed text.
See link to changed text.
The description of "left" needs to refer to "overconstrained" geometry for certain non-"auto" values of properties.
Disposition: Accepted (clarification)
Links to the changed text in the XSL recommendation:
See link to changed text.
http://lists.w3.org/Archives/Public/xsl-editors/2001JulSep/0035.html
From: "Glenn Adams" <glenn@xfsi.com> To: <xsl-editors@w3.org> Date: Mon, 30 Jul 2001 12:49:55 -0400 Subject: RE: table-cell border precedence table-cell border precedenceI have pointed out these and other inconsistencies already. My primary concern at this point is that the XSL FO group has apparently punted on supporting the CSS2 semantics for collapsing borders which they normatively reference. In particular, the XSL FO group apparently believes that the border precedence can be computed on cells during XSLT processing. However, I have shown definitively that this is impossible to do when the border widths are based on relative units that can only be computed during the formatting process. I have urged that a simple solution be added to resolve this problem; namely, than an "auto" value be added for the border precedence properties which would have a meaning of "determine precedence base on CSS2 algorithm". So far, however, the XSL FO group seems to have ignored my suggestion.
Discussion Message
From: Bert Bos <bert@w3.org> Subject: RE: table-cell border precedence It seems Glenn has a point: you cannot always get the same rendering from XSL-FO tables as from CSS2 tables. The expression language in XSL-FO isn't powerful enough to express the precedence rules of CSS2. I'm trying to understand in what situation CSS2 behaviour cannot be simulated with explicit precedences in XSL-FO. One such situation appears to be as follows (in HTML + CSS): <table> <tr style="border: 2px solid"> <td style="border: 0.1em solid"> ... The effect is that there will be a border of 2px, unless the cell has a font that is bigger than 20px. In XSL, that would be something like: <fo:table...> <fo:table-row border="2px solid"> <fo:table-cell border="0.1em solid" border-precedence="XXX"> ... Where the XXX is an expression that yields a large number when 0.1em is greater than 2px and a small number otherwise. Unfortunately, this doesn't work: * <choose> <when test="0.1em > 2px">1000</when> <otherwise>-1000</otherwise> </choose> since XSLT doesn't know about lengths. The expressions in XSL-FO itself don't seem to allow comparisons, and they don't have conversions from lengths to numbers either. * 0.1em > 2px ? 1000 : -1000 So it seems that an expression will not work. The question then is, whether the designer himself always knows the font size and can choose the right precedence. In many cases he probably knows, but not if he imports a style sheet from elsewhere, or writes a reusable library of style sheet fragments. Glenn's suggestion of allowing border-precedence="auto" has some problems, too. What happens if some border-precedence attributes are "auto" and some others are not? Maybe it is easier to add a value "collapse-explicit-precedence" to border-collapse: collapse | separate | collapse-explicit-precedence | inherit in which case "collapse" would mean the same as in CSS2, and "collapse-explicit-precedence" would use the border-precedence attributes. Bert
Discussion Message
From: Steve Zilles <szilles@adobe.com> Subject: PLEASE READ: Border-collapse property (again) Bert Bos has just responded to an email of Glenn Adams where Bert notes that Glenn's proposed "auto" value will not work. Separately, Murakami-san has also raised some concerns about the lack of direct support for the CSS2 border conflict resolution rule. Bert makes what seems to me (and to Sharon Adler) to be a constructive way around this problem. We agreed that we need precedence values to be able to match table border models other than that of CSS. But, we need the CSS implicit rules also because there is no way to match, exactly, the CSS rules using just precedence. Therefore, Bert suggests having an additional value for the "border-collapse" property. This suggests the following value syntax (a slight modification of Bert's proposal): collapse | separate | collapse-with-precedence | inherit With this syntax, "collapse" and "separate" would have the meaning they currently have in CSS and "collapse-with-precedence" would have the meaning that was added in XSL. Note that in CSS the values "collapse" and "separate" just mean use the collapsing borders model or use the separate borders model, respectively. There are separate sections of the CSS document that define these models. In XSL, currently, there is no separate section that defines the models, instead, the description of the fo:table-cell FO has the semantics for these values. In XSL, the semantics of "separate" is the same as for CSS. The XSL semantics for the "collapse" value (the XSL borders model) is different from CSS. What the above proposal does is (a) associate the semantics of the XSL borders model with the value "collapse-with-precedence" and (b) requires adding the semantics of the CSS collapsing borders model, associated with the "collapse" value, to the fo:table-cell FO description. In more concrete terms, it would be necessary (a) modify the text of the XSL PR that is currently associated the "collapse" value to instead be associated with the "collapse-with-precedence" value and (b) to add text for the "collapse" value. These modifications would be to the FO's (some table related FO's) to which the "border-collapse" property applies. For all but fo:table-cell, the current text is of the form: [7.7 Common Border, Padding, and Background Properties] NOTE: Only the background properties from this set apply. If the value of border-collapse is "collapse" for the table the border properties also apply. which should become [7.7 Common Border, Padding, and Background Properties] NOTE: If the value of border-collapse is "collapse", all the properties apply. If the value of border-collapse is "separate" or "collapse-with-precedence, only the background properties from this set apply. If the value of border-collapse is "collapse-with-precedence" for the table the border properties also apply. For fo:table and fo:table-cell, the current text is of the form: Trait Derivation: [...] If the value of the border-collapse trait is "collapse" the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the highest precedence. It is an error if there are two such borders that have the same precedence but are not identical. Each border segment is placed centered on the table grid boundary line. On devices that do not support sub-pixel rendering, if an effective border width is determined to be an odd number of pixels it is implementation defined on which side of the grid boundry line the odd pixel is placed. Constraints: A table-cell occupies one or more grid units in the row-progression-direction and column-progression-direction. The content-rectangle of the cell is the size of the portion of the grid the cell occupies minus, for each of the four sides: · If the value of the border-collapse trait is "separate": half the value of the border-separation trait; otherwise 0. · If the value of the border-collapse trait is "separate": the thickness of the cell-border; otherwise half the thickness of the effective border. This becomes: Trait Derivation: [...] If the value of the border-collapse trait is "collapse-with-precedence" the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the highest precedence. It is an error if there are two such borders that have the same precedence but are not identical. Each border segment is placed centered on the table grid boundary line. On devices that do not support sub-pixel rendering, if an effective border width is determined to be an odd number of pixels it is implementation defined on which side of the grid boundary line the odd pixel is placed. If the value of the border-collapse trait is "collapse", the border for each side of the cell is determined by, for each segment of a border, selecting, from all border specifications for that segment, the border that has the most "eye catching" border style, see below for the details. Each border segment is placed centered on the table grid boundary line. On devices that do not support sub-pixel rendering, if an effective border width is determined to be an odd number of pixels it is implementation defined on which side of the grid boundary line the odd pixel is placed. Where there is a conflict between the styles of border segments that collapse, the following rules determine which border style "wins": 1. Borders with the 'border-style' of 'hidden' take precedence over all other conflicting borders. Any border with this value suppresses all borders at this location. 2. Borders with a style of 'none' have the lowest priority. Only if the border properties of all the elements meeting at this edge are 'none' will the border be omitted (but note that 'none' is the default value for the border style.) 3. If none of the styles is 'hidden' and at least one of them is not 'none', then narrow borders are discarded in favor of wider ones. 4. If the remaining border styles have the same 'border-width' than styles are preferred in this order: 'double', 'solid', 'dashed', 'dotted', 'ridge', 'outset', 'groove', and the lowest: 'inset'. 5. If border styles differ only in color, then a style set on a cell wins over one on a row, which wins over a row group, column, column group and, lastly, table. (Note that no change is needed to the following section because the exceptional case is the "separate" case and the two forms of "collapsing" have identical constraints; just different precedence rules.) Constraints: A table-cell occupies one or more grid units in the row-progression-direction and column-progression-direction. The content-rectangle of the cell is the size of the portion of the grid the cell occupies minus, for each of the four sides: · If the value of the border-collapse trait is "separate": half the value of the border-separation trait; otherwise 0. · If the value of the border-collapse trait is "separate": the thickness of the cell-border; otherwise half the thickness of the effective border.
Discussion Message
From: "Glenn Adams" <glenn@xfsi.com> Date: Fri, 17 Aug 2001 20:35:13 -0400 MSubject: RE: PLEASE READ: Border-collapse property (again) If the suggested change is made, then I withdraw my minority position objection. I agree that Bert's proposal addresses my concerns; however, I would also note that it would be possible to use the "auto" value for precedence without introducing a new value for "border-collapse" if prioritiy rules were established to distinguish between the precedence of "auto" and explicit numeric precedences. Nevertheless, I think Bert's proposal is preferable as the mixture of these two precedence models is not well established in practice whereas the two distinct models (collapse and collapse-with-precedence) are better established in practice in isolation.
Disposition: Accepted (bug in spec)
Link to the changed text in the XSL recommendation:
See link to changed text.
Item 1: Accepted (editorial)
Item 1: Accepted (bug in spec)
Item 1: Explanation of XSL spec
Item 2: Explanation of XSL spec
Item 3: Explanation of XSL spec
Item 1: Accepted (clarification)
Item 1: Accepted (editorial)
Item 2: Accepted (editorial)
Item 1: Accepted (editorial)
Item 2: Accepted (editorial)
Item 1: Accepted (editorial)
Item 1: Accepted (clarification)
Item 2: Accepted (editorial)
Item 1: Explanation of why no change will be made
Item 1: Accepted (editorial)
Item 2: Accepted (editorial)
Item 1: Accepted (clarification)
Item 1: Explanation of why no change will be made
Item 1: Explanation of why no change will be made
Item 1: Accepted (clarification)
Item 1: Future XSL version
Item 1: Accepted (clarification)
Item 1: Explanation of XSL spec
Item 1: Explanation of XSL spec
Item 2: Accepted (bug in spec)
Item 1: Explanation of XSL spec
Item 1: Accepted (bug in spec)
Item 2: Explanation of XSL spec
Item 3: Explanation of why no change will be made
Item 4: Explanation of why no change will be made
Item 1: Accepted (editorial)
Item 1: Accepted (editorial)
Item 2: Accepted (editorial)
Item 1: Accepted (editorial)
Item 1: Explanation of why no change will be made
Item 1: Accepted (editorial)
Item 1: Accepted (editorial)
Item 1: Accepted (clarification)
Item 1: Explanation of why no change will be made
Item 1: Explanation of XSL spec
Item 1: Accepted (bug in spec)
Item 1: Accepted (clarification)
Item 1: Explanation of why no change will be made
Item 1: Accepted (editorial)
Item 2: Accepted (editorial)
Item 3: Explanation of why no change will be made
Item 4: Accepted (editorial)
Item 5: Accepted (editorial)
Item 6: Explanation of why no change will be made
Item 7: Accepted (editorial)
Item 8: Explanation of why no change will be made
Item 9: Explanation of why no change will be made
Item 10: Accepted (editorial)
Item 11: Accepted (editorial)
Item 12: Explanation of why no change will be made
Item 13: Accepted (editorial)
Item 14: Accepted (editorial)
Item 15: Accepted (editorial)
Item 16: Explanation of why no change will be made
Item 17: Accepted (editorial)
Item 18: Accepted (editorial)
Item 19: Accepted (editorial)
Item 20: Accepted (editorial)
Item 21: Accepted (editorial)
Item 22: Accepted (editorial)
Item 23: Accepted (editorial)
Item 24: Accepted (editorial)
Item 25: Accepted (editorial)
Item 26: Accepted (editorial)
Item 27: Accepted (editorial)
Item 28: Accepted (editorial)
Item 29: Accepted (editorial)
Item 30: Accepted (editorial)
Item 31: Accepted (editorial)
Item 32: Accepted (editorial)
Item 33: Accepted (editorial)
Item 34: Accepted (editorial)
Item 35: Accepted (editorial)
Item 36: Accepted (editorial)
Item 37: Accepted (editorial)
Item 38: Accepted (editorial)
Item 39: Accepted (editorial)
Item 40: Accepted (editorial)
Item 41: Accepted (editorial)
Item 42: Accepted (editorial)
Item 43: Accepted (editorial)
Item 44: Accepted (editorial)
Item 45: Accepted (editorial)
Item 46: Accepted (editorial)
Item 47: Accepted (editorial)
Item 48: Accepted (editorial)
Item 49: Accepted (editorial)
Item 50: Accepted (editorial)
Item 51: Accepted (editorial)
Item 52: Accepted (editorial)
Item 53: Accepted (editorial)
Item 54: Accepted (editorial)
Item 55: Accepted (editorial)
Item 56: Accepted (editorial)
Item 57: Accepted (editorial)
Item 58: Accepted (editorial)
Item 59: Accepted (editorial)
Item 60: Accepted (editorial)
Item 61: Accepted (editorial)
Item 62: Accepted (editorial)
Item 63: Accepted (editorial)
Item 64: Accepted (editorial)
Item 65: Accepted (editorial)
Item 66: Explanation of why no change will be made
Item 67: Accepted (editorial)
Item 68: Accepted (editorial)
Item 69: Accepted (editorial)
Item 70: Accepted (editorial)
Item 71: Accepted (editorial)
Item 72: Accepted (editorial)
Item 73: Accepted (editorial)
Item 74: Accepted (editorial)
Item 75: Accepted (editorial)
Item 1: Accepted (editorial)
Item 1: Accepted (editorial)
Item 2: Explanation of XSL spec
Item 3: Accepted (editorial)
Item 1: Accepted (editorial)
Item 2: Accepted (editorial)
Item 1: Accepted (editorial)
Item 1: Accepted (editorial)
Item 2: Accepted (clarification)
Item 3: Accepted (clarification)
Item 4: Accepted (bug in spec)
Item 5: Accepted (bug in spec)
Item 6: Accepted (editorial)
Item 7: Accepted (clarification)
Item 8: Accepted (editorial)
Item 9: Accepted (bug in spec)
Item 10: Accepted (clarification)
Item 11: Accepted (bug in spec)
Item 12: Accepted (editorial)
Item 13: Accepted (clarification)
Item 14: Accepted (editorial)
Item 15: Accepted (clarification)
Item 16: Accepted (clarification)
Accepted (bug in spec)