> 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 together)
except for footnotes. floats are transparent initially and the placement isn't
done through the insertion mechansim as already Leslie found that this isn't
flexible enough to account even for common situations.
> > So if the "pagestyle" can control the float placement then there is a
> > conflict. The problem would only go away if the material from the mark
> > is
> > supposed to define the layout/pagestyle of the "next page, because
> > then we can
> > simply wait until we have determined the final galley cut and then
> > evaluate
> > the marks from that cut to be used on the next page.
> Although that is, at least for some modifications of pagestyle (e.g.
> changes to happen at the page of a heading, being caused by the
> \section or the like command), not a natural restriction.
yes that is the catch. for some types of directives such changes would apply
much more naturally to the "current" page. Perhaps, in the end one needs both
both and educate the user where to place them (not happy about that though).
> > > [monotonic dependence]
> > >
> > well perhaps I misread the algorithm, but I guess it can't be used if
> > the
> > basical float placement happens the way it is described above. And I
> > think it
> > has to happen in this way to be able to do better than a simple linear
> > algorithm as LaTeX currently uses (that one works well enough for
> > single
> > column pages but already with two columns it doesn't really do).
> Hmm... And it's not possible to have TeX run the linear algorithm for
> each column separately, 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 examples aren't possible with Leslie's 2e algorithm while xor can handle
> (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.
> > but if you do that you can't impose a monotonicity rule in this way (i
> > think)
> > as that would still produce backward effects, i.e., assume you have
> > page 3 with 4 floats
> > page 4 with 2 floats
> > you add a directive on page four that says no floats on this page
> > (i.e., the
> > intention to push the 2 floats to page 5.
> > now when the doc is compiled the directive will be seen first time on
> > page 3
> > (when it is cut without floats), so ...
> ... a consistent float allocation is made --- the text around the
> directive to suppress floats (e.g. a section heading) ends up on page
> 3, and on that page there are no floats --- although the change caused
> by adding the directive is probably not what was expected. So let's try
> to do better.
> What I was thinking about for step 1 was not just the result of the TeX
> page builder, but rather the result after placing floats etc. (It's no
> big difference whether the main vertical list was cut by the page
> builder or \box255 is cut by an explicit \vsplit, except that in the
> latter case one has to look at \splitbotmark instead of \botmark.) So
> in your example:
> * Step 1 builds page 3 with 2 floats. Step 2 checks if there was some
> setting change, but since that mark fell after the split, no setting
> change is detected. Page 3 is shipped out as built in step 1.
> * Step 1 then builds page 4 with 4 floats. Step 2 checks if there was
> some setting change, and since there was (floats forbidden), page 4 is
> rebuilt without floats. At step 3 it is rechecked whether the
> reconstruction of page 4 introduced further setting changes, but since
> there were none, page 4 as built in step 2 is shipped out.
> 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.
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 space
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).
So my feeling is that this will still introduce "impossible documents" and
defining rules to break out of them (which may be possible) would be really
diffcult to implement and probably equally difficult to explain.
which is why for anything changing the space arangement (eg float placement
vertical sizes) I'm more and more convinced that it has to affect the "next"
> Monotonicity only comes into play if there is the further complication
> that there on page 5 (as it would have been without the "no floats"
> directive on page 4) was a counter-directive that floats are fine --- a
> directive which Step 2 would move to page 4.
yes and then there is that :-)
> >> PS: I wouldn't mind getting a response to the xparse/xdoc stuff too.
> > well let's see, how many more days do I have before I'm slower than you
> > replying to my post? :-)
> Well, we're not the only ones on this list, are we? ;-) Anyway, I just
> didn't want the issue to be forgotten in all the OR excitement.
hope not, but who knows? this is a slow list as we know (and all those
questions aren't easy ... so there is still help