[xmlroff] Interface vs GObject properties vs indirection?

[Tony Graham]

Implementing fo:static-content and fo:region-* raises an interesting
question for xmlroff's design.

xmlroff's area tree contains information about areas produced by FOs.
The information in the area tree is only what is necessary to place the
area on the page -- it's size, position, border widths, etc.

The information that isn't going to change -- border style, colour,
etc. -- doesn't get copied to the area when the area is created, so
drawing the area requires looking up the FO that produced the area to
find border colours, etc.

This is straightforward for most FOs, but the problem for fo:flow and
fo:static-content is that while those FOs produce the areas and have
some interesting properties such as 'id', they don't have the properties
for borders, etc., since those are specified on their corresponding
fo:region-*.

It's not such a problem for fo:flow if you pretend that it's always its
fo:region-body that generated the area so the same simple property
lookup can work.

Since I don't want to extend the pretence to fo:static-content, I've
been looking for alternative ways to keep the common case simple but
also handle fo:flow and fo:static-content.

So far I've come up with three alternatives:

 - Interface

   FOs with "Common Border, Padding, and Background Properties"
   implement an interface for accessing those properties' values, and
   fo:flow and fo:static-content implement those interfaces by returning
   the corresponding property value from their fo:region-*.

   Interfaces with GObject are tedious because you have to do all the
   plumbing yourself, though producing the code for the common case can
   be automated in the 'codegen' stylesheets.

 - GObject properties

   GObject supports declaring properties on GObjects, and property
   values can be looked up by name.  Every FO's GObject type has GObject
   properties corresponding to each of its XSL properties (and a few
   have a few others to make the code easier).

   The current code does/did lookup of the border-* properties as
   GObject properties.

   It would be possible to declare read-only GObject properties on the
   GObject types for fo:flow and fo:static-content so the mechanism
   still works, but it seems to me that it would confuse the GObject
   view of the formatting objects if two FOs had a bunch of read-only
   XSL properties that aren't defined for them in the XSL spec.

 - Indirection

   Currently an area knows its FO and lookups up properties of that FO
   for border colour, etc.

   An area could, instead, know its FO and from that FO get the FO that
   implements the border colour, etc., properties needed for properly
   drawing the area.

   In the general case, an FO would point to itself, but fo:flow and
   fo:static-content would point to their corresponding fo:region-*.

   The problem is that the 'id' property (and some others in XSL 1.1) is
   always on the first FO, so it may be necessary to look to one FO for
   some properties and to the second FO for others.

I am currently a long way down the interface path, but I'm coming to
prefer the indirection approach since it's both simple and reflects the
spec.

What do you think?

Regards,


Tony.