J.Pietschmann wrote:
Victor Mote wrote:
This is a good question. The answer to the first part is that it should
return an int, representing the number of millipoints. When it cannot be
resolved, it should return an int constant TBD_LAYOUT (or whatever),
which
is equal to -32,987 (or whatever). So, the Area Tree or Layout needs
to then
perhaps query another "get" method to determine how it should compute the
value from its Area Tree context, or, as I mentioned in a recent
(within the
past hour or so) posting in response to Glen, either 1) passing
context data
to "get", or 2) making "get" look at the area tree context before
returning
the value.
What about font-size="12pt+2%+0.8*from-parent(height div 32)" ?
Good question. Make it
font-size="12pt+2%+0.8*(from-parent(height) div 32)" though. Even
nastier is
font-size="12pt+2%+0.8*(from-nearest-specified(height) div 32)"
because in markers and in static-content, we have to keep track of where
*all* property specifications occur in the ancestry FO tree to resolve
it. In general, the functions will be resolvable as the FO tree is
built. The tree is "static", in the sense that the tree relationships
are maintained in spite of any to-ing and fro-ing with the Area Tree.
Markers are an exception, and because marker properties are resolved in
the context of the static-content into which they are eventually placed,
all the information required for from-nearest-specified() must be
available in the static-content FO subtrees.
Because this is not required in the fo:flows, a good deal of property
storage efficiency is realizable.
This is why I was talking some time ago about a PropertyValue type which
is an RPN-style expression, which can be rapidly resolved without
recourse to the general parser. Without it, we have to carry at least
some expressions around in the raw, after having first parsed them in
order to determine that we can't resolve them, and then throw them to
the parser again whenever a) we have sufficient context, or b) the page
is re-laid. The idea of performing a full parse on a given expression
more than once makes me nauseous.
The approach I am thinking about with such expressions is to associate
the expression, and therefore the FO node, with the *area* which will
provide the context for the resolution of the percentage component(s) of
the expression. (It may be enough to use the parent area of the areas
that the node generates, and to work back to the appropriate reference
area or other dimension when the parent dimensions are resolved.)
When the dimensions of such an area are resolved, the list of attached
FO property expressions can also be resolved. Exactly how to do this I
am not yet sure, but I am thinking of something along the lines of a
co-routine, implemented by message-passing queues, similar to the
existing structure of the parser/FOtree-builder interaction.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
