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/>
smime.p7s
Description: S/MIME Cryptographic Signature
