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


Reply via email to