Hi Lars,

 > Indeed, the LaTeX2e floats doesn't use \inserts, but use magical 
 > penalties to call the OR; fancy I didn't notice that before ... (but 
 > then ltfloat.dtx is still very Lamporty in its documentation).

well not surprising it is still largely Lamport. for 2e we never touched the
float handling a lot.  --- you understand that all the questions I asked are
not with respect to "improvements" of the 2e way of handling things but with
respect to a totally different approach as implemented in the experimental xor
package which is based on expl3 language?

 > Was the problem that \insert requires floats to fall into disjoint 
 > classes (if [t] and [b] are separate \insert queues, then where does a 
 > [tb] float go)? Or was the problem that \inserts could not appear on 
 > the page before their position in the document? Or was it [h] floats 
 > that made \inserts insufficient?

several issues really with inserts. a) as you said you can't properly support
float classes (allowing for independed sequences of float placement per class)
then b) you have difficulties to control your floats as they end up as in a
single insertion box, so taking some of them out for reposition etc is a
nightmare (and if you do and afterwards have to reposition using different
methods, why use inserts in the first place)? c) there are no decent
interaction possibilities, e.g., changing behavior ofthe algorithm like
flushing floats (\clearpage is a primitive way of that in 2e) or things like
deciding that a bottom float should only happen if the page doesn't also
contain footnotes, etc.

it is possible with enough stamina to do those things even if you use inserts
eg duplicate every region for every float class to keep things separate but
this is hard and you run in additional difficulties as eventually you need to
combine things and you have to keep track of whether or not a region actually
has already received a float and then prevent a float of a different class
into the same region to add extra space to the page etc etc... again one can
think of ways to do this but ... in summary \inserts have been developed to
support footnotes (for which they work reasonable enough) and everything else
was an afterthought trying to apply the methods and for documents with minimal
requirements for floats that works well enough but beyond that ...


 > >> (The OR is an area I haven't
 > >> fiddled around with much; I imagine there might be problems with
 > >> material and/or information being irreversibly lost when one leaves 
 > >> the
 > >> OR.) Could of course be that it's still not good enough.
 > 
 > If I recall it correctly, there are some things TeX throws away 
 > irreversibly, but eTeX added some primitive (<something>discards, I 
 > think) that lets you rebreak vertical material without loss...

you comment on yourself here :-) but yes you are right there are ways to
rebreak without loss but the eTeX discards isn't really the best way to do
that (imho). in any way, that part is nicely working in xor


 > 
 > >> [directive example]
 > >>
 > >> This was the expected behaviour, was it not?
 > >
 > > well, yes, maybe. but I don't think it will work either. or rather it 
 > > only
 > > works in the above example because we know that the directive is 
 > > reducing the
 > > "non-text" space therefore staying within our monotonic dependencey 
 > > rule, ie
 > > the directive says "less floats please". If it on the other hand would 
 > > say
 > > "more floats please" it might push the directive out to the next page.
 > 
 > Yes, categorising directives as "increasing" or "decreasing" is 
 > certainly nontrivial, but you began by asking for *principles* for 
 > setup control, did you not? 

yes I did and honestly I fid this dicussion very useful

 > Monotonicity is a principle (the 
 > implementation of which may prove nontrivial). However, one idea could 
 > be to do the full rebreak of the page, and then compute the combined 
 > height to which the columns were split; require this quantity to be a 
 > monotonous function of rebreak count. (See pseudocode below.)

have to study your pseudocode in more detail later tonight and think about
it. but one question generally: do you  think its behavior can be
explained/comprehended without putting the algorithm next to you and think
very hard about what it does to your intput?

or say it differently: what I was asking and still struggling with is an input
method of specifyin page layout directives so that 

 - taking version A of a typeset document I have a clue where and how to
   place some directive to achieve a desired change?

 - taking version B of a document (the one with the directive in) both a
   source and typeset output and it becomes immediately (some sort of
   immediate anyway :-) understandable why the source compiles in this
   manner?

I still haven't been able to convince myself that this is possible unless the
directive acts on the "next" page or the directive is one that only
reorganizes the page content but not add or substract from it (in which case
it could work on the "current" page). So my question is really to describe an
input method that has this property ob being understandable.

here is an example why i think this is so difficult:

  The AAA, BBB, CCC are floats and (A) and so on are callouts. Furthermore the
design only allows 2 floats per page. [D1] is a place where we want to place a
directive because with the default layout we end up with tree pages as this:


  AAAAAAAAA     CCCCCCCCC     xxxxxx
  AAAAAAAAA     CCCCCCCCC   
                CCCCCCCCC   
  xx(A)x(B)
  xxxx(C)xx     xxxxxxxxx
  xxxxx[D1]     xxxxxxxxx
    xxxxxxx       xxxxxxx
  xxxxxxxxx     xxxxxxxxx
                xxxxxxxxx
  BBBBBBBBB       xxxxxxx
  BBBBBBBBB     xxxxxxxxx
  BBBBBBBBB     xxxxxxxxx

so we put in [D1] the directive that says "allow 3 floats on current page". As
a result we end up with 2 pages like this.

  AAAAAAAAA     xxxxx[D1]
  AAAAAAAAA       xxxxxxx 
  BBBBBBBBB     xxxxxxxxx  
  BBBBBBBBB     xxxx[D2]x
  BBBBBBBBB       xxxxxxx   
                xxxx[D3]x
  xx(A)x(B)     xxxxxxxxx
  xxxx(C)xx       xxxxxxx
                xxxxxxxxx
  CCCCCCCCC     xxxxxxxxx
  CCCCCCCCC     xxxxxx
  CCCCCCCCC

Now the problem is the directive is now on the next page so its semantics need
to be slightly adjusted from what we thought it was or we get a flipflop
layout: something like

  D1 = allow 3 floats on the page this directive would fall if it wouldn't
       been active

now while this may algorithmically sound, I think it would be very hard  to
comprehend what the hell is happening if I give you the final document because
it is hard to image where D1 would end up if not active and worse
understanding how different directives interact with each other, e.g., if
there is also a need to manipulate the second page in some manner, why is
[D2] or [D3] acting on the second page but [D1] on the first ...

As i said from an algorithmic perspective this is all explainable behavior but
just looking at source and result ... urg, don't you agree?


of course there is the possibilitiy to use the first definition of the
directive, accept that flipflops are possible and then simply detect them (and
if they happen not use the directive but flag an error.

would that be an acceptable approach? perhaps, ...

 - it would clearly tell the user that he/she had placed the directive in a
   place that doesn't stay on "current" page if the directive is put in force,
   so hey ... move this thing

 - but at least one downside is that this would happen with a fairly positive
   propability and so people would need to do a lot of good guessing where
   things have to be placed (this is an issue for multicolumn layouts not with
   a good number of floats not so much with single column once like in the
   above example)

... this is why life in 2e and 2.09 was so nice and easy, directives either
changed only look and feel (like placement of page number but not galley
content or they simply forced a new page first like number of column changes
or \clearpage ...

'night
frank