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:

Frank Mittelbach <[log in to unmask]>

Reply-To:

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

Date:

Tue, 10 Nov 1998 23:54:17 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (168 lines)

i think that we have several problems here which to some extend
pulling the ship into different directions; i think we first need to
dis-tangle some of this a bit before it really makes sense to talk
models (or even approaches)

some claims:

- one of the major driving forces of latex is not necessarily the
  quality of its output but the exchangeability and portability of its
  input while maintaining a reasonable quality output and (with the
  necessary skill/knowledge (luck?)) being able to produce without too
  much fuss really high quality output from a nearly unchanged source

- by mid 1992 this was seriously in danger because too many kernel
  dialects floated around, maintenance was poor and because of a few
  other reasons. in essence by that time it was often impossible to
  run even a moderately simple document at one site and expect it to
  compile without errors somewhere else (let alone produce the same
  visual document)

- 2e was the try to bring that chaos back into some order and by the
  same time introduce a number of enhancements (at one hand to help
  promoting the new standard but at the other to provide a basis that
  allow extensions which can peacefully live together (or at least
  better than in the past)

- i claim that we more or less actually achieved this, it is again
  possible to exchange documents quite freely as long as they are
  "clean and simple". Simple here goes a long way further than
  original latex as defined by lamport, even though Marcel thinks (and
  he is right) that it is still narrow (but it does cover graphics,
  color, fonts especially ps fonts, input and output encoding,
  language support (although i don't think that is where it should be
  one day) math via amsmath and other stuff)

- what hasn't been addressed at all (or only very very marginally) was
  style or layout design --- [ by the way, anybody who knows my talk
  given at Stanford 1990 or so about what is wrong with LaTeX 2.09
  will see that what i said back then is actually overachieved already
  with 2e --- so no need for anything like ltx3, is there? well don't
  answer that now :-} ]

- and neither has be front matter stuff been addressed unfortunately


Marcel wrote

> My basic claim is that base LaTeX is too narrowly defined, and
> therefore causes a lot of the document exchange problems which seem
> to occur frequently not only between author and publisher, but also
> between different authors.

well, as David explained, the core LaTeX is simply being defined of
what we support personally plus some extensions like amsmath or psnfss
for which we either have definite maintenance paths or thought we can
support in addition.

for this block of the core we provide very strict consistency checks
and documents that used this stuff two years ago will run now and will
do so in with the december release (will produce identical output) ---
exceptions proving the rule.

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.

so ...

i followed the discussion with interest and some amusement (sometimes)

in my opinion the "core" whatever this is at a certain point in time
can only be maintained by a cathedral solution, and staying with the
picture, without much better arguments as those brought forward so
far, i wouldn't give my blessing to anything else. but as Michael
said, we do have the bazaar situation already in anything that appears
in contrib (supported or other(wise)) and that is essentially what
people feel which is the problem. the crux therefore seems to me how
to make the "core" bigger ie move some of the bazaar stuff into the
cathedral in an acceptable way

second, the linux example is a red herring. its development and
implementation model works because it doesn't effect peoples use of
the system as it is the single system that is effected if you upgrade
your linux (but your ip protocol stays the same it is still tcpic if
not the linux model would die too); with latex the situation is that
the "system" is not the single latex installation but the combination
of all those latex systems out there that you like to communicate
with.

===================================================================

so ...

i do see some good reasons for extending the "core" distribution but
it would require new maintenance and support models and it would need
somewhat conservative people that understand why it can be dangerous
to fix the spacing in article.cls (even though we all know that
design-wise it is mostly rubbish)

all such extensions and new ideas are great and producing code that
works better is fine and those people who know me know that my name is
attached to a few extentions that have finally ended up being in
standard use --- but with my background in TeX programming i can only
say that it is very hard and difficult to try keeping the bigger
picture in mind when taking out the knife to make things better. this
is all fine if you write your own package class or whatever to serve
your private writing style but it is a very different situation if you
try to maintain a world wide distributed system which is supposed to
be portable world wide.

====================================================================

so ...

what i would ask for an extended "core" distribution is (as a minimum)

- stability within the distribution, ie all packages would need to
  work with each other in any legal combination

- source stability between distributions, eg at least 98% of the
  documents should work without problems and without changes to the
  result in a suitable large number of different maintenance releases

- clearly defined and supported maintenance cycles such as the core
  LaTeX nowadays has (they may be longer, eg a year, but one should
  not go back to the old days of 2.09 maintenance which was applied
  whenever it was raining in California)

- a maintenance method that supports this core distribution, the
  current method using latexbug and ending up on the screen of ltx3
  project people can't be the way from that point on

====================================================================

so ...

in my mind this would mean a lot of volunteer work and a lot of good
ideas how to actually set something like this up. perhaps both is
possible but it is not enough to draw a recommended list (even though
this would need to be at the start of it) it needs more

taken the above it would need

- standard installation concepts (and thus reimplementation at least
  of the setup)

- standard integration into a regression test concept (see recent tub
  article by me and David on this for the current core)

- a support structure and people how fill it with life

- interface documentation (and probably development) for those parts
  which are not yet clearly defined

- ...

good night

frank

ps i should have said something of the about aspects as promised in
  the beginning but i'm too tired --- perhaps tomorrow

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