RE: nested inlines and baseline scaling

You correct that there is a problem in the draft.

The text as written now works only in the case where 
the font sizes are all the same, and in that case the 
ancestor/descendant constraints are superfluous.

To correct the draft, we will change the first paragraph 
to read:

3. For any inline-area descendant I of P, the distance in
   the shift-direction from the dominant baseline of the
   parent Q of I, to the alignment-point of I equals the
   offset between the dominant baseline of Q and the baseline
   of Q corresponding to the alignment-baseline trait of I,
   plus the baseline-shift for I.

This removes the superfluous constraints and precisely
captures our examples.
 
Paul Grosso
for the XSL FO SG

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Manuel Mall
> Sent: Tuesday, 2005 September 27 10:03
> To: [email protected]
> 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
> 
>