xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas L Delmelle <a_l.delme...@pandora.be>
Subject Re: Indefinite page-height
Date Thu, 23 Mar 2006 18:48:52 GMT
On Mar 22, 2006, at 21:52, Walter Bauer wrote:

Hi Walter,

   [Me :]
>> Only the offset of the regionViewport in question needs to be altered
>> (decrease by Integer.MAX_VALUE - PBP.difference? Something like
>> that...?)
>
> yes, and that's exactly what I don' t get to work.

Well... it depends. I had another glance at the related code. Where  
exactly in finishPage have you put your code?

I'm guessing here, but if you put it all the way at the top --before  
the calls to layoutSideRegion()-- wouldn't that solve the problem?

<snip />
>
> Further more: The reason why I tried to put this code into  
> finishPage instead of finishPart:
> - I couldn't find out why Integer.MAX_VALUE doesn't work. The  
> resulting length is off by 10000000 and I looked for "10000000"  
> only finding this.add(new KnuthGlue(0, 10000000, 0, null, false));  
> in AbstractBreaker. Coincidence or actually the reason for some  
> integer overflow? Returning Integer.MAX_VALUE - 2 * 10000000 as q&d  
> check didn't work either.

Hmm...
(Integer.MAX_VALUE + 10000000 - (Integer.MAX_VALUE - difference)) =  
10000000 + difference

Will need to take a closer look at that.

> - Putting it into finishPart to me looks a little like a hack using  
> implementation specifics.

Yes, but ... FOP is the implementor here, no? What's 'hacky' about  
using the specifics of our own implementation? :)

> For me, finishPage is a more "public" point to perform the page  
> size adjustment. But well, I'm not accustomed to the architecture  
> and style yet to judge this. Perhaps a cleaner way would be to add  
> something like getUsedBPD() to BodyRegion to decouple the  
> dependencies.

Could be the logic behind it is that finishPart() is guaranteed to be  
called before finishPage(), and finishPage() contains the activation  
of layout for the side-regions... From a certain POV, the focal point  
of this recalculation of indefinite page-height(*) is the flow  
layout. This would mean that my initial thoughts on this are wrong,  
and the side-regions need no recalculation after all (?)
Even better if I'm right here...

(*) Or is it BPD? Well, depends on writing-mode and/or reference- 
orientation of the region-body...
Grrr :) See, it could be that the total page-height ends up being:
region-before-bpd + region-body-ipd + region-after-bpd

One thing I pondered over: what if the region-body's height is its  
ipd? What happens with text-alignment, especially justified text? And  
start-aligned (with reference-orientation="90")? Will the text  
'shift' automatically when the viewport's height is altered? (I  
assume it's not *that* simple ;))


Cheers,

Andreas


Mime
View raw message