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

Reply via email to