Re: inline stacking and baseline scaling
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:blockSome text fo:inline font-size=.5em dominant-baseline=reset-size alignment-baseline=text-before-edgetop /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:blockSome text fo:inline font-size=.5em dominant-baseline=reset-size alignment-baseline=text-before-edgetop 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:inlineApguru 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
Re: inline stacking and baseline scaling
On Mon, 26 Sep 2005 06:19 pm, Peter B. West wrote: Manuel Mall wrote: snip/ Peter, thanks for your feedback. I have deleted most of my original post to keep this to a reasonable size. Further comments inline. Just repeating my example here: fo:blockSome text fo:inline font-size=.5em dominant-baseline=reset-size alignment-baseline=text-before-edgetop fo:inline font-size=.5em alignment-baseline=central tiny/fo:inline /fo:inline /fo:block 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. Yes, agreed. 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. I agree that neither of these properties inherit but they all have default values. However, the baseline table does propagate as you said and may or may not be rescaled depending on the alignment properties explicitly set. If none are set the baseline table stays unchanged. 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. This is were my interpretation differs from yours. IMO for the innermost inline (tiny) the baseline table that applies is the one established by the rescaling of the table by its parent inline (top). Therefore tiny should be aligned to the central baseline of the rescaled table. For the inline tiny the following alignment property values apply: alignment-adjust=auto = computed value is central alignment-baseline=central = computed value is central baseline-shift=baseline = computed value is 0 dominant-baseline=auto The most interesting bit is the auto setting for the dominant-baseline as it says in the spec for that case: if this property is not on a block-level formatting object, then the baseline-identifier for the dominant baseline, the derived baseline-table, and baseline-table font-size remain the same as those of the parent formatting object. As the parent formatting object is the inline top I interpret this as: tiny's baseline table is the same as top's (which is the rescaled baseline table from the fo:block). tiny's baseline table is not being rescaled to tiny's font-size. The dominant-baseline-identifier still stays alphabetic. FWIW (not that much I agree) both AntennaHouse and RenderX behave as I outlined. The scaled-font-table remains the same as for top; only the size of the glyphs changes. Not sure I understand what a scaled-font-table is but as said above IMO the scaled-baseline-table on tiny is the same as on top. See the third example: fo:inlineApguru fo:inline font-size='.75em' Exji /fo:inline /fo:inline Yes, not disputed. So rule 3 holds. There have been no baseline-shifts (rescaling the font-table doesn't count as a baseline-shift.) Yes, in your interpretation, not in mine. Maybe. Still seriously confused Surely not. :-) Peter Manuel
Re: inline stacking and baseline scaling
Manuel Mall wrote: On Mon, 26 Sep 2005 06:19 pm, Peter B. West wrote: Manuel Mall wrote: snip/ Peter, thanks for your feedback. I have deleted most of my original post to keep this to a reasonable size. Further comments inline. Just repeating my example here: fo:blockSome text fo:inline font-size=.5em dominant-baseline=reset-size alignment-baseline=text-before-edgetop fo:inline font-size=.5em alignment-baseline=central tiny/fo:inline /fo:inline /fo:block 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. Yes, agreed. 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. I agree that neither of these properties inherit but they all have default values. However, the baseline table does propagate as you said and may or may not be rescaled depending on the alignment properties explicitly set. If none are set the baseline table stays unchanged. 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. This is were my interpretation differs from yours. IMO for the innermost inline (tiny) the baseline table that applies is the one established by the rescaling of the table by its parent inline (top). Therefore tiny should be aligned to the central baseline of the rescaled table. For the inline tiny the following alignment property values apply: alignment-adjust=auto = computed value is central alignment-baseline=central = computed value is central baseline-shift=baseline = computed value is 0 dominant-baseline=auto The most interesting bit is the auto setting for the dominant-baseline as it says in the spec for that case: if this property is not on a block-level formatting object, then the baseline-identifier for the dominant baseline, the derived baseline-table, and baseline-table font-size remain the same as those of the parent formatting object. As the parent formatting object is the inline top I interpret this as: tiny's baseline table is the same as top's (which is the rescaled baseline table from the fo:block). tiny's baseline table is not being rescaled to tiny's font-size. The dominant-baseline-identifier still stays alphabetic. FWIW (not that much I agree) both AntennaHouse and RenderX behave as I outlined. The scaled-font-table remains the same as for top; only the size of the glyphs changes. Not sure I understand what a scaled-font-table is but as said above IMO the scaled-baseline-table on tiny is the same as on top. See the third example: fo:inlineApguru fo:inline font-size='.75em' Exji /fo:inline /fo:inline Yes, not disputed. So rule 3 holds. There have been no baseline-shifts (rescaling the font-table doesn't count as a baseline-shift.) Yes, in your interpretation, not in mine. I'm looking for an interpretation that is consistent with Rule 3. This is a murky area of the Rec, and one I have never understood. Why not send your original query to the editors, so that they can consider whether anything needs to be clarified before 1.1? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
