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)? > > Manuel Jeremias Maerki
