On 10.03.2005 16:15:10 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > I got my copy of Michael Plass' dissertation today. A cursory 
> > overview shows that this document will provide some insight 
> > on using Knuth element model for page breaking but it also 
> > makes clear that we still have to come up with solutions for 
> > certain tricky problems that he didn't have to deal with back 
> > then. At any rate, the dissertation seems more helpful than 
> > the two documents we found by Brüggemann-Klein, Klein and Wohlfeil.
> 
> Hi Jeremias:
> 
> I got my copy yesterday and spent some time in it as well. I wanted to weave
> some thoughts about it into the thread from a few days ago that dealt with
> this same topic. In that thread, you raised the same two issues that I have
> been troubled about for page-breaking: 1) differing page IPDs, and 2)
> side-floats.
> 
> WRT differing page IPDs, I think it is probably very acceptable in almost
> every case to simply change the rules. IOW, If you want to use layout
> strategy X, you must do so on a page-sequence-master that has all page IPDs
> the same and that uses the same column-count. (Plass acknowledges that the
> problem to be solved is two-dimensional, but specifically says that his
> algorithm is one-dimensional.) Whether dealing with business forms
> (invoices, purchase orders, etc.) or high-end book publishing (I have
> experience with both), I cannot think of a use case for differing IPDs on
> pages in the same page-sequence. If the goal is 100% standard compliance,
> this isn't good enough. However, if the goal is to get some work done for a
> client, and it doesn't hinder future 100% compliance, then this would be the
> way I would address it.

A fact is that FOP 0.20.5 had no problems with differing available IPDs.
With Luca's suggestions I think we can (auto-)configure the page
breaking algorithm (read: no separate layout strategy) so it can handle
differing IPDs.

> Side-floats are another story. Plass addresses them by adding a new
> primitive to the box/glue/penalty model, called "insert" (page 15). However,
> I thought the following was pretty interesting as well, drawn from the last
> paragraph of his dissertation:
> 
> "There are other ways of incorporating approximations into the pagination
> routine; for instance, inset figures could be handled satisfactorily by
> doing the pagination as if they were full width figures with the same area
> as the original figures; afterwards the paragraphs could be re-broken in
> order to fit them around the figures. The optimizing line breaking algorithm
> would be helpful in this regard, since it could break the text on the page
> in such a way that it would come out to the right number of lines. Layout
> artists traditionally use approximate copyfitting techniques to do such
> tasks, so methods like this hold much promise."
> 
> So, if an insert requiring 4 square inches is required, and the IPD is six
> inches, add 2/3 of an inch to the BPD of the block, do your copyfitting,
> then come back and lay the block out properly later.
> 
> After thinking through all of these papers and ideas, I am more convinced
> than ever of the utility of pluggable layout. But I guess you guys like
> branches better :-)


Jeremias Maerki

Reply via email to