The following is for consideration only. I am not proposing any specific
action be taken at this time.

I've notice some inconsistencies in naming as pertains to referring to the
category of properties versus traits.

The XSL FO semantic model (e.g., see
refers to the following entities:

   - attributes
   - properties
   - traits

Traits are further sub-divided into:

   - FO traits, i.e., the results of the refinement process
   - Area traits, also called "rendering traits"

In the FOP implementation, I observe that the term "property" is used to
refer to both FO properties and FO traits, i.e., both the input and the
output of the refinement process.

It may be useful to begin to distinguish between the input to the refinement
process, i.e., FO properties, and the output of that process, i.e., FO
traits. In particular, the (generally) private members of the various FO
objects which have hitherto been referred to as "the value of properties
relevant to fo:*", are probably more accurately described as FO traits,
since it is they which store the results of the refinement process. In
contrast, the value returned by Area.getTraits() denotes the Area
(rendering) traits alone, and, should not, in general, include the FO traits
(unless they happen to also be characterized as rendering traits).

As an aside, the reason I'm noting this is because I needed to re-implement
support for the writing-mode property and its related FO traits. The
existing support for writing-mode used a bit of a hack on PropertyList, and,
furthermore, did not properly implement the refinement semantics required to
produce the writing-mode, inline-progression-direction,
block-progression-direction, and shift-direction FO traits needed to support
right-to-left writing modes.


Reply via email to