Characters and area traits

[Manuel Mall <mm...@arcus.com.au>]

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.

Comments please?

Manuel

Re: Characters and area traits

[Manuel Mall <mm...@arcus.com.au>]

On Mon, 19 Sep 2005 04:23 pm, Jeremias Maerki wrote:
> On 18.09.2005 13:10:34 Manuel Mall wrote:
> > On Fri, 16 Sep 2005 11:41 pm, Jeremias Maerki wrote:
<snip/>
>
> > So, for the time being, I have now fop internally standardised the
> > meaning of the fop specific "offset" attribute in the fop area tree
> > as meaning the distance between the before edges of the parent area
> > and the area to be rendered. I have also introduced a new attribute
> > called "baselineOffset" which gives the point on the start-edge
> > (distance from the before-edge) for the actual alignment line for
> > all glyphs in that inline area, i.e. the alignment point in bpd for
> > all the glyphs in that area will be on that line.
>
> Sounds reasonable. Did you find anything in the spec what exactly the
> suggested set of trait is?
>
I believe the relevant sections of the spec are 4.2.6, 4.6 and 7.13 
which take quite a bit to digest.  However, in the end it seems to boil 
down to the spec suggesting to carry the actual-baseline-table, 
dominant-baseline-identifier, alignment-baseline, alignment-point and 
baseline-shift as traits and let the renderers do some of the placement 
calculations. May be "alignment-point" is the closest to what I have 
called baselineOffset.

<snip/>
> Jeremias Maerki

Manuel

Re: Characters and area traits

[Jeremias Maerki <de...@jeremias-maerki.ch>]

On 18.09.2005 13:10:34 Manuel Mall wrote:
> On Fri, 16 Sep 2005 11:41 pm, Jeremias Maerki wrote:
> > 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.
> 
> Jeremias, seems to me we are talking about two different things here.

I don't think so. I only tend to look at how to get a problem right for
good as opposed to a quick change to make things work. I see that this
was not fully appropriate here. Sorry for that.

> My 
> initial problem simply was that I needed more data in the area tree to 
> correctly draw border/padding/background for various inline fos 
> (leader, page-number, page-number-citation, character). The other, only 
> vaguely related matter, is the correct handling of all the area 
> alignment properties in layout. IMO it is only vaguely related, and 
> this may be contentious, because for rendering we only need to know 
> where to place the glyph, i.e. the x/y coordinates of its alignment 
> point. All the relative and baseline alignment stuff should have been 
> previously resolved by layout. If you go along with that argument it 
> would mean the fop area tree as exposed to the renderers will not carry 
> baseline tables or related data. Not sure if this causes an issue with 
> the plans to expose the area tree as an official external interface.

No, I don't think it would. As I said, I don't know too much about the
details involved here so I can't tell what the right approach would be.
People who would mess around with the area will need to know what
they're doing anyway. No problem if it might get a little complicated on
this level.

> So, for the time being, I have now fop internally standardised the 
> meaning of the fop specific "offset" attribute in the fop area tree as 
> meaning the distance between the before edges of the parent area and 
> the area to be rendered. I have also introduced a new attribute called 
> "baselineOffset" which gives the point on the start-edge (distance from 
> the before-edge) for the actual alignment line for all glyphs in that 
> inline area, i.e. the alignment point in bpd for all the glyphs in that 
> area will be on that line.

Sounds reasonable. Did you find anything in the spec what exactly the
suggested set of trait is?

> This seems to have worked well so far and introduced quite a bit of 
> consistency in the handling of offsets and basic vertical alignment for 
> all our inline areas. There is an assumption behind this that all 
> glyphs in an inline area have the same nominal alignment line. This is 
> certainly true in the moment and I am not aware of a font where 
> different glyphs have different nominal alignment lines (but there 
> probably is for fonts mixing Western and non Western glyphs). And even 
> if so, our font interface (nor FOray's i/f I assume) does not expose 
> this sort of detail. 
> 
> If the two attributes (offset and baselineOffset) are enough in the fop 
> area tree to cover vertical writing modes I am not sure about - this is 
> "for further study".
>
> Hope this makes sense

Sounds completely reasonable to me.
> 
> >
> > 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
> Cheers
> Manuel



Jeremias Maerki

Re: Characters and area traits

[Manuel Mall <mm...@arcus.com.au>]

On Fri, 16 Sep 2005 11:41 pm, Jeremias Maerki wrote:
> 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.

Jeremias, seems to me we are talking about two different things here. My 
initial problem simply was that I needed more data in the area tree to 
correctly draw border/padding/background for various inline fos 
(leader, page-number, page-number-citation, character). The other, only 
vaguely related matter, is the correct handling of all the area 
alignment properties in layout. IMO it is only vaguely related, and 
this may be contentious, because for rendering we only need to know 
where to place the glyph, i.e. the x/y coordinates of its alignment 
point. All the relative and baseline alignment stuff should have been 
previously resolved by layout. If you go along with that argument it 
would mean the fop area tree as exposed to the renderers will not carry 
baseline tables or related data. Not sure if this causes an issue with 
the plans to expose the area tree as an official external interface.

So, for the time being, I have now fop internally standardised the 
meaning of the fop specific "offset" attribute in the fop area tree as 
meaning the distance between the before edges of the parent area and 
the area to be rendered. I have also introduced a new attribute called 
"baselineOffset" which gives the point on the start-edge (distance from 
the before-edge) for the actual alignment line for all glyphs in that 
inline area, i.e. the alignment point in bpd for all the glyphs in that 
area will be on that line.

This seems to have worked well so far and introduced quite a bit of 
consistency in the handling of offsets and basic vertical alignment for 
all our inline areas. There is an assumption behind this that all 
glyphs in an inline area have the same nominal alignment line. This is 
certainly true in the moment and I am not aware of a font where 
different glyphs have different nominal alignment lines (but there 
probably is for fonts mixing Western and non Western glyphs). And even 
if so, our font interface (nor FOray's i/f I assume) does not expose 
this sort of detail. 

If the two attributes (offset and baselineOffset) are enough in the fop 
area tree to cover vertical writing modes I am not sure about - this is 
"for further study".

Hope this makes sense

>
> 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
Cheers
Manuel

Re: Characters and area traits

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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

Re: Characters and area traits

[Manuel Mall <mm...@arcus.com.au>]

On Fri, 16 Sep 2005 10:39 pm, Chris Bowditch wrote:
> 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.
>
> Well I tend to agree. Treating fo:character as fo:inline just because
> the Renderer interface doesn't have a renderCharacter method is a
> nasty bodge. As you say if there are subtleties to be observed when
> rendering an fo:character then go ahead and change the Renderer
> interface.

Thanks Chris - that's not quite it. There is a renderCharacter 
interface. The problem is that when giving an inline area to the 
renderer the renderer needs to know with respect to vertical (bpd) 
positioning two items:

1.) Where does the area begin within the line because inlines can be 
taller or narrower than the line height (bpd) of the line area they 
belong into. The renderers need to know this so they can draw any 
borders correctly above and below the area.

2.) Where is the baseline within the inline area for the correct bpd 
positioning of the glyphs. 

Currently the interface (= area tree) has only one attribute related to 
this vertical positioning and I need two as explained above.

>
> Chris

regards

Manuel

Re: Characters and area traits

[Chris Bowditch <bo...@hotmail.com>]

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.

Well I tend to agree. Treating fo:character as fo:inline just because 
the Renderer interface doesn't have a renderCharacter method is a nasty 
bodge. As you say if there are subtleties to be observed when rendering 
an fo:character then go ahead and change the Renderer interface.

Chris

Re: Characters and area traits

[Manuel Mall <mm...@arcus.com.au>]

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

Re: Characters and area traits

[Manuel Mall <mm...@arcus.com.au>]

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

Re: Characters and area traits

[Finn Bock <bc...@worldonline.dk>]

[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].

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