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

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

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

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

> What is best to do probably depends on *why* output routine setting
> changes are made. Does anyone have a list of scenarios that might be
> discussed? Some I can think of are:
>
>   * We're entering a new section of the document, so it would be good if
> float
>     placement could be a bit more liberal so that we got them out of the
> way.
>
>   * We're making a special kind of page (e.g. chapter opening) and don't
>     want any floats to go here.
>
>   * We're entering a section of the document where the basic page layout
>     is different (e.g. includes page headers because we're in the index).

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