LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
text/plain; charset=us-ascii
Mailing list for the LaTeX3 project <[log in to unmask]>
David Kastrup <[log in to unmask]>
Fri, 24 Jan 2003 15:56:23 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain (99 lines)
        Timothy Murphy <[log in to unmask]> writes:

> On Friday 24 January 2003 00:28, David Kastrup wrote:
> > If you take a look at printed mathematics in journals, you'll find
> > things like display equations spanning two of three columns.
> I have just taken a look at some mathematical journals,
> and none of them seemed to do anything like that.
> They are all in fact excessively conservative (even by my standards),
> particularly the German ones.
> Which journal are you referring to?

I have seen stuff like that (IIRC some awfully expensive Elsevier
journal or similar) but don't have the library at hand right now.
Anyhow, the point was that such typesetting tasks even exist when
confining oneself to the context of mathematic publications.  But that
is a restriction that I would not want to see applied to LaTeX,
anyhow.  Would you state that such typesetting tasks should never be
solvable by reverting to LaTeX-based solutions?  That LaTeX should be
confined to catering for more mundane mathematical publications?

> >  I am just wondering why you are subscribed to this list when your
> > opinion is that LaTeX should not be improved.
> You are being disingenuous.

Well, the sentiment is reciprocated ;)

> I am all in favour of improving LaTeX, given that I think it is
> already pretty good, due to the work of the LaTeX team over the
> years.
> But what you are talking about is tinkering with the TeX engine on
> which LaTeX runs.

No.  I am talking about using an already tinkered with engine that
has been tested and available for years.  I am not proposing
inventing eTeX, I am proposing using it.

> I wouldn't even object to that in principle, but it seems to me that
> it would be better to make small changes, as and when they are
> clearly needed and can be fully justified _by added functionality
> that they give to the end user_.

What are you proposing here formally?  To abandon the readily
available work done on eTeX-2 in order to come up with some mini-eTeX
versions?  eTeX-2 is available right now, and solidly established.  It
is hardly likely you as a user would notice any difference if your
distribution vendor changed to providing it as the default LaTeX

> For example, one issue that has often been raised is the shortage of
> registers.  I haven't looked at tex.web carefully,

But some other people have, and I see no reason to ignore the pains
they have taken to cater with the problems in order to come up with
incompatible solutions that would achieve nothing more.

>  but on the face of it when Knuth says
> @d box_base=toks_base+256 {table of 256 box registers}
> it seems that one could increase the 256
> without the heavens falling down.

On the face of it.  But much more is involved since the data
structures for addressing these sorts of items also have a fixed size
and so on and so on.  These problems have been dealt with in eTeX.  It
is not that eTeX-2 is something as radical as NTS (a reimplementation
in Java).  eTeX-2 is implemented as a set of change files to the
original TeX source.  For that reason, almost any TeX implementation
relying on the original TeX source code as a basis for mechanical
translation (like web2c does) can crank out an eTeX with equivalent
efficiency and functionality in a reasonably short time frame.  The
closer one keeps to the original source code in an implementation (and
you seem _very_ much in favor of keeping to the original source code),
the less problematic generation of an eTeX executable is, and most
implementations come with it by default by now (there are commercial
exceptions I hear, but if they get told in time about the requirements
of the LaTeX team, I am sure they will accommodate, too).

> (One might even ask Knuth if he would sanction a general increase in
> register sizes, though I recognise that he has a rather rigid
> approach to changes in TeX.)

Knuth's target is not to provide an optimal engine for LaTeX.  And
there simply is no point in trying to coax Knuth into some sort of
giving work that is necessary for LaTeX his particular blessing.

It makes sense for Knuth to restrict changes to TeX to what he thinks
appropriate for his usage of TeX (which does not even include _any_
version of LaTeX).  It makes sense for the LaTeX team to not restrict
themselves to a code base that is maintained clearly without a focus
on their particular needs.

David Kastrup, Kriemhildstr. 15, 44793 Bochum