Indefinite page-width / page-height

[Andreas L Delmelle <a_...@pandora.be>]

Hi,

I took a quick stroll through the code, and now I'm really getting the 
impression that implementing indefinite page-width or page-height isn't 
all that hard to achieve.

(Those enlightenments by Jeremias and Manuel yesterday sure gave me the 
kick that was needed to grasp what happens and why our current 
layout-engine is so darn' cool :-) )

The remark about running into a limitation WRT using int and 
millipoints, which definitely did put a smile on my face :-), doesn't 
seem to pose a problem, since the Integer.MAX_VALUE won't actually be 
used anywhere for measurements --just as a hint to the 
BreakingAlgorithm that there is no constraint on the page's height or 
width. Explicit breaks are still possible. Luca was very right in 
pointing out that the breaking algorithm can't be ignored.
Running out of memory is indeed the more likely result, but my guess is 
that these properties weren't meant to be used to generate one 
outrageously looooooong page. They do come in handy if you want to make 
a nice electronic photo-album PDF, where each page doesn't necessarily 
have to have the exact same dimensions --implementing "auto" for 
page-width and -height is also a must if you don't want to end up with 
pages that are all 8in wide or 11in high.
If the user forgot explicit breaks, then that's his concern --on a JVM 
with sufficiently large heap-size, he will surely curse himself when he 
first has to wait a couple of minutes only to realize that FOP crashes 
and didn't get to render *any* content :-)

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')

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.

4) Should code be added to FODimension itself for dealing with the 
value indicating indefinite page-size? Might be better to subclass 
FODimension... I'm not sure yet. I guess not creating a FODimension at 
all would lead to NPE's being thrown.

That's it for now. AFAICT, the BreakingAlgorithm as it currently works, 
requires only minimal modification to handle the rest without any 
problems.
See what I mean: almost no changes to the layout-engine are needed --at 
most, use Integer.MAX_VALUE in PageSequenceLM.getAvailableBPD() if the 
BPD returned by the viewports turns out to be -1 or zero, and force the 
current PageViewport's height/width in a break-situation. Come to think 
of it, the first can most likely be handled by the viewports 
themselves.

Cool!


Cheers,

Andreas


[*] BTW: currently, if the height/width is explicitly set to a negative 
value, you get no real warning about this, but it does have its impact 
on the result... It can always happen, I guess, especially when the 
input FO comes from a complex XSL transformation, so it may be 
worthwhile to provide a reasonable fallback in those cases. For 
negative values, maybe we could flip the sign, for zero values the 
currently used fallbacks (8 or 11in) should be sufficient. This could 
be handled in the properties package without any problem.

Re: Indefinite page-width / page-height

[Andreas L Delmelle <a_...@pandora.be>]

On Sep 26, 2005, at 07:01, Manuel Mall wrote:

> On Mon, 26 Sep 2005 05:25 am, Andreas L Delmelle wrote:
>> BTW, stumbled upon an interesting issue:
>> Does anyone know how percentages should be viewed in case the page's
>> height is indefinite? Or would this simply be something the user
>> shouldn't be doing at all (i.e. define the page-height to be
>> "indefinite", so that its ultimate value depends on the laid out
>> content, and at the same time define certain properties as having a
>> value that is a percentage of the page-height...?) My common sense
>> tells me that this is a circular reference, so the results are
>> "unpredictable", and I can safely create a pageHeightContext with bpd
>> set to Integer.MAX_VALUE...
>
> I would say
> a) in the case of percentages being defined on an indefinite base value
> the behaviour is not defined in the spec, ie. left to the user agent.
> b) in terms of protecting the user from him/herself

:-) Yeah, most people do need protection from themselves, don't they? 
Even the best of us do --or should I say: _especially_ the best of us 
;-)

> a base value of 0 in this case may be preferable, at least you
> wont get huge margins or regions. This could be caught in the
> SimplePercentBase constructor so you don't have to have if-then-else
> everywhere.
> Alternatively,
> c) if we want to be really nice to the user we could instead catch it 
> in
> the percentage evaluation, in LengthBase.getBaseLength check if the
> value to be returned is MAX_VALUE and if so force it down to 0 and log
> a warning for the user.

Agreed. Which one of the two --well, perhaps the latter is indeed the 
nicest, so I'll have a look at that ASAP.

Thanks for the FB.


Cheers,

Andreas

Re: Indefinite page-width / page-height

[Manuel Mall <mm...@arcus.com.au>]

On Mon, 26 Sep 2005 05:25 am, Andreas L Delmelle wrote:
> On Sep 25, 2005, at 19:47, Andreas L Delmelle wrote:
> > 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:
>
> ...
>
> BTW, stumbled upon an interesting issue:
> Does anyone know how percentages should be viewed in case the page's
> height is indefinite? Or would this simply be something the user
> shouldn't be doing at all (i.e. define the page-height to be
> "indefinite", so that its ultimate value depends on the laid out
> content, and at the same time define certain properties as having a
> value that is a percentage of the page-height...?) My common sense
> tells me that this is a circular reference, so the results are
> "unpredictable", and I can safely create a pageHeightContext with bpd
> set to Integer.MAX_VALUE...

I would say
a) in the case of percentages being defined on an indefinite base value 
the behaviour is not defined in the spec, ie. left to the user agent.
b) in terms of protecting the user from him/herself a base value of 0 in 
this case may be preferable, at least you wont get huge margins or 
regions. This could be caught in the SimplePercentBase constructor so 
you don't have to have if-then-else everywhere. Alternatively,
c) if we want to be really nice to the user we could instead catch it in 
the percentage evaluation, in LengthBase.getBaseLength check if the 
value to be returned is MAX_VALUE and if so force it down to 0 and log 
a warning for the user.

>
> Just thought I'd ask, even if only as a rhetorical question :-)
>
>
> Cheers,
>
> Andreas

Manuel

Re: Indefinite page-width / page-height

[Andreas L Delmelle <a_...@pandora.be>]

On Sep 25, 2005, at 19:47, Andreas L Delmelle wrote:

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

BTW, stumbled upon an interesting issue:
Does anyone know how percentages should be viewed in case the page's 
height is indefinite? Or would this simply be something the user 
shouldn't be doing at all (i.e. define the page-height to be 
"indefinite", so that its ultimate value depends on the laid out 
content, and at the same time define certain properties as having a 
value that is a percentage of the page-height...?) My common sense 
tells me that this is a circular reference, so the results are 
"unpredictable", and I can safely create a pageHeightContext with bpd 
set to Integer.MAX_VALUE...

Just thought I'd ask, even if only as a rhetorical question :-)


Cheers,

Andreas

Re: Indefinite page-width / page-height

[Andreas L Delmelle <a_...@pandora.be>]

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