LATEX-L Archives

Mailing list for the LaTeX3 project


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
Michael John Downes <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Mon, 6 Oct 1997 13:10:08 -0400
text/plain (65 lines)
> You can more or less get (1) by just having the master class redefine
> \documentclass to do nothing, re-enable \usepackage for use by the
> articles, and just set up whatever typographic details are needed to
> handle the `front matter' of the individual articles when considered
> as sections in the larger work.

If you put each article in a group the save stack can take a serious
hit. This used to cause trouble for us on occasion when doing the book
reviews section in one of our journals. Partial blame, however, was
eventually laid to some unnecessary carelessness with the save stack in
certain macros. And as the capacity of TeX systems continues to grow,
the save stack may practically speaking cease to be a concern.

> There are problems when you start to consider packages used by the
> different articles clashing, and issues relating to avoiding namespace
> clashes with \label etc, but they are not insurmountable (probably:-).

Nevertheless imho they are troublesome enough that a better approach
would be to set up a system of communicating between the different parts
through an auxiliary file. At the end of the first part, measure the
actual depth of the last page and pass it to the next article, along
with the current page number and whatever else is needed. This means
using an OS-specific script to process the whole collection instead of a
single LaTeX run, but you avoid so many other problems that it's worth
it. Ad hoc customization for individual parts done by different authors,
such as


will make trouble even if each article is enclosed in its own group and
there are many ways for this kind of trouble to come up.

> 2) A generalised \include/\includeonly system that does not force the
>    \clearpage as in the current implementation.

> (2) is harder and perhaps not even possible in full generality,
> depending on what you want to specify happens to floats, whether or
> not they are allowed to float out of or into regions of the document
> that are potentially not included.

Understood; but isn't it true that the floats will get printed in any
case (in the next really included portion, or at \end{document})? The
worst scenario that I can see is some floats from section 3 get printed
in section 5 if the user didn't happen to include section 4 on this
particular LaTeX run. Will this happen often enough in practice to
really be a problem? And if \include didn't include a \clearpage it
would be easy enough to add one in front of the \include statements that
needed it, whereas taking it out isn't so easy.

I suppose this idea has been suggested before?:

At an \include boundary, take all the floats in \@toplist, \@botlist,
\@deferlist and set them at the end of the preceding text as `here!'
floats, with enough stretch in the inter-float space to get through any
page-breaking problems.

Isn't the main unsolved problem for \include making sure that non-immediate
\write's go to the proper .aux file?

Michael Downes