LISTSERV - LATEX-L Archives - LISTSERV.UNI-HEIDELBERG.DE

Le Tue, Dec 11, 2007 at 12:23:07AM +0100, Frank Mittelbach:
> 
> 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?

This is indeed a tricky part. I see two simpole ways to get out of the
trap:
- one is to decide a minimum height for the global footnote area, like 4
  lines, and so there is a minimal amount of space dedicated to the
  notes, and no balancing at all in this space under a given number of
  lines of notes (or a given total height of notes)
- another is to refine this and do it while not "burning" all the cols
  at once, but it is quite difficult. It would lead to something that
  I'm not sure we can do with TeX, like:
  - one parameter H: minimum note-col height (like 5 lines of notes)
  - if no notes on the page, then no space reserved at all
  - if any notes, a first note-col is created, and the first(s)
    text-cols are shortened (if notes are less than H)
  - if more notes, more note-cols are added, and more text-cols are
    shortened, the rule being that we always keep a height of H for each
    new note-col
  - if enough notes (H times N-notes-cols), then a block balanced

The second way sounds too complex, but the first seems manageable...


[ About middle title ]

> 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.

Yes, sounds more reasonable, and already usefull.

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

Hmmm... I would have it independent of the float system, that is
something like that:
- we insert a "cross title" of height H
- so we reduce the available height for each column of H (+- some glue)
- then run the float placement stuff in a shortened page
- now the floats have their positions
- then check their is room for the title (i.e. top floats to not get so
  low on the page than there are bottom floats above), that would lead
  to an error (or a page break?)
- then place the top floats, balance the top part of the text, place
  the cross title, place the bottom part of the text, place the bottom
  floats

You see the idea? I don't think it is usefull to put a flush point,
except if it eases something in the algorythmic way to handle that...

> 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. 

For me, it is a case that is too complex, it will have limitations that
are almost impossible to explain, so impossible to use in an efficient
way.

Except if you decide to get to a totally different way to approach the
problem, which would be really closer to a visual solution. It would be
something like positionning the inserts on the page, and then floating
the text *around* it, with a column width changing.

Something like that:

tttttttttttttttttttttt   ttttttttttt  TTTTTTTTT
tttttttttttttttttttttt   ttttttttttt  TTTTTTTTT
tttttttttttttttttttttt   ttttttttttt  TTTTTTTTT
tttttttttttttttttttttt   ttttttttttt  TTTTTTTTT
tttttttttttttttttttttt   ttttttttttt  TTTTTTTTT
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
tttttttttttttttttttttt   tttttttttttttttttttttt 
AAAAAAAAA  ttttttttttt   tttttttttttttttttttttt 
AAAAAAAAA  ttttttttttt   tttttttttttttttttttttt 
AAAAAAAAA  ttttttttttt   tttttttttttttttttttttt 
AAAAAAAAA  ttttttttttt   tttttttttttttttttttttt 
AAAAAAAAA  ttttttttttt   tttttttttttttttttttttt 
AAAAAAAAA  ttttttttttt   tttttttttttttttttttttt 
AAAAAAAAA  ttttttttttt   tttttttttttttttttttttt 
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP  tttttttttttt 
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP  tttttttttttt 
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP  tttttttttttt 
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP  tttttttttttt 
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP  tttttttttttt 

That is something which sounds like highly incompatible with TeX as we
know it, and that would lead to horrible problems (equations numbering,
dealing with arrays, and so on). Just think about what would happen to a
longtable combined with tabularx (is that lxtable? can't remember...) in
the part of text which is reduced.

We can try to achieve something a bit more restricted: for each float,
define a kind of "visual size" (instead of compatible areas), and make
the area selected automatically if the float fits inside. Then, a float
can take 1 col in a 2 cols context, and 3 cols in an 8 cols context.

With that kind of thing, it might perhaps be possible to try to have an
output routine changing the numbers of columns at mid of the page...

> 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.

We would need to manage the width as described before, as a
charasteristic of the float itself, and then match that width with the
width of the area.

> 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?

If we deal with the width-float and width-area then there are answers...

> 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.

My guess is that it might be possible to do that, but I don't know if it
is truely useful... The middle title sounds really useful. Changing the
number of columns sounds less usefull in the general case. It might be
of interest to restrict it to cases that we know how to manage.


Regards,

	Benjamin.