Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 16:14:12 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0KFEA6C032586 for ; Mon, 20 Jan 2003 16:14:11 +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 h0KExXAL009187; Mon, 20 Jan 2003 15:59:33 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C096.965B7A00" 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 h0K3Jsxx000694; Mon, 20 Jan 2003 15:52:08 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 7193 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 20 Jan 2003 15:52:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h0KEq85f007336 for ; Mon, 20 Jan 2003 15:52:08 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0KExCAL009108 for ; Mon, 20 Jan 2003 15:59:13 +0100 (MET) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18adOJ-0000MI-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 20 Jan 2003 15:59:11 +0100 Received: from [80.129.5.232] (helo=istrati.mittelbach-online.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18adOI-00052t-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 20 Jan 2003 15:59:10 +0100 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h0KEuHx24004; Mon, 20 Jan 2003 15:56:17 +0100 In-Reply-To: <15916.1578.804504.547177@lin2.idris.fr> References: <15916.1578.804504.547177@lin2.idris.fr> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 20 Jan 2003 15:14:12.0977 (UTC) FILETIME=[96F08E10:01C2C096] 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: -1 () IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02,X_AUTH_WARNING Content-class: urn:content-classes:message Subject: Re: LICR objects in math Date: Mon, 20 Jan 2003 15:56:17 +0100 Message-ID: A<15916.3601.724740.511520@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LICR objects in math Thread-Index: AcLAlpcNYVP2D1J2Sc23EGZiz5+GnA== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4446 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C096.965B7A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bernard, > > glad to learn that; can you perhaps tell us how you resolved the = problem of > > either killing ligatures and kerns or alternatively making the = wrong choice at > > the begining of an \halign cell that afterwards (!) jumps into = math mode? > > there is no need to resolve a pb which does not exist: there is no > \ifmmode and there is no expansion since i use the "mltex" option and > thus inputed chars belong to category "letter". ah, so what you mean is you solved it for a subgroup of the clientele of todays LaTeX 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? that also explains why you have a problem with using the wrong = diacritics as you pass on the characters straight. at least that is fortunately no = problem with the current approach > ok, so you have to change the original title "Providing math support > for inputenc" IMHO. I'm afraid that if text chars can't be all used = in math > it will be of least interest. the title is perhpas not the best, it should have probably been talking = about math support for LICR objects (though one big application is inputenc) = but i don't see that that this is without interest a) there are languages for which is is really important, eg Russian = Greek for for them the solution works b) one can come up with math representations for any character, i just = said if there is none you will get an appropriate error message (which is = better then simply get the wrong symbol or none at all) actually i doubt that for Latin based languages the chars like \L \o etc = play an important role in math (i haven't come across them in formulas) more interesting is the approach that any input character has a well-defined behaviour in text and math (even if sometimes it might be "sorry not available"). by the way the latter also happens in text if your fonts do = not support a certain char, frank frank ------_=_NextPart_001_01C2C096.965B7A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LICR objects in math

Bernard,

 >  > glad to learn that; can you = perhaps tell us how you resolved the problem of
 >  > either killing ligatures and = kerns or alternatively making the wrong choice at
 >  > the begining of an \halign cell = that afterwards (!) jumps into math mode?
 >
 > there is no need to resolve a pb which = does not exist: there is no
 > \ifmmode and there is no expansion since i = use the "mltex" option and
 > thus inputed chars belong to category = "letter".

ah, so what you mean is you solved it for a subgroup = of the clientele of
todays LaTeX 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?

that also explains why you have a problem with using = the wrong diacritics as
you pass on the characters straight. at least that is = fortunately no problem
with the current approach

 > ok, so you have to change the original = title "Providing math support
 > for inputenc" IMHO. I'm afraid that = if text chars can't be all used in math
 > it will be of least interest.

the title is perhpas not the best, it should have = probably been talking about
math support for LICR objects (though one big = application is inputenc) but i
don't see that that this is without interest

 a) there are languages for which is is really = important, eg Russian Greek for
 for them the solution works

 b) one can come up with math representations for = any character, i just said
 if there is none you will get an appropriate = error message (which is better
 then simply get the wrong symbol or none at = all)

actually i doubt that for Latin based languages the = chars like \L \o etc play
an important role in math (i haven't come across them = in formulas) more
interesting is the approach that any input character = has a well-defined
behaviour in text  and math (even if sometimes = it might be "sorry not
available"). by the way the latter also happens = in text if your fonts do not
support a certain char,

frank

frank

------_=_NextPart_001_01C2C096.965B7A00--