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

Reply via email to