LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
David Carlisle <[log in to unmask]>
Wed, 8 Mar 2000 13:23:00 GMT
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain (42 lines)
> What users expect is something like an exponentially weighted
> placement algorithm:

There is a possibility in the new algorithm to have something
like this, as there is a possibility (documented but not currently
implemented) to store the page on which the float callout was typeset
as part of the float data structure (once that page is known)
Then there would be a possibility of using the difference between that
page and the current page as part of the float placement algorithm.

Fixed rules like the one you cited, are fairly easy. That said deferred
floats must always appear on the next page (which basically means you
have to ignore all the float parameters and constraints and just get get
the float out, like a current \clearpage but allowing use of top area as

But it isn't clear how one could `gradually' alter the float placement
parameters to encourage floats to appear `near' their callout but in
`reasonable' positions. That is not to say it can't be done, but
suggestions welcome. ie given something like the current
\textpagefraction, \topnumber etc, how would you modify the algorithm
given additional information the number of pages the current float has
been deferred. Or more generally what parameters woulD you use _instead_
of \textpagefraction, \topnumber ...

>  usually 10% to 60% of \textheight.

ie too large to go in top, too small to make a float page on their own,
ideal material for taking to the end of the document, given the default
latex parameter settings!



> t doesn't satisfy this requirement, because it could (sensibly) place
> the float on the current page, before the reference to it.

It would if you add flafter package (but that isn't too relevant to the
new algorithm)