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: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>

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:inline>Apguru
  <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/>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to