xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Google Summer of Code
Date Mon, 24 Apr 2006 20:36:58 GMT

On 24.04.2006 20:49:54 Vincent Hennebert wrote:
> Hi Jeremias,
> 
> Thanks for your review!
> 
> > Vincent, a comment on yours: For before-floats, you refer to best-fit
> > and first-fit approaches. I'm not sure if it's really relevant here. If
> > I'm not mistaken before-floats are pretty similar to footnotes which
> > means you can probably take a lot from there. I think that first-fit
> > only really helps when you get to side-floats.
> 
> Well, my understanding of before-floats makes me think that they may
> benefit from a total-fit algorithm. WRT footnotes, the difference is
> that a footnote must appear on the same page as its reference; this is a
> constraint that doesn't exist for before-floats, although it is best to
> place them as near their reference as possible, of course.
> 
> When refering to first-fit/total-fit algorithms I had the paper
> "Pagination Reconsidered" referenced on the Wiki [1] in mind. To
> summarize quickly it is stated that placement of floats benefits from a
> better algorithm than first-fit, quite like for the computation of page
> breaks. In fact LaTeX uses a first-fit algorithm, which often leads to
> floats placed pages far from their reference. So I had the feeling that
> a total-fit algorithm could be applied to floats as well as to page
> breaks.

Yeah, now I remember that part. before-floats can be pretty big (big
images) and that's why it is sometimes difficult to place them near the
anchor, especially if there are several before-floats gathering together.

> > I think that user-configuration for best/first-fit doesn't help much. I
> > rather think that FOP will have to find out itself whether it has to
> > abandon best-fit so it can handle more complex features, i.e. switching
> > to first-fit if it finds one of the following conditions:
> > - side-float in the flow
> > - page-masters with different available IPD in the flow
> > - tables with auto table layout (when individual column widths are
> > requested for each page)
> 
> That may be discussed. I remember of discussions on this list about the
> cost of a total-fit algorithm regarding time and memory consumption.
> IIRC there was stated that such an algorithm should be optional for
> rendering documents that don't need it, like invoices. That's why I was
> thinking of a config option.

Right. I guess it's less the time consumption than the memory
consumption. First-fit would allow to release memory much earlier. On
the other side, less memory means more speed. :-)

> Regarding Fop automatically switching to the most appropriate algorithm,
> depending on the situation, I'm afraid of the complexity of such a
> behavior. That may be difficult to estimate which strategy is to be
> adopted, and when it should be decided that a given strategy has failed
> and that it should be switched to another one. But I may be wrong.

No, thinking about this some more, especially after your input here, I
think you're on the right track. I guess it wouldn't be a tragic thing
if we threw an exception if total-fit is active but the requested
features cannot be solved in that mode. I don't think it's so much
complexity that works against automatically switching the algorithm but
it's probably speed in this case, because we'd have to iterate over the
whole FO tree to see what features are encountered. For invoice-style
documents, that's not really an option because speed is everything.

> Vincent
> 
> 
> [1] http://wiki.apache.org/xmlgraphics-fop/LiteratureLinks



Jeremias Maerki


Mime
View raw message