RE: nested inlines and baseline scaling

After much discussion, the XSL FO SG agrees that the
wording in the area should be improved, but it will
take some time to have a detailed resolution.

Since this wording comes from XSL 1.0, we plan to
process it as an erratum to 1.0 and fold it into
1.1 when it is ready.  Given that this is a 1.0
erratum and not a new 1.1 issue, We do not plan 
to hold up the XSL 1.1 CR for this issue.  We do
expect to be able to fold in the resolution of this
erratum before 1.1 becomes a Rec.

paul

Paul Grosso for the XSL FO SG

> -----Original Message-----
> From: xsl-editors-request@w3.org 
> [mailto:xsl-editors-request@w3.org] On Behalf Of Manuel Mall
> Sent: Tuesday, 2005 September 27 10:03
> To: xsl-editors@w3.org
> Subject: nested inlines and baseline scaling
> 
> 
> 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
> definition.
> 
> Now lets take this example:
> 
> <fo:block>Some text
>   <fo:inline font-size=".5em"
>         dominant-baseline="reset-size"
>         alignment-baseline="text-before-edge">top
>   </fo:inline>
> </fo:block>
> 
> 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"
>         dominant-baseline="reset-size"
>         alignment-baseline="text-before-edge">top
>     <fo:inline font-size=".5em" alignment-baseline="central">
>     tiny</fo:inline>
>   </fo:inline>
> </fo:block>
> 
> 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
> 
> Regards
> 
> Manuel Mall
> 
>

Received on Tuesday, 13 December 2005 21:40:54 UTC