LISTSERV mailing list manager LISTSERV 16.0

Help for LATEX-L Archives


LATEX-L Archives

LATEX-L Archives


LATEX-L@LISTSERV.UNI-HEIDELBERG.DE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

LATEX-L Home

LATEX-L Home

LATEX-L  November 1998

LATEX-L November 1998

Subject:

Re: What is "base" LaTeX

From:

Marcel Oliver <[log in to unmask]>

Reply-To:

Mailing list for the LaTeX3 project <[log in to unmask]>

Date:

Sun, 15 Nov 1998 00:02:43 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (218 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
  LaTeX.

- 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:
> > and UNLESS IT IS WELL DOCUMENTED, which, as
> > 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
  collection.

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
below.)

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
public...

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
interface.

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
easier.

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???

Marcel

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

September 2019
July 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
June 2018
May 2018
April 2018
February 2018
January 2018
December 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
July 2016
April 2016
March 2016
February 2016
January 2016
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
September 2012
August 2012
July 2012
June 2012
May 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
September 2007
August 2007
June 2007
May 2007
March 2007
December 2006
November 2006
October 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
November 2005
October 2005
September 2005
August 2005
May 2005
April 2005
March 2005
November 2004
October 2004
August 2004
July 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
October 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
October 2002
September 2002
August 2002
July 2002
June 2002
March 2002
December 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996

ATOM RSS1 RSS2



LISTSERV.UNI-HEIDELBERG.DE

Universität Heidelberg | Impressum | Datenschutzerklärung

CataList Email List Search Powered by the LISTSERV Email List Manager