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]>
Mon, 26 Nov 2007 15:01:30 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain; charset=us-ascii
Frank Mittelbach <[log in to unmask]>
text/plain (115 lines)
Hi Ulrich,

 > in my opinion middle floats always float ;-) "Middle" floats could float
 > from the column top to the column bottom; if there's room left before or
 > after one should apply the standard orphan/widow rules (but if a
 > designer wants a fixed middle placement one should have an option like
 > the absolute placement for top and bottom position). They can be of
 > different size and therefore I don't think there is a algorithm that
 > will satisfy all possible combinations automatically. As said there
 > should be a possibility for a fixed position on the page, e.g., on top
 > or bottom or both (wether in single column mode or more) and maybe even
 > in combination with column number, e.g., left column, middle, right (or
 > one, two, three, ...) -- In this case I would like to have an option to
 > place some text at the original position when the float has been moved.

I didn't meant to discuss "here" floats as in LaTeX2e which indeed nearly
always float :-) ---and if they do, your idea of allowing some alternate text
to appear is a good one.

I was/am after a design that supports one or more float area that is not on
the top/bottom of the page but somewhere within the page, i.e., a place or
more where floats float into, for example in a design where part of the margin
is being used for floats

  ttt  ttt
  ttt  ttt
AAAAA  ttt
AAAAA  ttt
AAAAA  ttt
  ttt  ttt
  ttt  ttt
  ttt  ttt

you are quite right that no algorithm can satisfy everything, but the question
is what can be done algorithmically that satisfies at least something?

 > > To state the problem differently, what should be the amount of freedom
 > > available to the designer (through the algorithm), and what would be a
 > good
 > > way to express it?
 > No restrictions!

that algorithm wouldn't work and wouldn't place anything. remember this is not
trying to build InDesign or Quark inside LaTeX this is about autmatically
placing floats and any such algorithm needs rules of some kind.

take the 2.09 algorithm, that one basically had the following rules:

 - place as many floats as possible (and as early as possible) that are not in
   conflict with any other rule

 - for unplaced floats try to produce float pages (sub of previous rule)

 - restrict placement through

    - number of floats per page
    - number of floats per float area
    - size of float area
    - remaining size of text

 - keep order of floats within type

 - require that float is placed after callout or in same column on top

 - honor area placement options on individual float (and have defaults per

2e extended that minimally by supporting overwrite on a per float basis (!
syntax) and supporting strict-after-callout through flafter

the xor implementation has already changed that drastically by supporting

 - spanning float areas across multiple columns (in a multi-column design with
   cols >=2), 

 - relations betwen float areas, e.g., if a float is place in one area, other
   areas may not be allowed to receive floats

 - more flexibility in specifying float callout relation

 > > Questions:
 > > 
 > >     * What kind of other specs can you think of?
 > for fixed positions:
 > [col=1, pos=<t,c,b,>, col=2, pos=<t,c,b,>, col=3, pos=<t,c,b,>, ...] or
 > even
 > [col=1, pos=absolute(10cm), ...], [col=1, pos=absolute(10\baselineskip),
 > ...], or [col=1, pos=<baseline|top|bottom>(10\baselineskip), ...]  

If I understand this correctly than those are suggestions more in line of
spcifying layout on a per page basis, e.g. place this float in that position
on this page ... That is a different beast altogether and in fact xor will
have this ability too (though right now it is broken)

But what I'm after is this:

 - assuming you have the possibility of specifying one (or more?) middle areas
   for floats by which I mean an area to receieve float(s) where above and
   below there is still text

 - when what kind of algorithmic specifications and rules should govern this
   area and how it is filled?