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: xsl-editors-requestw3.org 
> [mailtosl-ed
itors-requestw3.org] On Behalf Of Manuel Mall
> Sent: Tuesday, 2005 September 27 10:03
> To: xsl-editorsw3.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
> 
>