inline stacking and baseline scaling

[Manuel Mall <mm...@arcus.com.au>]

My apologies for this relatively long post. I am still struggling to
come to grips with some of the fundamentals of line building. And
without having a clear picture of that it is impossible to come up with
a decent design. Interestingly (?) all my conceptual problems occur when
one starts to nest inlines (for example simple math formulas) and shift
baselines around.

Any way the spec in 4.6.1 defines what a 'properly stacked' inline-area
is. Items 1. and 2. deal with stacking in IPD but item 3 repeated here
deals with 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-befored-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

Cheers

Manuel

Re: inline stacking and baseline scaling

["Peter B. West" <li...@pbw.id.au>]

Manuel Mall wrote:
> My apologies for this relatively long post. I am still struggling to
> come to grips with some of the fundamentals of line building. And
> without having a clear picture of that it is impossible to come up with
> a decent design. Interestingly (?) all my conceptual problems occur when
> one starts to nest inlines (for example simple math formulas) and shift
> baselines around.
> 
> Any way the spec in 4.6.1 defines what a 'properly stacked' inline-area
> is. Items 1. and 2. deal with stacking in IPD but item 3 repeated here
> deals with 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-befored-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.

I can't say for sure, but I think there may be some confusion about the 
relationship between the alignment-baseline of nested inline-areas and 
the dominant-baseline of the containing line-area.  The 
nominal-requested-line-rectangle is implicitly defined with respect to 
the dominant-baseline, text-depth and text-altitude on the parent of the 
line-area.

The situation with inheritance of properties involved with these 
calculation is also confused.  They do no inherit, except that, for 
dominant-baseline, components of the scaled-baseline-table "propagate" 
for formatting object children with the default initial value of "auto" 
for dominant-baseline.  Apart from that, neither alignment-baseline nor 
dominant-baseline inherit, so they must revert to relativity to, I 
think, the values holding for the line-area, whenever a new inline 
formatting object, including nested objects, is encountered.

In the example you have used, the alignment-baseline of "central" on 
"tiny" simply moves the central line of "tiny" into correspondence with 
the central line of "Some text".  The scaled-font-table remains the same 
as for "top"; only the size of the glyphs changes. See the third example:

<fo:inline>Apguru
   <fo:inline font-size='.75em'>
     Exji
   </fo:inline>
</fo:inline>

So rule 3 holds.  There have been no baseline-shifts (rescaling the 
font-table doesn't count as a baseline-shift.)

Maybe.

> 
> Still seriously confused

Surely not.

Peter
-- 
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>