Received: by nummer-3.proteosys id <01C19443.41ADFDEC@nummer-3.proteosys>; Thu, 3 Jan 2002 11:41:52 +0100 MIME-Version: 1.0 x-vm-v5-data: ([nil nil nil nil nil nil nil t nil][nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.41ADFDEC" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: MULTI-AUTHOR WORKS Date: Tue, 23 Apr 1991 16:34:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "MITTELBACH FRANK" Sender: "LaTeX-L Mailing list" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 329 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.41ADFDEC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I just finished an issue of some internal newletter printed at the EDS which has the problem of being a typical multi-author work. There is the overall stuff like table of contents as well as individual articles >from different authors. There is also some `backmatter' material like a glossary which is compiled by the editor. The individual articles are of (at the moment) two different types namely `contributions' and `notices' in our internal jargon. Guided by production experiences the style for this newsletter was set up in a way that individual articles are prepared in the standard article style syntax. Reasons: 1) The individual author is able to typeset his/her article with any style (house or otherwise) that implements `article makeup'. He is not forced to know about special names and functions but can view his article in the way the document is natural to him, namely as an individual article which is so far not necessarily part of some larger structure. 2) The only thing we request is to separate the article from the driver file to keep unnecessary editorial work to a minimum. That is, we suggest to use \documentstyle{article} \begin{document} \input{myarticle} \end{document} The file myarticle then contains the real article with definitions and all, and can therefore be pasted directly into other structures. 3) The style itself contains environments like `notice' and `contribution' that redefines \author \maketitle and the like to produce a desired layout. Some of these commands are ignored depending on the kind of article. This means that the editor is free to turn any article into a contribution or a notice or ... without changing the source. This concept was considered important as it speeds up processing time. Changes to articles are done only for the sake of editorial corrections (typos, grammar, contents) but are not necessary when simply fitting the article into the larger context of the newsletter. 4) On the newletter surface, commands like \tableofcontents are available but produce information assembled from \maketitle etc of individual contributions and notices. 5) We think of adding a section `letters to the editor' which will certainly be implemented as some letter environment that accepts standard letter GML but turns this into suitable output for the newletter. Problems: As mentioned by several people on the list, the front matter declarations in LaTeX are clearly not sufficiant. In fact they are nearly non existant. This means that we currently have to help ourselfs by abusing fields like \date which then in turn produce a problem in such a concept. But this only means that we have to define a proper front matter concept that will allow to specify necessary information in a natural manner. I don't consider the question of compatibility here a difficult one since the current LaTeX provides nearly nothing which can be easily provided in a `compatibility style' or changed in an older source. The use of identical names(e.g. \tableofcontents) for slightly different things might be considered confusing but this is something I think is in practice perhaps even more natural then inventing new names (like \volumetoc \issuetoc ...) that are actually all commands for the same concept only that the special outcome is determined by the position in the document. Frank Mittelbach ------_=_NextPart_001_01C19443.41ADFDEC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MULTI-AUTHOR WORKS

I just finished an issue of some internal newletter = printed at the EDS
which has the problem of being a typical multi-author = work. There is
the overall stuff like table of contents as well as = individual articles
>from different authors. There is also some = `backmatter' material
like a glossary which is compiled by the = editor.
The individual articles are of (at the moment) two = different types
namely `contributions' and `notices' in our internal = jargon.

Guided by production experiences the style for this = newsletter
was set up in a way that individual articles are = prepared in
the standard article style syntax.

Reasons:

   1) The individual author is able to = typeset his/her article
      with any style (house = or otherwise) that implements `article
      makeup'. He is not = forced to know about special names and
      functions but can view = his article in the way the document is
      natural to him, namely = as an individual article which is so far
      not necessarily part = of some larger structure.

   2) The only thing we request is to = separate the article from
      the driver file to = keep unnecessary editorial work to a minimum.
      That is, we suggest to = use

       = \documentstyle{article}

       = \begin{document}
         = \input{myarticle}
       = \end{document}

      The file myarticle then = contains the real article with
      definitions and all, = and can therefore be pasted directly into
      other = structures.

   3) The style itself contains environments = like `notice' and
      `contribution' that = redefines \author \maketitle and the like
      to produce a desired = layout. Some of these commands are ignored
      depending on the kind = of article. This means that the editor is
      free to turn any = article into a contribution or a notice or ...
      without changing the = source.
      This concept was = considered important as it speeds up processing
      time. Changes to = articles are done only for the sake of
      editorial corrections = (typos, grammar, contents) but are not
      necessary when simply = fitting the article into the larger
      context of the = newsletter.

   4) On the newletter surface, commands = like \tableofcontents
      are available but = produce information assembled from \maketitle
      etc of individual = contributions and notices.

   5) We think of adding a section `letters = to the editor' which will
      certainly be = implemented as some letter environment that accepts
      standard letter GML = but turns this into suitable output for the
      newletter.


Problems:

  As mentioned by several people on the list, the = front matter
  declarations in LaTeX are clearly not = sufficiant. In fact they
  are nearly non existant. This means that we = currently have to
  help ourselfs by abusing fields like \date = which then in turn
  produce a problem in such a concept.
  But this only means that we have to define a = proper front matter
  concept that will allow to specify necessary = information in a
  natural manner.

  I don't consider the question of compatibility = here a difficult one
  since the current LaTeX provides nearly = nothing which can be easily
  provided in a `compatibility style' or changed = in an older source.

  The use of identical names(e.g. = \tableofcontents) for slightly
  different things might be considered confusing = but this is something
  I think is in practice perhaps even more = natural then inventing new
  names (like \volumetoc \issuetoc ...) that are = actually all commands
  for the same concept only that the special = outcome is determined by
  the position in the document.

Frank Mittelbach

------_=_NextPart_001_01C19443.41ADFDEC--