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: [Xmlgraphics-fop Wiki] Update of "GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats" by VincentHennebert
Date Fri, 11 Aug 2006 12:00:50 GMT

On 11.08.2006 13:26:51 Vincent Hennebert wrote:
> 2006/8/11, Apache Wiki:
> > Dear Wiki user,
> >
> > You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for
change notification.
> >
> > The following page has been changed by VincentHennebert:
> > http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats
> >
> > The comment on the change is:
> > Difficulties around side-floats
> 
> Ok guys, I've been searching for 3 days for a simple, elegant, powerful,
> effective, ligthweight solution to make the total-fit algorithm work
> with side-floats, but can't seem to find one. This issue is somewhat
> related to the one regarding differing available ipd in page sequences
> (solving one might help solve the other one, at least). There is also
> some similarity with tables, i.e., how to combine several "vertical"
> Knuth element lists into just one. Excepted that in the case of
> side-floats, we may choose several completely different solutions to
> place them. And this is a case-by-case decision: one time this will be
> better to differ the float, one other time to break it, one other time
> to compress it...
> 
> In some situations, a best-fit approach could even produce better
> results, as we would have the possibility to consider the differing of a
> side-float. But it is well-known that best-fit may be much worse than
> total-fit regarding before-floats and footnote placements.

Are you sure that it's "much" worse? Note that even TeX uses best-fit
for page breaking.

> Looking at how tables are handled might give me some ideas for
> side-floats, but this would require some time and there isn't much left
> now.
> 
> I also have some ideas for improving the handling of before-floats and
> footnotes, and I'd like to implement them while I have time and it's
> still fresh in my memory.
> 
> The implementation I propose on the Wiki page has its limitations but
> should work in most cases. This might give a basis for further
> improvements.
> 
> I'm thinking about making a poll on fop-user to know what are their
> expectations regarding side-floats, and which usage they would make of
> them. This might help make some design decisions.

That should certainly provide some interesting feedback.

> Well, in one word, I'm a bit lost as for what to do, now.

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
have much theoretical reference material on using the Knuth approach on
page breaking. Most of what exists today around page breaking is by M.F.
Plass or worked out by us on our Wiki.

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.

How does that sound?

Jeremias Maerki


Mime
View raw message