Notes on properties

["Peter B. West" <pb...@powerup.com.au>]

Fopdevs,

I am still struggling with a few property-related issues, which I will
vent here and on xslfo-proc-dev in hopes of some feedback from others
who have been down the pit.

The spec overview has the process of refinement, including expression
evaluation and calculation of computed values, completed before area
tree generation.  Part of this refinement is the resolution of relative
into absolute lengths with respect to the property context.  That
context includes the current font-size, and the conversion of "relative
numerics by type to absolute numerics within additive expressions."

Section 5.9.7 Relative Numerics includes:

It is an error if the property context has no available conversion for
the relative numeric and a conversion is required for expression
evaluation (e.g., within an add operation).

Constraining property expression evaluation to occur during FO tree
building simplifies the process.  All of the information required to
resolve the details of an individual FO is available in the immediate
line of ascent through the FO tree.  However...

Markers.

The view that expression evaluation can be completed in before the 
construction of the area tree is incompatible with markers.  The 
retrieval of markers is defined in terms of areas and pages.  The page
and area within which retrieved marker is expanded provides the context
for the evaluation of the properties defined on the fo:retrieve-marker. 
Even though it may be possible to resolve values of the fo:marker
children with reference to the FO tree as it exists at the time of
marker retrieval, this retrieval can only occur after some of the area
tree has been constructed, so at the very least area tree construction
must take place in parallel with FO tree construction to some extent.

Markers and EMs.

It seems to me that EMs can be resolved immediately in all cases except
markers, and that the best approach is to special-case markers, and
proceed with the immediate elimination of EMs in all other cases.

Marker subtrees.

What I plan to do is to process the fo:marker itself in the context of
the FO tree, but to read the marker subtree, bypassing all property
expression parsing, into an individual marker tree, which will be
maintained in a hash of some kind in the associated FOTree object.  The
FOAttributes object which is normally constructed as a by-product of the
XML parsing can be stored with the proto-FONode in the marker tree.
When the fo:retrieve-marker is processed and the appropriate marker tree
is recovered, the marker subtree will be read to construct the FO tree
under the retrieve-marker.  This process can mimic the normal reading of
the input text, construction of the FONodes and resolution of the
properties and property expressions from the FOAttributes.  At this
point, EMs will be resolved.  Note that both fo:marker and 
fo:retrieve-marker are illegal within the marker subtree.

Marker datastructures.

Don't know much about these yet, except that they will be complex.
Markers have to be accessed by class-name, which is not unique except
within a parent, so they must be collected into (qualifying) sets by 
this non-unique key.  Evaluating the hierarchy within this set is almost 
completely layout (i.e. area tree) dependent.

"Each fo:marker is conceptually attached to each normal area returned by 
the fo:marker's parent formatting object. Additionally, an fo:marker is 
conceptually attached to each non-normal area that is directly generated 
by the fo:marker's parent formatting object. Conversely, areas generated 
by any descendant of an fo:flow may have zero or more fo:marker's 
conceptually attached."

Representing this will be interesting, but it is related, I think, to 
the representation of keep and space-specifier relationships.

Percentages.

These are nasty.  Percentages may be defined relative to lengths which 
are not known at the time the FO tree is built, and which may change as 
layout is refined.  However, as noted above, the spec leads us to 
believe that they can be resolved to computed values at FO tree 
construction.  Clearly, in this case, as in the case of markers, they 
cannot.

Inheritance

This complicates inheritance.  In almost all cases, inheritance is of 
the computed value, and it is inherited by the computed value.  That is, 
in the inheriting FO, the specified value is either 'inherit' (or a 
function call) or non-existent, and the computed value is taken directly 
from the computed value of the bequeathing FO.  When the computed value 
is not known, what is inherited?

If a percentage is assigned to the inheritor's computed value, the 
reference dimension must also be implied or indicated.  I have not 
attempted a rigorous analysis of all possible cases to determine whether 
the correct dimension would always be implied, i.e., that the reference 
dimension for all cases of descendants which may inherit will always be 
the same as that of any possible ancestor.  I am proceeding on the 
assumption that it would not.

That given, my preference is to set the inheriting computed value to an 
Inherit object which simply contains a reference to the bequeathing 
computed value, or rather, because it will initially be null, to the 
PropertyTriplet which will eventually contain the computed value.  The 
requirement for this (essentially, whether the referenced computed value 
was null or a percentage) can be determined as the attempt is made to 
resolve inheritance at the time of FO tree construction.

Percentages in additive expressions.

I agonised for a long time over the possibility of percentages (and, 
until I decided on the above strategy, EMs) in expressions.  The anguish 
was greatly prolonged by my failing to notice some implications of the 
paragraph quoted at the top from Secion 5.9.7.  I am now interpreting it 
in the following (highly favourable) way.  Because the spec asures us 
(falsely as it turns out) that the resolution of relative lengths 
happens during the building of the FO tree, and before the construction 
of the area tree, then the absence of any necessary context for 
expression evaluation is an error.  For a percentage this includes any 
additive operation (by definition; the spec demands in 5.9.6 that the 
operands in mod, addition and subtraction be absolute numerics of the 
same unit power).  However, as a percentage is an indeterminate length, 
it is only possible to combine it with numbers in a multiplicative 
operation.

While there are certain cases (e.g. font-size as a percentage, which is 
effectively an EM specification) in which a percentage has an 
immediately available reference dimension, in most cases the reference 
is a dimension of an area, so I am going to draw a long bow and say that 
no such percentage, in principle, can be resolved within the 
construction of the FO tree, so almost all expressions involving 
percentage are errors.  I may be possible to loosen this restriction in 
practice, but it will greatly simplify the implementation.

I'll post later about some of the details of data structure and methods 
for property resolution, and on the order in which aspects of resolution 
should occur.

Peter
-- 
Peter B. West  pbwest@powerup.com.au  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Notes on properties

[Karen Lease <kl...@club-internet.fr>]

Peter,

As you might imagine, I spent some time tussling with several of these 
issues a while back when I integrated the expression parsing from James 
Clark's XT into the FOP expression parser. Perhaps my musings will be of 
interest.

The idea was to resolve everything at FO building time, but as you note, 
there are cases where this isn't possible. Since I wasn't dealing with 
markers yet, most of my problems came with percentages.

That is why there are a couple of special kinds of Length classes 
defined in the fop datatypes. A percentage is in fact defined with 
respect to some reference dimension which in most cases isn't defined 
until layout gets underway. So the Length is in a more or less 
unresolved state until its reference dimension is calculated during 
layout. The proportional table width is similar since the table width 
itself may not be known until layout. Finally, I had handled the case 
where these kinds of dimensions could be combined with some absolute 
dimensions. This stuff works, at least in some cases, but I suspect not 
in all cases. In particular, if something lower down in the inheritance 
tree tries to one of these undefined values during FO tree building, it 
will not get anything reasonable.

I did think somewhat about using the approach which James Clark's code 
originally used, which would essentially mean storing the parse tree for 
the expression and evaluating it only during layout. But that seemed 
like heavy-duty overkill for a situation in which most expressions had 
constant values, so I never tried that out.

As to the impact of inheritance on percentage-based property 
specification, I actually wrote a mail about this to the XSL editors 
(before the final REC stage): 
http://lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0009.html. I 
asked about the computed vs. specified issue and the official response was:
<quote>For compatibility with CSS2 the general rule, even for 
percentages, is that the computed value is inherited. We have added a 
section specifying in detail which area is used as reference when the 
"general rule" is not sufficient, e.g. a percentage specified on fo:root.
</quote>

I would interpret this to mean if an FO A specifies a property as a 
percentage, and FO B which is a child of A explicitly or implicitly 
specifies inherits it, that the resolved value on B is identical to the 
resolved value on A, using whatever reference dimension is appropriate 
for A. I would think your idea of setting the property value on B to an 
"Inherit" object referencing A would allow this to be implemented. It's 
more or less the way my PercentLength class worked except that in that 
case, the property value for A referenced the FO whose dimension was to 
be used as the reference.

Regards,
Karen

Peter B. West wrote:

> Fopdevs,
> 
> I am still struggling with a few property-related issues, which I will
> vent here and on xslfo-proc-dev in hopes of some feedback from others
> who have been down the pit.
> 
<snip/>



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org