On Tuesday 13 March 2007 17:50, Vincent Hennebert wrote:
> [Moving to fop-dev as we're going to speak about implementation
> details]
> Andrejus Chaliapinas a écrit :
> > Hi Jeremias,
> >
> >> I've just checked since I was curious. It's already in 0.90. Seems
> >> to have to do with font metrics. Take a look at the Area Tree XML.
> >> The label has a BPD of 18936 while the body has 14400. Symbol has
> >> an ascender of 1010 while Helvetica has 718.
> >>
> >> Smells like a need for implementing relative-align="baseline" to
> >> me.
> >>
> >> Jeremias Maerki
> >
> > Would it be hard to fix? Should I try that myself (hmm, not so
> > easy) or someone else could take a look on that?
> In theory no; in practice...
> I'm not familiar with the inline part of the layout code, but as I've
> been having this idea in the head for some time, I thought I might
> use this opportunity to explain it. Inline specialists, please
> correct me if I'm wrong.
> AFAIK there is no information about the distance of the baseline from
> the before-edge of an area. A quick small picture:
> ------------------------   <-- before-edge of the area
> | First line of text.  |   <-- "base-line" of the area
> | Second line of text. |       (= baseline of the first line)
> ------------------------
> If we had that information for each area, then this would be easy to
> implement relative-align I think.

I believe that information is available. If you look at the area tree 
generated every text element has a baseline value which is the offset 
from the before edge.

> That would imply to change almost every LayoutManager to
> compute/transfer this information. Quite a bit of work.
Yes, but I think for slightly different reason. The logic (in the case 
of lists) to support relative-align would have to be in the ListItemLM. 
After doing the line breaking (getNextKnuth...) for both the item label 
and the item body the ListItemLM would need to get to the first line of 
both subordinates (via the first Knuth element of each of the lists 
returned?), compare their heights and baselines, signal adjustments 
down to the relevant InlineLevel LMs and adjust the already generated 
Knuth element for page breaking to the new line height. I guess a 
similar logic would need to apply to support relative-align for table 
cells, i.e. it would reside at row level.

> Andrejus, if you want to give it a try, you're welcome ;-) We would
> be glad to help you find your way in the code. But, granted, that's
> perhaps not the easiest way to get involved into FOP's development.
> What do others think?

What concerns me more ATM is the question if we actually deal with the 
font metrics, baselines, alignment correctly. The metrics of the Base14 
Symbol font have the Ascender/Descender actually exceeding the fonts EM 
box (Ascender + Descender > 1000). This causes the growth in line 
height for lines containing Symbol font inlines. Is this the right 
thing to do? Or should we cap the line height at the EM box height and 
larger characters just protrude. Not sure if the spec actually deals 
with that. Would need to dig into this again. Growl....

> Vincent


Reply via email to