Andreas Delmelle wrote:
> On May 13, 2008, at 12:06, Vincent Hennebert wrote:
>> Just to let you know that I’m starting my next big task: make it
>> possible to specify pages of different widths.
> Cool! You have our full support. ;-)
>> I spent some much useful time with Simon during the ApacheCon where he
>> gave me detailed explanations about his changes in the
>> Temp_Interleaved_Page_Line_Breaking branch. I don’t understand all of
>> them yet since the impacted part of the code is still a bit new to me.
>> But I will now take over his work.
>> However, given the complexity of this area I felt I needed to experiment
>> a bit with my ideas on a simple prototype, before diving into the real
>> implementation. I’ll publish the results of my experiments on the
>> wiki... as soon as I have some results.
> Hope to see them soon.
>> That’s pretty much it for now. Any comments welcome :)
> Not sure if I get it correctly, but my last thought-experiments in that
> area went in the direction of nested Breaker implementations (or one
> single Breaker that is passed down). No coincidence, of course, since I
> started playing with that for the fo:inline-container implementation
> (Bugzilla 44885). What I needed there was the height of the resulting
> box to get the alignment context right for the ancestor
> LineLayoutManager. To acquire that height, requires a pass through the
> breaker, IIC. At least, that's how it is solved for block-containers...
> No idea if I got the idea entirely correct. What still bugs me about the
> inline-container implementation, is that I currently create a completely
> new PageBreakingAlgorithm instance, while this could probably be trimmed
> down. It would be /slight/ overkill if you have a block with
> inline-containers with no more than a handful of characters to create a
> new PBA.
> What if we introduce the concept of a BlockBreaker (? much like we
> already have a BlockContainerBreaker), only the Breaker implementation
> should be able to hold off on gathering more element-lists (as is the
> case now: call doLayout(), which calls getNextBlockList(), and all the
> base element-lists are gathered, until end-of-flow or until a forced
> break is signaled).
> We should be able to do something like:
> - getNextElements() for the first (few?) childLM(s) of the flow
> - run through the Breaker without adding any areas, just compute the breaks
> - check if we have an unavoidable page-break (bpd-overflow:
> breaker.difference > parentBreaker.availableBPD)
> - if not, continue with a few more LMs; otherwise, start adding areas,
> and continue from the last position
> That may give us the opportunity we need to change the available IPD for
> the following breakers.
> Just some ideas. Maybe I'm going entirely in the wrong direction with
> this, but it seems like a good opportunity to find out... :-)
Wow, I will need some time and code study before being able to comment
on your proposal. My knowledge of the layout code is limited to tables
so far. I’ll get back to you as soon as I have more insight.
Thanks for explaining your ideas anyway :-)
Vincent Hennebert Anyware Technologies
Apache FOP Committer FOP Development/Consulting