LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
David Carlisle <[log in to unmask]>
Date:
Fri, 3 Oct 1997 19:23:39 +0100
In-Reply-To:
<[log in to unmask]> (message from Phillip Helbig on Thu, 2 Oct 1997 08:47:59 GMT)
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (81 lines)
What is the main purpose of a standard markup convention for journal
articles?

* To allow a single generic `preprint class' to be used for authors
  for multiple journals, with the `production class' for a particular
  journal being used just in the final stages, perhaps in house after
  the author submission?

* To allow transfer of articles from one journal class to another?

* To give a more or less loose set of conventions so that authors are
  not `surprised' by the submission requirements of any particular
  journal, even if certain differences in markup are required for each
  journal?


I'll give a couple off examples of the kind of issue that I have in
mind when asking the above questions.

Some journals give full postal addresses for each author.
Some just give an `affiliation' for each author and highlight one
`corresponding author' for whom full address is given.

For the first type of Journal one might expect some kind of syntax
like

\author{...}
\address{...}
\author{...}
\address{...}
\author{...}
\address{...}
(with suitable shortcuts to allow shared addresses to be only
specified once, and optional arguments of various sorts)

For the second type one might expect

\author{...}                              \author{...}
\affiliation{...}                         \affiliation{...}
\author{...}                or perhaps    \correspondingauthor{...}
\affiliation{...}                         \affiliation{...}
\correspondingaddress{...}                \address{...}
\author{...}                              \author{...}
\affiliation{...}                         \affiliation{...}

or some other markup scheme. The question is, does it make sense to
try to have one preprint class that covers both schemes. If such a
class is to guarantee that documents can be run without error on
either production class, then it seems that authors will be asked to
provide lots of `redundant' information such as full address and
affiliation for each author, even though a typical class will only use
one or the other.

This may seem like a rather trivial distinction, but several such
small differences soon combine to mean that either your `generic
front matter code' becomes quite complicated, or you end up with
several class files which are similar in construction but strictly
incompatible.

For production use it is essential that any preprint style that
authors used is more or less guaranteed to produce manuscripts that
run with the production class (that may use commercial fonts or differ
in other ways from a public author submission class, but should take
as far as possible exactly the same manuscript markup).

Another problem is author order. Some Journals (see for example the
Kluwer class files) order all authors from the same institution
together. Perhaps more common is a single list of authors with
somekind of footnote marker system to identify the affiliation of each
author. The AMS have a kind of hybrid system where the frontmatter
author list is a single list, but at the end a list of full address
is cross referenced back to the authors.  Does it make sense to try
to capture all these systems with a standard markup scheme. Especially
as author order in some disciplines involves political implications of
`seniority' (In others, authors are always listed alphabetically
irrespective of seniority).

Just questions this message, no answers.

David

ATOM RSS1 RSS2