xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter B. West" <pbw...@powerup.com.au>
Subject Re: [VOTE] Properties API
Date Fri, 05 Dec 2003 01:34:29 GMT
Victor Mote wrote:
> Peter B. West wrote:
>>2% of what?  Of a reference area.  Of what actually gets laid out on a
>>page.  If a single flow object gets laid out over more than one page,
>>that reference may vary, but nothing changes in the FO Tree.  It makes o
>>sense to second-guess the Area tree within the FO tree.  It's within the
>>Area tree that all of these floe objects begin to take on concrete
> Sec. 7.8.4 indicate that font-size percentages apply to the parent element's
> font size, which would be from the FOTree, not from areas.
> However, I fear that in the general case you may be right. The relative
> column-width problem in tables may fall into this category. If so, then the
> solution is to pass the relevant Area object to the "get" method so that it
> can see more of the Area's context. Any Area can (or should) be able to see
> not only its Area Tree ancestry, but its FOTree ancestry as well.

See Section 7.3 Reference Rectangle for Percentage Computations

>>>>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.
>>>Yes, this is the real issue.
>>Only one of the real issues, I'm afraid.
> OK, what are the others?

The thorns that immediately stick in my finger are

1) markers
I have a pretty well-developed idea of how to implement the FO tree
building side of this in alt.design.  It involves
static-content-specific changes to the current FO tree building
algorithm, and a slight generalization of the SyncedFoXmlEventsBuffer
class to allow events to be read from a variety of sources.  In a word,

2) Area tree dependencies for FO expressions.  Basically, length
calculations involving percentages.

2a) Handling the expressions.
2b) Designing the interaction between the FO builder and the Area tree

3) Layout look-ahead and backtracking.  Closely related to 2b.

4) Managing the association out-of-line areas (footnotes and floats) 
with the FONode/Area in which it was defined and the higher-level areas 
(e.g.  before-float-reference-area, footnote-reference-area, 
main-reference-area) which are juggled as a result of the lower-level 

More on these design issues in a subsequent post.
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

View raw message