Re: Characters and area traits
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
Re: Characters and area traits
[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
Re: Characters and area traits
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
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 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
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
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
