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
