Hi Benjamin,

 > Le Fri, Dec 07, 2007 at 12:45:56PM +0100, Frank Mittelbach:
 > > 
 > > layout is called "ftnrightspread" and you can review the results in the pdf
 > 
 > I see one interesting case, about footnotes and multicolumn. The usual
 > layout is to have N cols, with the footnotes of each columns at the
 > bottom of it. It might be interesting to have a layout with different
 > numbers of cols for the text and the notes.
 > 
 > Something like a 2 columns text with a 3 columns footnote area, when there
 > is a quite large difference in text size between text and notes, it
 > avoid having too long lines in the notes.

that is certainly an interesting but probably non-trivial variation/extension

in fact, even balancing the footnotes (without changing the column width would
be an extension of what is there, but posing the same problems really).

Technically one problem is to actually sync the space occupied by the
footnotes with the generation of columns (though there are some possibilities
to get that right more or less all the time -- if i remember correctly the TeX
book even has some code in appendix D for that)

but then there is also a certain difficulty how to handle the case that a page
doesn't contain many footnotes. what should be done in this case? running 3
one-liners across the page may look horrible for example. and if one changes
behavior in that case then the space calculation may become difficult if not
impossible.

anyway, anybody any ideas how this conceptually should behave?


 > I don't know how to have that kind of thing integrated as a parameter in
 > a more global layout.

that would be the least of my worries :-)


 > Another case interesting in mixing various numbers of columns, and that
 > can be handled, is having a "break" across all columns, but not only at
 > the top of the page, like a "middle title". I don't know how it fits
 > with the float placement system, it would be a kind of gluing together a
 > page with balanced columns and no bot floats (the top part) and a page
 > with a cross-cols title (the bottom part).

I'm thinking about this problem for a long long time and haven't found a
suitable or say satisfying algorithmic approach to it.

what is probably doable without too much complication is to allow titles to go
across the page, ie to balance run a title in single column mode and then
return back to the same number of columns as before.

the above idea to force earlier floats into the top part could then be simply
handled with flush points (well perhaps somewhat extended)

what i never got any good idea on how to handle it with the complication of
floats is to change the column numbers for good, e.g. 3-columns then balance
then continue with two columns or something along those lines. 

the problem with the current algorithm is that it builds up float by float so
changing column numbers will change the width of the float areas which poses
one problem.

another problem then would be the area setup for a page would then largly
depend on the content of the page while right now it is static (which helps)
at least static in the sense that one knows what one is aiming for for a
particular page.

and then there is of course the problem what you do if you have 2 such balance
points on a page and a float that sits in the second block. what is that going
to go to?

i'm not saying nothing can be done, just that this really is difficult to be
addressed by some algorithmic approach in a suitable manner and much more
easily done with a totally visual tool.

I mean, the current 2e algorithm is fairly trivial in the amount of
possibilities and alternatives and still many people are baffled by the
decisions the algorithm takes sometimes. Now, part of that is probably due to
the fact that it doesn't offer a way to show why it made certain decisions ---
one of the reasons why the xor comes with plenty of info (not the tracing one
but the one you get when you compile with "progress" option) but to some
extend it is simply due to the fact that a statement like "down here this
particular figure would fit nicely" doesn't easily translate in an algorithm
that has to base its decision on abstract stuff like "bottom figures no larger
than X, no top right figure if there is a top left one ..."

 > Since a multi column is more suited for large page sizes, it can be
 > interesting to have such "middle" titles.

yes. which is why i'm experimenting with the balancing in connection with
floats but ... :-)

good night
frank