W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2000

Questions/comments on 7.11 Area Alignment Properties

From: Jon Ferraiolo <jferraio@Adobe.COM>
Date: Tue, 28 Mar 2000 16:56:51 -0800
Message-Id: <200003290053.QAA18459@mail-345.corp.Adobe.COM>
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
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

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'.


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

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'.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:17 UTC