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... :-)
Good luck!
Cheers
Andreas
Thanks,
Vincent
--
Vincent Hennebert Anyware Technologies
http://people.apache.org/~vhennebert http://www.anyware-
tech.com
Apache FOP Committer FOP Development/
Consulting
