xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Pepping <spepp...@leverkruid.eu>
Subject Re: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert
Date Fri, 11 Aug 2006 18:33:20 GMT

On Fri, Aug 11, 2006 at 04:17:15PM +0200, Vincent Hennebert wrote:
> 2006/8/11, Jeremias Maerki:
> >Are you sure that it's "much" worse? Note that even TeX uses best-fit
> >for page breaking.
> Oh yes I'm sure ;-) It's a common complaint from users of the LaTeX
> world that figures are placed in a weird manner. There are plenty of
> parameters to tweak the output by hand, but this doesn't always give
> satisfying results. And given that manual intervention isn't really an
> option in the FO world...
> Note also that TeX implemented best-fit for page-breaking only because
> of limited computation resources at that time (you know, those good old
> 80's).

IIUC, LaTeX has a two-layer page break algorithm. First it lets TeX do
its page breaking, then in macro language it considers the result and
may ask TeX to do another pass over the page. It can request several
passes over each page. I have never studied it in any more detail.

> >Hmm, yeah, it's a bit difficult. Best-fit vs. total-fit plays into this.
> >Best-fit will most likely replace total-fit because of the additional
> >features we can cover. If that means some drawbacks on things like
> >footnote placement that could be acceptable if the drawbacks are not too
> >great. ATM, I cannot estimate the impact of the change. Too bad we don't
> Well, to me switching to best-fit is out of the question. Total-fit is a
> killer feature for technical documents with lots of figures and
> footnotes (the current implementation is already better than Xep...).
> This would give Fop a big advantage over concurrent implementations.
> Rather, we might consider implementing both strategies. Ideally there
> would be an option in the config file ( "optimize-for-books" vs
> "optimize-for-fancy-layouts" or something like that). The generation of
> Knuth elements would be the same, only the breaking algorithm would
> differ. But abandoning total-fit is not an option, IMO. Moreover...

I agree with you. I would be really sorry to see the total fit
algorithm be abandoned in FOP.

> >I would not consider it a bad move if you concentrated the rest of your
> >time of the GSoC on the before-floats and footnotes, especially if it's
> >unlikely that you can finish side-floats in time and if the switch from
> >total-fit to best-fit hangs in the air. Even without an actual
> >implementation the groundwork for a side-float implementation in form of
> >some very good documentation is a very satisfying result. I would
> >consider the goals of the GSoC project met. It might be good to add some
> >best-fit-specific comments, though.

I am just reading through your side floats page. It is impressive. It
is indeed a good result for the GSoC project. It was clear from the
start that this would be a challenge of unknown severity.

Regards, Simon

Simon Pepping
home page: http://www.leverkruid.eu

View raw message