Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 12:14:36 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0LBEX6C003603 for ; Tue, 21 Jan 2003 12:14:34 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0LAwTX3001326; Tue, 21 Jan 2003 11:58:29 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C13E.4801B600" 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 h0L2ppDV012859; Tue, 21 Jan 2003 11:51:20 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 8502 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 21 Jan 2003 11:51:20 +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 h0LApI5f015737 for ; Tue, 21 Jan 2003 11:51:18 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0LAwJX4001261 for ; Tue, 21 Jan 2003 11:58:21 +0100 (MET) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18aw5t-0007G7-00 for LATEX-L@listserv.uni-heidelberg.de; Tue, 21 Jan 2003 11:57:25 +0100 Received: from [80.129.10.128] (helo=istrati.mittelbach-online.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18aw5o-00006B-00 for LATEX-L@listserv.uni-heidelberg.de; Tue, 21 Jan 2003 11:57:24 +0100 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h0LAsMF20623; Tue, 21 Jan 2003 11:54:22 +0100 In-Reply-To: <15917.5131.149954.42674@lin2.idris.fr> References: <15917.5131.149954.42674@lin2.idris.fr> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 21 Jan 2003 11:14:36.0407 (UTC) FILETIME=[483FD070:01C2C13E] x-mime-autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id h0LApI5f015738 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.7 () IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03,X_AUTH_WARNING Content-class: urn:content-classes:message Subject: Re: LICR objects in math Date: Tue, 21 Jan 2003 11:54:22 +0100 Message-ID: A<15917.9950.434672.425660@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LICR objects in math Thread-Index: AcLBPkhgJvpCPO7ESfmJZqrNO7EbrQ== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4458 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C13E.4801B600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bernard, > fallacious argument i heard for the first time 20 years ago, when = accented > chars were only used by a subgroup of TeX users... Willing to solve > all world's problems often generates no solution, so having > complementary solutions is a good approach. definitely, i wasn't trying to argue against that. i was simply stating = that this is not what i was looking for, i was looking for a solution that = works together with inputenc. Vladimir's textmath.sty is another such completementary approach but also for a quite welldefined group of languages/applications > > and only for the chars that are part of your base font (or can be > > constructed from them), eg if you type $\texteuro$ what happens? > > as we spoke about input encoding and math, \text constructs were > not concerned. If \DeclareMathMeaning can solve the pb of $\texteuro$ > it's fine. ??? if some user presses a key on his/her keyboard then due to inputenc = he/she gets an object in the LICR, eg \"a or \oe or \texteuro or \cyro or ... if that is used in text then LaTex knows how to deal with any of them, = if it is used in math then the question is to give it a sensible meaning > > One limited possibility would be > > \mathcode`\=E4=3D"8000 > > i confess this is also my trick along with the mltex option and > thus there is an expansion: > > {the letter =E0} > =E0->\mathaccent "7012\relax a > > > would require that input encoding and font encoding match... > > no more than \catcode`\=E4=3D\active of inputenc! that works for a TeX which uses =E4 of type letter. but that means only characters and languages that are in your 8bit codepage of your computer = can be produced with this TeX. That's fine, but as i said it is for some = group of languages useful. inputenc tries to implment more languages and more encoding concept (and = will hopefully soon also have utf8) and for this =E4 is already active and = can't take two types of definition at the same time (and testing for \ifmmode to = decide between the too doesn't work, see discussions frank ------_=_NextPart_001_01C2C13E.4801B600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LICR objects in math

Bernard,

 > fallacious argument i heard for the first = time 20 years ago, when accented
 > chars were only used by a subgroup of TeX = users... Willing to solve
 > all world's problems often generates no = solution, so having
 > complementary solutions is a good = approach.

definitely, i wasn't trying to argue against that. i = was simply stating that
this is not what i was looking for, i was looking for = a solution that works
together with inputenc. Vladimir's textmath.sty is = another such
completementary approach but also for a quite = welldefined group of
languages/applications

 >  > and only for the chars that are = part of your base font (or can be
 >  > constructed from them), eg if = you type $\texteuro$ what happens?
 >
 > as we spoke about input encoding and math, = \text constructs were
 > not concerned. If \DeclareMathMeaning can = solve the pb of $\texteuro$
 > it's fine.

???

if some user presses a key on his/her keyboard then = due to inputenc he/she
gets an object in the LICR, eg \"a or \oe or = \texteuro or \cyro or ...

if that is used in text then LaTex knows how to deal = with any of them, if it
is used in math then the question is to give it a = sensible meaning

 > > One limited possibility would = be
 > > \mathcode`\=E4=3D"8000
 >
 > i confess this is also my trick along with = the mltex option and
 > thus there is an expansion:
 >
 > {the letter =E0}
 > =E0->\mathaccent "7012\relax = a
 >
 > > would require that input encoding and = font encoding match...
 >
 > no more than \catcode`\=E4=3D\active of = inputenc!

that works for a TeX which uses =E4 of type letter. = but that means only
characters and languages that are in your 8bit = codepage of your computer can
be produced with this TeX. That's fine, but as i said = it is for some group of
languages useful.

inputenc tries to implment more languages and more = encoding concept (and will
hopefully soon also have utf8) and for this =E4 is = already active and can't take
two types of definition at the same time (and testing = for \ifmmode to decide
between the too doesn't work, see discussions

frank

------_=_NextPart_001_01C2C13E.4801B600--