LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

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

Print Reply
Marcel Oliver <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Sun, 15 Nov 1998 00:02:43 +0100
text/plain (219 lines)
I'd like to refocus the discussion to what I think is one the key
issues: author-author and author-publisher communication.

First, I think that the distribution problem should not be a concern
of LaTeX development. TeX/LaTeX will increasingly be distributed
through distributions like teTeX as opposed to users downloading the
core packages individually; those distributions will define which
packages are available to the average users, as well as provide update
facilities which will depend heavily on the upgrade procedures which
are common to the target platform (e.g. rpm). While I agree that it is
extremely important to have well-maintained distributions, this issue
is external to LaTeX.

So the question remains what packages as well as coding conventions (!)
should I use if my goal is to maximize the exchangeablility of my
documents.  This includes:

- The ability to easily recycle snippets of my documents by myself as
  well as current or future collaborators.

- Increase the chance that my documents will run on future versions of

- Make it easy for my co-authors not only to run my documents, but
  also to change them or add their contributions without creating a
  big mess.

- Be sure that a document that I prepare will be accepted by a
  reasonable publisher in my field for direct electronic submission,
  and will not be retyped or otherwise mangled in unpredictable ways.

- Allow my documents to be translated into other formats (HTML, XML or
  whatever else may come along) with the least amount of losses.

This is a whole different question from what should be distributed as
LaTeX:  There are many things that I would like to do in certain types
of documents (think of letter classes) where the above issues are not
really first priority.

However, one of the main advantages of LaTeX, when properly used and
maybe improved, is that it has the potential to achieve achieve very
good document exchangeablility as defined above.

David Carlisle wrote:
> > far as the practical problems go, is problem number one
> Documented, and agreed. If you (for example:-) were to volunteer to
> draw up a list of `must have' packages, and wrap them all in some
> consistent installation and documentation format, and document how this
> is the minimum required latex installation for document interchange.

I'll try to start this list from my point of view, I'd be willing to
collect everybody's answer to the question "In my professional
writing, which tools are indispensable, and which ones do I prefer to
use when alternatives are available". Please send them by private mail
(this list is getting too noisy), maybe I'll also ask on c.t.t.

I'd also like to know from the publishers on this list what they think
about these issues.

For Mathematics, at least the areas that I work in, the needs are
rather modest:

- The AMS packages are absolutely indispensable, as is the AMS font

Comments: this may seem rather trivial, but other than the AMS I
haven't seen a publisher who didn't screw up on vanilla amsmath stuff
(this includes Elsevier a couple of years ago, I suspect this may have
improved by now) and even this year one publisher (not the big one
with the yellow books) seemed to use the 2.09 based version, with easy
to imagine problems that had to be corrected in the page proofs. SIAM
implements functionality like subequations in a slightly different way
in their author classes (apart from the issue that such stuff IMHO
shouldn't really go into a class file), and I have seen many things
which should be really standard but which are not (theorems, for
example). In many cases the core functionality of LaTeX is either
broken (equarray) or insufficient (theorems), so that the extension
packages are needed for basically ANY work in the field. Thus, the
basic LaTeX provisions should be removed from all documentation
(personally I also think that stuff like equarray should produce a
warning "You are using a broken command").

Summary: Here I think it's mainly a documentation problem which
prevents that very necessary and useful packages are not always used.

- graphics/graphicx for inclusion of illustration.

- some good bibliography package (natbib)?

(I have to admit that I never got round to starting a bibliography
database, and I haven't missed it much. For some people this seems to
be quite important. Also, I guess I would really start using natbib,
for example, if publishers were to tell me "if you start using this
very good bibliography package, we won't screw up your references any
longer," in other words, if natbib would be elevated to be a standard
publishing tool.)

- Some frontmatter package which is at least equivalent to the
  functionality that the AMS classes provide.

(We've started this discussion, some more comments on frontmatter

Physics:  Here I am not so sure what the main issues are, but I'd
guess that for a lot of stuff the above applies, too.

I guess some provision should be made for the consistent mark-up of
units (I have seen publisher's packages which provide for this, but
again, this is not really be addressed unilaterally by a publisher) as
well as a different set of special symbols.

Apparently the frontmatter is more tricky as sometimes papers are
written by lots of people.

Anything else?

Computer Science:  The math stuff probably applies here, too.  Some
standardized mark-up for program listings?

Humanities?  Maybe this is not so critical here as few publishers
would consider accepting LaTeX anyway?

Anything different for Astronomy?

I should stress here that I do not want subject specific standards. In
my opinion, an updated RevTeX is not a desirable goal. What we need is
a collection of standard packages (like amsmath) which can be loaded
for certain purposes, complemented by a set of rules which specify
what a portable document may contain, so that ANY publisher can
process the document with only header changes with their production
class.  Of course it would be nice if they would make their classes

This raises the issue about what should be admissible in a portable
LaTeX document. E.g., should things like \enlargethispage be legal in
such documents? The answer is not clear to me. One could either
explicitly discourage people to use them, or to expect any production
class to ignore any visual mark-up and provide the functionality with
different macros.

Then there are red herrings like \beq and \eeq that some people place
all over, the general question of what macros one may define in
portable LaTeX documents etc. Probably publishers know better what
problems may come up, but the important thing is that this does not
belong documented in a publisher's instruction file but into the most
basic LaTeX reference book (meaning Lamport's reference, with all due
respect to Lamport, should be banned).

Other issues may be:

- Output to PDF, thus disqualifying fonts which are not also available
  in Postscript Type 1.

- Mark-up of tables (I think this is an area where LaTeX is really
  deficient, both in functionality and in the necessity of visual
  mark-up even for many trivial tables).

- Guidelines for including graphics (psfrag???)

I am sure this list could be much longer.  Anyway, most of these
problems mostly require adequate documentation from an authoritative
source (cathedral style, if you want to call it like this), apart from
the problem of defining and implementing a universal frontmatter

Frank Mittelbach wrote:
> this stability is extremely important in the latex community, even
> upward compatible changes are considered bad by the majority of the
> users as we often had to find out because any such change means that
> some document only works if everybody uses version xyz dated... so
> portability goes down the drain. the need to be up-to-date if
> extensions are part of the game is far more accepted (ie getting a new
> package) but to be forced to change "the latex installation" is
> unfortunately something most people think is an unnecessary luxury
> since after all it does work.

In the context of frontmatter I believe that the benefits by far
outweigh the disadvantages. The problem is already there: If I want to
publish in journal X, I have to download journal X's preprint class
plus documentation (assuming journal X is nice enough to provide one),
possibly change my document so that x.cls runs it. All of my
co-authors will have to do the same if they want to be able to process
the file. So if it is possible to, once and for all, provide all the
means necessary in the base of LaTeX so that individual author classes
become obsolete, even on the expense of compatibility problems with
old installations, this would make a lot of peoples' lifes much

In any case, I feel there are people who are much more competent than
I am to address the frontmatter issue, but I would be happy to
contribute to the discussion, or write some hacks or documentation if
some consensus about the best way to approach this can be reached.

On a final note, the motivations of the publishing trade are still
mysterious to me:

Sebastian Rahtz wrote:
>  > ultimately incompatible. I really know SGML/XML (Sebastian, what do
>  > you hope to get out of the LaTeX3 project that you think you cannot
>  > get out of SGML?),
> I want a reliable batch-oriented page makeup system, no more, no
> less. I want to store my text in XML, and have LaTeX produce beautiful
> pages when I give it a style sheet

Are you speaking for yourself, or for Elsevier? While I could see that
XML/MathML may make sense for me in certain circumstances, because I
may want to reuse the logical structure, I don't see why this should
matter for a publisher whose job it is to get the thing on paper, and
possibly into an online repository (PDF?). There does not seem to be a
widely available user interface for XML, so currently, it also does
not seem realistic to expect authors to submit XML. So what's the
problem with LaTeX (apart from the ones that we discussed, and seem
very much fixable)? It should be much preferable to, say, Word's .doc
format or rtf???