- From: Jon Ferraiolo <jferraio@Adobe.COM>
- Date: Tue, 28 Mar 2000 16:56:51 -0800
- To: xsl-editors@w3.org, w3c-svg-wg@w3.org
XSL Editors and SVG Working Group, The following comments are a set of initial questions and comments about section 7.11 of the XSL March 27 draft specification (http://www.w3.org/TR/2000/WD-xsl-20000327/slice7.html#section-N29442-Area-A lignment-Properties). This email stems from an initial review of this section of the XSL spec and comparison with the corresponding section of SVG's March 3 draft spec (http://www.w3.org/TR/2000/03/WD-SVG-20000303/text.html#BaselineAlignmentPro perties). This email does NOT represent formal last call feedback from the SVG working group, although it is possible that some of the topics expressed in this email might be addressed in future formal correspondence. ISSUE/QUESTION WITH 'baseline-shift': 1) Based on discussions with Zilles in the past and looking at earlier drafts of his paper on "Subdividing and Internationalizing Vertical Align" and the description of the 'dominant-baseline' property when set to 'auto', it appears that the intent of 'baseline-shift' is that not only would the baseline tables get offset (a translation operation), but that the baseline tables would be resized (a scaling operation) based on the current font size. QUESTION: Is it true that 'baseline-shift' can cause both a shift and a resizing of the baseline tables? RECOMMENDED ACTION: If the answer is 'yes', then both the XSL spec and the SVG spec need to be clear in the write-up of 'baseline-shift' that the baseline tables might get resized. 2) The XSL spec says that a 'baseline-shift' of '0cm' or '0%' is equivalent to 'baseline'. That means that a 'baseline-shift' of '.001cm' might produce wildly different results than a 'baseline-shift' of '.000cm', since one might recompute the baseline table with a modified 'font-size' and the other will not. This is a bad discontinuity. SVG is especially sensitive to discontinuities because all properties are animatable. RECOMMENDED ACTION: Change the definition of 'baseline-shift' in the XSL and SVG specs to say that the baseline tables might be recomputed whenever baseline-shift has a value other than 'baseline'. VARIOUS ISSUES WITH INITIAL VALUE FOR 'baseline-identifier': 3) The XSL spec clearly states what the semantics should be for 'baseline-identifier' when you have to resort to the initial value, but there is no keyword for this behavior. With most (all?) other properties, there is a keyword that corresponds to each set of behaviors. RECOMMENDED ACTION: It seems to me that there should be a keyword 'auto' for 'baseline-identifier' whose behavior consists of the dominant baseline of the script to which character belongs, or parent's dominant baseline, if there is no such script, and that the initial value should be 'auto'. 4) The SVG spec has confusing language about the initial value for 'baseline-identifier'. The introductory description to section 10.7.2 conveys the correct concept, but the property description is some combination of confusing and incorrect. RECOMMENDED ACTION: Fix the wording in the SVG spec to match the XSL spec. SVG QUESTION ABOUT 'baseline-identifier' 5) 'baseline-identifier' has options 'before-edge', 'text-before-edge', 'after-edge' and 'text-after-edge'. The descriptions for these options refer to various box model concepts which don't apply to SVG, which only does single-line text. QUESTION: For SVG, I believe that 'before-edge' and 'text-before-edge' would be equivalent to 'hanging' (topmost baseline), whereas 'after-edge' and 'text-after-edge' would be equivalent to 'ideographic' (bottommost baseline). Is this correct? RECOMMENDED ACTION: If the answer is 'yes', then change the SVG spec to say that 'before-edge' and 'text-before-edge' is equivalent to 'hanging' and that 'after-edge' and 'text-after-edge' is equivalent to 'ideographic'. DISCREPANCIES BETWEEN XSL AND SVG THAT APPEAR TO REQUIRE CHANGES TO THE SVG SPEC: 6) 'baseline-identifier' in SVG has values 'top', 'text-top', 'bottom' and 'text-bottom' which are not part of the XSL spec. RECOMMENDED ACTION: Remove these options from the SVG spec. 7) 'baseline-identifier' and 'dominant-baseline' in the SVG spec has option 'lower', but the XSL spec has option 'alphabetic'. RECOMMENDED ACTION: Change the SVG spec to say 'alphabetic' 8) The XSL spec clearly indicates that the 'dominant-baseline' applies to all text elements, and that the dominant baseline table gets resized with each 'baseline-shift' when dominant-baseline='auto'. RECOMMENDED ACTION: Change the SVG spec to say that 'dominant-baseline' applies to ALL text elements, not just 'text'. Thus, you can change the 'dominant-baseline' on a 'tspan', for example. Also, the SVG spec needs to be changed to say that the baseline table changes size with each 'baseline-shift' when dominant-baseline='auto'. With this change, then 'auto', 'autosense-script' and 'no-change' become differentiated and meaningful with SVG. Jon Ferraiolo SVG Editor
Received on Tuesday, 28 March 2000 19:54:03 UTC