You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Vincent Hennebert <vi...@anyware-tech.com> on 2008/05/13 12:06:24 UTC

Changing IPD, aka Interleaved Page- and Line-breaking

Hi Guys,

Just to let you know that I’m starting my next big task: make it
possible to specify pages of different widths.

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.

That’s pretty much it for now. Any comments welcome :)

Thanks,
Vincent


-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Re: Changing IPD, aka Interleaved Page- and Line-breaking

Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Andreas,

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. ;-)

Thanks :-)


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


-- 
Vincent Hennebert                            Anyware Technologies
http://people.apache.org/~vhennebert         http://www.anyware-tech.com
Apache FOP Committer                         FOP Development/Consulting

Re: Changing IPD, aka Interleaved Page- and Line-breaking

Posted by Andreas Delmelle <an...@telenet.be>.
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
>