Hi Manuel, Manuel Mall a écrit : > 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.
Interesting. I'll try to comment on this later. Just a quick note for the moment... >> 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.... ... IIUC that's the purpose of the line-stacking-strategy. I've never had enough energy to try and grasp every detail of this part of the spec, but I'd say that in the case of "font-height" the line height would depend on the font's em box and thus larger characters would protrude, and in the case of "max-height" they would not. WDYT? Vincent
