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
>>dimensions.
> 
> 
> 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
http://www.w3.org/TR/xsl/slice7.html#percrule

>>>>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,
grafting.

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
builder.

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 
contents.

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




Mime
View raw message