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