## 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 >>]

 Subject: Re: journal macros (not front matter) From: Phillip Helbig <[log in to unmask]> Reply To: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Fri, 31 Oct 1997 07:44:21 GMT Content-Type: text/plain Parts/Attachments: text/plain (72 lines)
```> 1. BibTeX: yes, there should be an officially approved bst file for each
>    journal. BibTeX does not have to be obligatory, but it should
>    certainly be available. With my makebst (aka custom-bib, merlin,
>    genbst) generating such files is greatly simplified.

My thoughts exactly.  Distribute the .bst with the .cls.  Also, one
should be able to use the \cite-like commands of natbib, rather than
being REQUIRED to use some other scheme.  Depending on how the files are
processed, one might can get away with this even if it is not officially
sanctioned.  Definitely one should explicitly allow natbib.  Also good
would be for the .bst files to conform to the native natbib style.

> 2. Most journal style files (few issue classes) do include extra features
>    for handling tables, figure captions, references, sublabelling
>    equations. Much of this can be handled by existing packages, such as
>    my natbib.

Hmmm...how does natbib come into this?  Sometimes the caption should
come before the table, sometimes after---one has to code presentation,
not content.  It's things like this I was thinking of.  How can natbib
(in its present form) do this?

>    It would therefore be better to recommend the standard
>    packages that one should  be able to use, such as the tools collection
>    and amsmath. That is,  a paper using the model journal class could
>    include all these packages  without having to submit them separately
>    to the journal; he can assume they will be at any installation that
>    contains journal.cls.

Definitely.  Some `core subset' of LaTeX!?!

> 3. Abbreviations and spelling should not be accommodated in any such
>    packages. The author can provide this himself.

If they are available (as part of a .cls or in some other way) one
official source a) keeps people from reinventing the wheel and b) avoids
conflicts between an authors own macros and those used by a journal.
(The more of my own macros I have to write, the more potential for
conflict with names somewhere else, in the .cls or wherever.  This can
be avoided by stuff like \helbigetal instead of \etal but makes for too
much typing and too little readability.

> 4. The journals I have written classes for want a manuscript first with
>    the figure captions and tables all at the end, not included within the
>    text. This is anarchistic today. However, I have a package figcaps
>    that  allows this. Either the figures appear as normal in the text, or
>    the captions (and optionally the figures themselves) and tables are
>    written to  separate files to be reread at the end. I have not made
>    this package  public, but parts of it are available inside my class
>    files.
>
>    I use this as an example of some very complex things that some
>    journals require. My suggestion for journal.cls would be to FORGET IT.
>    A draft or  manuscript option should be available (for single column,
>    double spacing) but such juggling of figures and tables should be left
>    out. Let the  figures and tables appear in the manuscript text too. It
>    is only out of historical reasons that these are to be listed at the
>    end, from the bad old typewriter days.

A very important point.  My thoughts exactly.  The goal should not be
merely to standardise coding for existing practice but, since most
journals will have to rewrite their stuff for 2e anyway, make sure that
excess baggage which is no longer justified is done away with.

--