I read it like this: The areas generated by inlines are always children
of line areas. Since only line areas can define the before-edge and
after edge baselines, areas generated by inlines have to retrieve these
two baselines from their parent line area. I believe this is some kind
of implied inheritance. Disclaimer: I haven't studied the whole topic!
On 28.09.2005 06:11:40 Manuel Mall wrote:
> This is another of those spec interpretation questions. Sorry to
> populate this list with so many of these questions but this is a source
> of real irritation for me in the moment. I just want to get
> sub/superscripts working and do it properly and I am hitting all these
> "murky" (as Peter put it) things in the spec.
> Here we go again. In 7.13 the spec defines the various baselines. In
> that section it says: "There are, in addition, two computed baselines
> that are only defined for line areas." and then goes on about those two
> baselines being "before-edge" and "after-edge".
> We then come to 7.13.1 alignment-adjust and "before-edge" and
> "after-edge" are valid values. However, the alignment-adjust property
> applies only to inline fo's. And inline fo's don't generate line areas.
> As the alignment-adjust property applies to the area generated by the
> fo (not like the alignment-baseline property which applies to the
> parent area) none of the areas generated by the fo's in question will
> have those baselines defined. The text also implies that i-f-o and and
> e-g have the "after-edge" as their dominant baseline. For the "auto"
> setting we are allowed to use heuristics to determine where the
> baseline is but that option is not open to the other values. So, what's
> the point of having "before-edge", "after-edge" as allowed values if
> those baselines are guaranteed not to be defined (and even use them as
> default for e-g and i-f-o)?