## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 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 >>]

10 feb 2008 kl. 16.37 skrev Frank Mittelbach:
> Lars,
>
>> Which brings me back to the question about using \marks. If a mark
>> changing the \pagestyle (assuming here metrics stay the same) is given
>> in material ending up on page 5, there is no way that it can affect
>> what happens on page 4, even if it was put on the main vertical list
>> before page 4 was shipped out. So far so good, eh?
>
> well not quite I think (though that has nothing to do with your
> suggestion to
> use marks). The problem is the way the new output routine does its
> float
> placement: it works basically by collecting enough material for a page
> with no
> floats (plus some safety extra) and then starts adding floats one at a
> time. That means that one the first trial cut (no floats) it will pick
> up some
> pagestyle that on a later trial may no longer be present.

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
break?

> 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.

>> The other problem is nonmonotonic dependence on page breaks chosen, as
>> illustrated by the roman numeral problem. One way to break an infinite
>> loop of rebreaks would be to impose a monotonicity rule on the
>> settings. Basically there is the main body of text and floating
>> material competeing for area on the page being built, right? An
>> increasing text rule could then mean that settings are not taken into
>> account if they decrease the amount of body text being included, i.e.,
>> if we have the following sequence of events:
>>    1. A page break is chosen with default settings.
>>    2. Within this page material is then a change of settings which
>> would
>>       increase the part of the page occupied by body text, so the page
>>       break is recalculated with the new settings.
>>    3. Within the additional material put on the page, there is another
>>       change of settings which would reduce the body text amount on
>>       the page. This is however not taken into account, as it would
>>       violate monotonicity; the page break is not recalculated.
>> It's possible that decreasing text is more often useful than
>> increasing
>> text. Maybe it should even be decided on a case-by-case basis: if for
>> breaking page N there is an adjustment which increases (decreases) the
>> text part of the page, then further setting changes may not decrease
>> (increase) the text part of the page.
>
> 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? (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
>
> (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

* 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?

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.

> I think I can perhaps come up with a few more but that may need a
> little time
> actually I'm down with some flu and shouldn't sit in front of the
> computer
> anyway
>
>> 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.

Lars Hellström