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