I'm not a specialist on typography, yet, but the character wrapping (your option a) sounds definitely like a hack. I've started reading the parts in the spec about baselines and that's not a casual read. But I think that at one point we need to handle baselines and all these little details. I'm not a big help here but I think it would be worth reading through the following sections in the spec: 4.2.6, 7.8.1, 7.13. Somewhere in there all the necessary traits and their handling should be hidden. They should at least get you some hints how to handle the problem at hand.
On 16.09.2005 15:50:50 Manuel Mall wrote: > Still waiting for some feedback here from others. I am reluctant to > change the interface to the renderers without other committers agreeing > because such a change affects every renderer out there. On the other > hand it feels a bit like a kludge to treat/represent <fo:character ... > character="x" /> as <fo:inline ...>x</fo:inline>. There are also some > subtleties in the handling of some properties which are interpreted > differently when specified on a fo:character to a fo:inline. > > Manuel > > On Fri, 16 Sep 2005 03:31 pm, Manuel Mall wrote: > > On Fri, 16 Sep 2005 02:58 pm, Finn Bock wrote: > > > [Manuel] > > > > > > > I am currently looking at adding the missing background and > > > > border/padding support to fo:character and have run into a > > > > co-ordinate system issue. In fop text areas and character areas > > > > are positioned in the bpd direction using the "offset" attribute > > > > which refers to the character baseline position. However, > > > > border/padding and backgrounds are positioned everywhere relative > > > > to the top left (or should I say before/start) corner of the area > > > > rectangle. However, in the renderer based on the area traits (for > > > > a text or character area) I cannot easily determine the before > > > > edge position of the rectangle based on the baseline offset > > > > unless I go to the font and ask for its ascender size etc.. But > > > > that is really stuff for the layout system. > > > > > > > > I see two options: > > > > > > > > a) We can wrap the character area into an inlineParent area and > > > > put the background/border/padding for the character on the > > > > inlineParent. b) We add another attribute to the generic fop area > > > > being the baseline offset called "lead". The meaning of the > > > > attributes is then that "offset" refers to the distance between > > > > the before edge of the parent area to the before edge of the area > > > > to be rendered and "lead" is the distance from the before edge to > > > > the baseline for character placement. > > > > > > Perhaps I misunderstand, but I think it would be better if we > > > defined an dominant-baseline on the inlines (or even better > > > dominant-baseline-identifier on inline and actual-baseline-table on > > > the fonts) and a baseline-start-point on the linearea. The > > > semantics of these traits are as described in [4.2.6] and [4.5]. > > > > Finn, you understood me correctly and your suggestions to align our > > naming with the spec make sense. > > > > However, the fop area tree is really an interface to the fop > > renderers and not an exact implementation of the XSl-FO area tree. > > For example at the moment it seems layout is assumed to take care of > > all the baseline calculations and the renderers are only told the > > position of THE baseline for the glyphs of the font they are suppose > > to render. There seems to be no need for the renderers to be aware of > > different baselines, baseline tables, etc. as layout resolved all > > that into a single vertical (I am still thinking in terms of lr-tb > > scripts) position for each sequence of characters to be rendered. > > > > So we may have to introduce the concepts you suggest like > > actual-baseline-table, dominant-baseline, ... to the fop Layout > > Managers so they can do their job properly with respect to all this > > baseline stuff but I am not so sure we need it in the area tree (= > > interface to the renderers). > > > > > Together with bpd, I think that would be enough to find the rest of > > > the different rectangles. > > > > > > I guess it is the same as your suggestion b), but I would rather > > > stick with the terms used in the spec. > > > > > > regards, > > > finn > > > > Cheers > > Manuel Jeremias Maerki
