> -----Original Message-----
> From: Finn Bock [mailto:[EMAIL PROTECTED]
> [Andreas L. Delmelle]
> > Hmmm... coming back to my recent question about the use of/access to the
> > background-color property: I somehow would feel much for
> further extending
> > the way the Common*Properties are handled. IIC, the calls like the above
> > should only happen in the background via the propMgr of the
> FObj, and not
> > become part of the public API.
> I dunno. The spec clearly list which properties that apply for a element:
> file:///d:/java/REC-xsl/slice6.html#fo_external-graphic

(Off-topic: Finn, I don't think I have access to your d:-drive ;) )

> so it makes sense to find the same list of assignments in the layout
> managers.

Indeed it does, but I don't think Layout needs them all, neither does it
need them in their initial 'states' (don't really know what other word to
use for this...).

For instance:
<fo:block background-color="inherited-property-value(color)" ...>

The layout manager doesn't need _this_ value of the property, it needs the
actual ColorType (so I guess I basically agree with your comment about the
more abstract version).

<snip />
> Yeah, if it make sense to add more groups of properties together (and it
> seems that such a ipd,bpd pair make sense) I don't see a problem adding
> that.

I just think this will lead to an API that's a bit clearer, cleaner and so,
in the long run, easier to manage and maintain. I don't really know whether
the Common*Properties were separated out because they are, well, common, and
it's more efficient for them to be treated as a bundle. Maybe it was
originally the intention of creating property groups along the groups in
which they are divided in the spec (see
AFAICT the basic framework is already present to tie the
'propertyList.get(...)'-calls all together in the PropertyManager. If it is
decided at a later point that something needs to be added/modified WRT
Properties, this could avoid having to modify numerous corresponding
propertyList.get()-calls in all related FObj's / LM's / Areas. ( Referring
to the string->int conversion, and the hours Glen has spent to trace the
calls and replace the constant-names... )

> > ...
> > Length ipd = aProps.ipd;
> Yes, except that it is a LengthRange property.

Ouch! My mistake :)



Reply via email to