W3C home > Mailing lists > Public > xsl-editors@w3.org > July to September 2005

nested inlines and baseline scaling

From: Manuel Mall <mm@arcus.com.au>
Date: Tue, 27 Sep 2005 23:03:12 +0800
To: xsl-editors@w3.org
Message-Id: <200509272303.12380.mm@arcus.com.au>

My apologies for this relatively long post. I am struggling to
come to terms with some of the fundamentals of line building.

The spec in 4.6.1 defines what a 'properly stacked' inline-area
is. Items 1. and 2. deal with stacking in IPD and item 3 repeated here
deals with stacking in the BPD:

"3. For any inline-area descendant I of P, the distance in the shift-
direction from the dominant baseline of P to the alignment-point of I
equals the offset between the dominant baseline of P and the baseline of
P corresponding to the alignment-baseline trait of I, plus the sum of
the baseline-shifts for I and all of its ancestors which are descendants
of P.

The first summand is computed to compensate for mixed writing systems
with different baseline types, and the other summands involve deliberate
baseline shifts for things like superscripts and subscripts."

In 7.13 there are examples given and they all work with the above

Now lets take this example:

<fo:block>Some text
  <fo:inline font-size=".5em"

The inline gets a new baseline table scaled to its font-size because of
the dominant-baseline="reset-size" setting. Note that the
dominant-baseline-indentifier has not changed. Its still "alphabetic"
although that baseline does not align any more between the two areas
because of the rescaling of the baseline table. Now lets give the text
"top" a small suffix.

<fo:block>Some text
  <fo:inline font-size=".5em"
    <fo:inline font-size=".5em" alignment-baseline="central">

So "tiny" becomes some small text aligned on the central baseline as
established after rescaling. The problem is that the positioning of
"tiny" violates the rule 3. above on proper stacking with respect to the
line-area created by the fo:block. It is OK with respect to its direct
ancestor but it fails when applied recursively. This is because rule 3.
doesn't cater at all for rescaling of the baseline table, it only deals
with changing the alignment point (In my example its first moved to
"text-before-edge" and then to "central") and baseline-shifts. But I
couldn't find anywhere in the spec a notion that baseline rescaling
involves a baseline shift. The problem of course is that when a baseline
table is rescaled there is no uniform shift and the shift amount per
baseline also depends on the alignment.

May be rule 3 is not meant to be applied recursively but than it its 
formulated inconsistently with the rest of the spec.

Still seriously confused


Manuel Mall
Received on Wednesday, 28 September 2005 01:06:48 UTC

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