On May 8, 2008, at 14:17, paul womack wrote:
O.K.
I've found this documentation on the "area tree" internal modelling:
http://xmlgraphics.apache.org/fop/dev/design/areas.html
I think this page:
http://xmlgraphics.apache.org/fop/0.94/intermediate.html
says that the XML format is "subject to change".
q1) May I assume that any particular version of FOP would be able
to consume an area tree (XML) that it had itself generated?
That's a reasonable assumption, I think.
q2) And, a detail question, which I have not been (easily)
able to find an answer to: in the area tree, what are the units?
1/1000 of a point (= non-standard 'millipoints'), or 1/72000 inches.
My present plan is to identify the lower bound of the last text line
from the area tree, then use that to perform a second fop pass (all
the way from the start) with a "carefully contrived" page-height.
What I think would be the easiest approach:
-> generate an area tree using a relatively large page-height (enough
to fit the largest content)
-> use forced breaks (break-before="page") in the FO to trigger the
page-breaks
-> if you look at the area tree, you will then see <regionViewport />
elements generated for the region-body of each page; if the initial
used page-size is large enough, these should have the exact same
dimensions on every page
Finally, run the area tree through an XSLT transform, that simply
copies the input, but adds special processing for those
regionViewports: check the childnodes' accumulated 'bpd' attribute,
and shrink the regionViewport's bounds so it will fit nicely around
the content.
This is all a bit speculative, but this seems the most efficient way
I can come up with FTM, and it does presuppose some knowledge/
understanding of XSLT.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
