On Sep 22, 2005, at 23:28, Andreas L Delmelle wrote:
Hi all,
This post as a status-update, since I've been playing around with this
during the weekend:
<snip />
I'm definitely going to take a closer look soon, but right now I'll
just add a few comments for future reference (in case I don't get
around to it, someone else doesn't need to start from scratch)
Things to do (first glance):
1) In the properties package we should already catch the case of both
height and width being specified as "indefinite", and letting the
other default to "auto" (or the fallback: 11in or 8in), plus give a
warning about this. Rough idea: use a PageDimensionMaker extending
LengthProperty.Maker to deal with that --checks for the values of
reference-orientation and writing-mode could also be added here (cfr.
Rec 7.25.13 dependency on 'block-progression-direction')
This is done: see commit r291351
But...
2) In the area package, PageViewport currently sets the pageHeight and
pageWidth unconditionally to the integer value of the respective
Length instance variables of its SimplePageMaster. This should be
changed to, say a default of -1 or zero in case of getEnum() ==
EN_INDEFINITE (?), since negative or zero values for page-height or
-width make no sense (at least not to me, but the 1.0 Rec doesn't seem
to enforce a positive non-zero value? [*]).
Also, probably something like a setPageHeight() method should be added
that allows the PageSequenceLM to feed the accumulated content-height
or -width back into the PageViewport after the BreakingAlgorithm has
done its work.
3) Similar remark as above for area.Page, which creates a FODimension
unconditionally using the height and width integer values.
Currently, I have solved this locally by creating the pageVP with the
indefinite dimension set to Integer.MAX_VALUE.
The only things I'm still looking for are ways to:
a) retrieve the accumulated content-height/-width (or: the difference
between the initial page-height/-width and the content-height/-width up
to that point)
b) feed that value back into the pageVP: well, not so much the way to
do it, but presumably this needs to trigger a setXXX() for the
dimension in question in area.Page as well --and most likely also the
RegionVP which gets its dimensions from the pageVP...
I'm guessing the place where all this should happen is
PageSeqLM.finishPage()
As I have it now, the pages remain Integer.MAX_VALUE millipoints
high/wide, so it's not ready for a commit yet. A simple testcase has
already been added to test/layoutengine/testcases, but disabled for the
time being
If anyone familiar enough with the layout/area packages can provide any
assistance here, this would be much appreciated. Again: before I
succeed in figuring this out by myself --which will happen if you wait
long enough... but if anyone can speed things up by pointing me to the
right places, there's another user we can satisfy --or at least we'll
possibly gain a few more 0.90svn users if we announce on fop-users that
this feature is available :-)
Cheers,
Andreas
