Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 16:27:56 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0OFRr6C017334 for ; Fri, 24 Jan 2003 16:27:54 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0OF6ktt016129; Fri, 24 Jan 2003 16:06:46 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C3BD.2B26E600" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h0O3PCMP014696; Fri, 24 Jan 2003 15:59:31 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 8897 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Fri, 24 Jan 2003 15:59:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h0OEnV5f020623 for ; Fri, 24 Jan 2003 15:49:31 +0100 Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0OEukXM002688 for ; Fri, 24 Jan 2003 15:56:46 +0100 (MET) Received: from fwd00.sul.t-online.de by mailout01.sul.t-online.com with smtp id 18c5G9-00072v-09; Fri, 24 Jan 2003 15:56:45 +0100 Received: from localhost.localdomain (520018396234-0001@[62.226.11.148]) by fmrl00.sul.t-online.com with esmtp id 18c5Fq-2GSxweC; Fri, 24 Jan 2003 15:56:26 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0OEuOEP011214 for ; Fri, 24 Jan 2003 15:56:24 +0100 Received: (from dak@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id h0OEuNY9011210; Fri, 24 Jan 2003 15:56:23 +0100 In-Reply-To: <200301241412.36829.tim@birdsnest.maths.tcd.ie> Lines: 98 References: <15915.60496.798501.907773@lin2.idris.fr> <200301232349.20628.tim@birdsnest.maths.tcd.ie> <200301241412.36829.tim@birdsnest.maths.tcd.ie> Return-Path: X-OriginalArrivalTime: 24 Jan 2003 15:27:56.0614 (UTC) FILETIME=[2B849660:01C2C3BD] X-Sender: 520018396234-0001@t-dialin.net User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -2.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_GNUS_UA Content-class: urn:content-classes:message Subject: Re: LICR objects in math Date: Fri, 24 Jan 2003 15:56:23 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LICR objects in math Thread-Index: AcLDvSueEAYxF6EyTKyMq9sfg+zTIw== From: "David Kastrup" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4490 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C3BD.2B26E600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Timothy Murphy 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 format. > 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=3Dtoks_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 ------_=_NextPart_001_01C2C3BD.2B26E600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LICR objects in math

        Timothy = Murphy <tim@BIRDSNEST.MATHS.TCD.IE> 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
format.

> 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=3Dtoks_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

------_=_NextPart_001_01C2C3BD.2B26E600--