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