Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 21:24:34 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0MKOW6C009969 for ; Wed, 22 Jan 2003 21:24:32 +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 h0MKDKtt015722; Wed, 22 Jan 2003 21:13:20 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C254.46C2AD00" 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 h0MEKDKH028309; Wed, 22 Jan 2003 21:05:57 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 8697 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 22 Jan 2003 21:05:57 +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 h0MK5u5f032074 for ; Wed, 22 Jan 2003 21:05:56 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0MKD6Vw018829 for ; Wed, 22 Jan 2003 21:13:06 +0100 (MET) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18bRFC-0002sA-00 for LATEX-L@listserv.uni-heidelberg.de; Wed, 22 Jan 2003 21:13:06 +0100 Received: from [80.129.0.69] (helo=istrati.mittelbach-online.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18bRFB-0003yu-00 for LATEX-L@listserv.uni-heidelberg.de; Wed, 22 Jan 2003 21:13:05 +0100 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h0MK9pu22209; Wed, 22 Jan 2003 21:09:51 +0100 In-Reply-To: References: <15918.32649.326340.239302@istrati.mittelbach-online.de> <15915.60496.798501.907773@lin2.idris.fr> <15915.64379.146524.772099@istrati.mittelbach-online.de> <15916.8635.946195.989212@istrati.mittelbach-online.de> <15916.14608.340151.43815@istrati.mittelbach-online.de> <15917.9945.473122.219613@istrati.mittelbach-online.de> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 22 Jan 2003 20:24:34.0657 (UTC) FILETIME=[4726ED10:01C2C254] x-mime-autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id h0MK5u5f032075 X-Authentication-Warning: istrati.mittelbach-online.de: frank set sender to frank@mittelbach-online.de using -f X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.1 () IN_REP_TO,REFERENCES,SPAM_PHRASE_05_08,X_AUTH_WARNING Content-class: urn:content-classes:message Subject: Re: LICR objects in math Date: Wed, 22 Jan 2003 21:09:51 +0100 Message-ID: A<15918.64143.537552.784269@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LICR objects in math Thread-Index: AcLCVEdBqRLehuN8QT+7toSAOvBK1w== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4474 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C254.46C2AD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lars, > >My original proposal of doing such a declaration for the next LaTeX > >release was violently opposed. > > An important difference between the suggestions is that you suggested = that > LaTeX should have a built-in uselessness (that prevented running it = on > non-e-TeX): you want to remove functionality. Certainly not before = 2004, > but nonetheless uselessness. I haven't read David's suggestions like that. I too consider it sensible = to allow work for l3 be based on better/additional primitives which as a = result means that a l3 kernel will not run below TeX as an engine. > What Frank suggests is rather to point out > that an existing bug does go away if one uses e-TeX; this effectively = adds > functionality. Having inputenc always scream about it is probably to = overdo > it, but Frank seem to have in mind that enabling LICR objects for = math > should be done using a separate package inpmath. i have implemented it as a separate package, for the sake of playing = with it. I haven't made up my mind what it should be. it could be a) a separate package b) a package option to inputenc in any case it is *not* fixing a bug with the current inputenc, or the = current LICR since the current model used the IBM approach: if you can't fix it = call it a feature. in other words: LICR commands currently are simply not allowed in math. period. so all :-) the package (or whatever it becomes) does is provide new functionality for those people who want it. (well new in the sense that = it works better for latin based languages than Vladimir's textmath, which = also provides that feature but with kerning problems) right now if you use \usepackage[latin1]{inputenc} $=E4$ you'll get a LaTeX error message telling you that this is not allow with = an additional package or with an option like "mathsupported" it will become = a possibility, but with a warning if you do not use a program that = contains the eTeX primitives. frank ps a new implementation using eTeX primitive is available from http://www.latex-project.org/code/experimental/inpmath.zip ------_=_NextPart_001_01C2C254.46C2AD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LICR objects in math

Lars,

 > >My original proposal of doing such a = declaration for the next LaTeX
 > >release was violently opposed.
 >
 > An important difference between the = suggestions is that you suggested that
 > LaTeX should have a built-in uselessness = (that prevented running it on
 > non-e-TeX): you want to remove = functionality. Certainly not before 2004,
 > but nonetheless uselessness.

I haven't read David's suggestions like that. I too = consider it sensible to
allow work for l3 be based on better/additional = primitives which as a result
means that a l3 kernel will not run below TeX as an = engine.



 > What Frank suggests is rather to point = out
 > that an existing bug does go away if one = uses e-TeX; this effectively adds
 > functionality. Having inputenc always = scream about it is probably to overdo
 > it, but Frank seem to have in mind that = enabling LICR objects for math
 > should be done using a separate package = inpmath.

i have implemented it as a separate package, for the = sake of playing with
it. I haven't made up my mind what it should be. it = could be

 a) a separate package
 b) a package option to inputenc

in any case it is *not* fixing a bug with the current = inputenc, or the current
LICR since the current model used the IBM approach: = if you can't fix it call
it a feature.

in other words: LICR commands currently are simply not = allowed in
math. period.

so all :-) the package (or whatever it becomes) does = is provide new
functionality for those people who want it. (well new = in the sense that it
works better for latin based languages than = Vladimir's textmath, which also
provides that feature but with kerning = problems)

right now if you use

\usepackage[latin1]{inputenc}

  $=E4$

you'll get a LaTeX error message telling you that this = is not allow with an
additional package or with an option like = "mathsupported" it will become a
possibility, but with a warning if you do not use a = program that contains the
eTeX primitives.

frank

ps a new implementation using eTeX primitive is = available from

   http:= //www.latex-project.org/code/experimental/inpmath.zip

------_=_NextPart_001_01C2C254.46C2AD00--