11 feb 2008 kl. 09.18 skrev Frank Mittelbach:
> Hi Lars,
>> So what you're saying here is that all \count registers corresponding
>> to float \inserts are set to 0, so that TeX's page breaking algorithm
>> won't take the sizes of these floats into account when choosing a page
> yes, inserts aren't used in LaTeX (other than for keeping registers
> except for footnotes. floats are transparent initially and the
> placement isn't
> done through the insertion mechansim as already Leslie found that this
> flexible enough to account even for common situations.
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).
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?
(I can't see how to do [h] with inserts, but the others seem managable
if [h] is dropped, so I suppose that was the thing.)
>> Hmm... And it's not possible to have TeX run the linear algorithm for
>> each column separately,
Using the TeX page builder ("linear algorithm") it pretty much
pointless if the floats aren't \inserts that the page builder can take
into account anyway, so the issue is probably moot.
>> because upon encountering a multicolumn float
>> in column 3 you'd have to go back and rebreak columns 1 and 2, which
>> might not be possible anymore. Or is it?
> you can't go linearly unless you disallow a lot of useful and common
> - restricting floats to be only visible from the call out not that it
> has to
> be placed strictly after the call-out (e.g., call-out in col 2
> float placed
> in column one or even on the previous page if still visible)
> - spanning columns may go backward, e.g., in a two column layout you
> may want
> to have a spanning 2-column float still allowed on top even if the
> callout is
> on the second column
Both of these are so to say "linear with backtrack" -- when finding a
float that affects column 1, back up and start rebreaking with modified
goal. My line of thought here was mostly "Is this possible without
messing up the page contents?"
> both examples aren't possible with Leslie's 2e algorithm while xor can
>> (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
>> 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...
>> [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
> 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
> "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? 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.)
> Furthermore in TeX things are not that clear cut. rebreaking does
> change the
> vertical flow and you may get different lengths when added together as
> vanishes into the breaks or stuff like widows etc prevent TeX from
> breaking in
> certain points (like the famous example of removing a word from a
> paragraph to
> make it one line longer).
It might still be possible to have combined text height decrease but
actual amount of vertical material used increase if one makes careful
combinations of penalties and large negative amounts of space, but I
don't think the OR can be required to handle such situations sensibly
> So my feeling is that this will still introduce "impossible documents"
> defining rules to break out of them (which may be possible) would be
> diffcult to implement and probably equally difficult to explain.
> which is why for anything changing the space arangement (eg float
> vertical sizes) I'm more and more convinced that it has to affect the
As an algorithm, what I've suggested would be
iteration_count := 0;
directives := empty;
i := i + 1;
<break page (under settings current at page start modified by
directives[i-1]), save as pagetry[i], record sum of column(*)
as pagetotal[i], record directive marks found in vertical material
used as directives[i]>
directives[i] = directives[i-1] (* Main case *) OR
nonmonotonous(pagetotal, ..., pagetotal[i])
IF nonmonotonous(pagetotal, ..., pagetotal[i]) THEN
(*) Or more precisely sum of subcolumn heights, when there are middle