LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sun, 13 Jan 2008 19:41:00 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (85 lines)
I'm having a bit of trouble to find a good way to specify internal or external
page setup control. In LaTeX2e this concept only exists in some rudimentary
form, i.e., it is possible to influence that page style as far as running
headings are concerned by placing a \pagestyle or \thispagestyle command in
the source but that's about all that is available.

Float placement is only controlled via individual float attributes (that is
all pages offer the same areas to put floats in) and other changes to the
page, e.g., one/two column, can only be made (if at all) by forcing a
controlled page break first. 

What I'm looking for for the new output routine is to be able to change, for
example, the area specifications for the current or the following pages. The
tricky part is: how should this be specified and when should it act? 

If it works like \thispagestyle, i.e., is intended to act on the "current"
page then this might result in the following problem: 

    * Some such directive would be picked up when gathering material and would
      change, say, which float areas are allowed on the current page. But then
      adding floats to these areas the point with the directive might get
      pushed out of the current page (since each float takes away space from
      the galley). As a result all the placements done may no longer be
      valid. 

A possible (but probably bad) way out would be the following algorithm:

   1. Do a dry run without floats to find out the maximum text material that
   can go on the page. 
   2. If this material contains such a page setup directive, change the page
   setup to the new one. 
   3. Start doing trial float placements (i.e., add one float after another)
   using the new page setup. 
   4. After each trial check if the point in the galley where the directive
   was found is still on the current page. If not declare that float placement
   invalid. 

Thus this would end up with a page in the new page setup. However, it is most
likely not a good approach at all since, it effectively means that we do not
place floats just because we made a decision to use a new page setup. If we
would have kept the old page setup we might have been able to place many more
waiting floats (and this way pushing the page setup request to the next
page). 

There is another snag with the above algorithm: after having changed to a new
page setup the galley space in the new setup might have changed (if page setup
means more than just float areas, e.g., the vertical size of the columns might
differ or the number of columns on the page might differ). Thus that means
that after the second step the galley size might be smaller or larger thus the
directive might already got pushed out (which would be bad since it means we
have two instable states) or (nearly equally bad) we get more space in the
galley and as a result hit a later directive requiring a different page
setup. 

So what would be the alternatives? Anybody any good suggestions? Here is one:

    * Use the directives to always specify what should happen on the next not
      on the current page. This way we could simply wait until we typeset the
      final page and pick up the directives in the text at that point thus
      knowing exactly what should happen with the next page. 

One problem that I see with this one is that one isn't used to it,
e.g. instead of \chapter{foo} =\thispagestyle{empty}= one would now have to
say something like \nextpagestyle{empty} =\chapter{foo}=. Not being used to
isn't in itself a problem (though it might be one for adoption by the
users). But this also means that such directives can't be easily issues from
within other commands, since in such a case the area of influence is the page
on which the current point will finally end up and not the page after
thereafter. Now with a command that itself starts a new page the command can
push out the directive, then starts the new page, but if the command doesn't
start a new page then directives can't be used. 

Now I don't know how much of a problem this is (if any) but it is something
that needs to be considered as it would be a restriction if this approach is
used. 

Any other suggestions how one could conceptually handle page control?

cheers
frank

ps if you read down to here you will have noticed that this only dicusses
internal page setup control not external ones, but the message was already too
long and both parts need solving

ATOM RSS1 RSS2