Message-Id: <199402141837.AA00960@mail.cs.tu-berlin.de>
Reply-To: Mailing list for the LaTeX3 project <LATEX-L@DHDURZ1.BITNET>
In-Reply-To:  <01H8VG57GH6A9OEC0Y@MATH.AMS.ORG>
Date:         Mon, 14 Feb 1994 11:41:16 -0500
From: bbeeton <BNB@MATH.AMS.ORG>
Sender: Mailing list for the LaTeX3 project <LATEX-L@DHDURZ1.BITNET>
To: Multiple recipients of list LATEX-L <LATEX-L@DHDURZ1.BITNET>
Subject:      Re: collective documents [was exam papers]
Status: R

sebastian asks some questions about whether a "collective document"
would really need new faciliities, as opposed to simply a new
document class.

regarding whether our hacked-together tugboat "collection" option
will or won't work with latex2e remains to be seen; it might work
with compatibility mode, but i don't really want that -- when the
switch is made to latex2e, i want it to be a complete switch so as
not to be using any more versions of the styles than absolutely
necessary; gets too confusing otherwise.

the kinds of things that are implemented are (as in sebastian's
style/class) per-paper bibliographies, contents, lists of tables and
figures -- i.e., separate .aux and .lo* files (and i would love to
have the ability to use \nofiles for a particular article if it's
appropriate, but right now the reconstruction of these auxiliary
files is so delicate -- sometimes they simply don't get rewritten
when i'm in "collective" operation -- that i don't dare chance it).

for proofing individual items, they are most easily processed one at
a time, so the \documentstyle line (or its new equivalent) will be
present in every article file.  when in "collection" mode, this must
be read in and checked to see if any new options must be input; if
any options have already been input, don't repeat them (double input
is sometimes pretty lethal, or at least "the results are undefined").

at \begin{document} various things need to get reset -- section
numbers, for example, and the elements that make up the front matter
(don't want to use the net address of the previous paper's author
if the author of the current paper has none).

it's necessary to *not* stop processing at \end{document} but to check
whether there's anything more; so there needs to be a "final" \end .
\however, any paper-specific definitions and parameter settings should
be killed to keep them from affecting later papers.

compiling a "publication" table of contents would require an .aux
file at the collective level -- so two .aux files could be open at
once.

posit a two-column publication in which articles have one-column
top matter, but start on a page that has already begun if there's
enough room.  then \end{document} must balance the columns, and
\begin{document} must reset to one-column a suitable distance down
the page.

probably some more bits that i've forgotten at the moment.
i guess that none of this is really "new", but especially the
encapsulation and reinitialization, and the extra file handling
are sufficiently nasty that it would be helpful to have a
standard way of handling them.
                                                -- bb