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

Reply via email to