Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 14:57:33 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0KDvU6C032290 for ; Mon, 20 Jan 2003 14:57:31 +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 h0KDeMAL016265; Mon, 20 Jan 2003 14:40:23 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C08B.E123C480" 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 h0K3JswH000694; Mon, 20 Jan 2003 14:32:52 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 7060 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 20 Jan 2003 14:32:52 +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 h0KDWq5f006618 for ; Mon, 20 Jan 2003 14:32:52 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0KDdrZr014818 for ; Mon, 20 Jan 2003 14:39:54 +0100 (MET) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18ac9a-0003cY-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 20 Jan 2003 14:39:54 +0100 Received: from [80.129.5.232] (helo=istrati.mittelbach-online.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18ac9Z-0006Uf-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 20 Jan 2003 14:39:54 +0100 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h0KDax823061; Mon, 20 Jan 2003 14:36:59 +0100 In-Reply-To: <15915.60496.798501.907773@lin2.idris.fr> References: <15915.60496.798501.907773@lin2.idris.fr> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 20 Jan 2003 13:57:33.0547 (UTC) FILETIME=[E1773BB0:01C2C08B] 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: Mon, 20 Jan 2003 14:36:59 +0100 Message-ID: A<15915.64379.146524.772099@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LICR objects in math Thread-Index: AcLAi+GS1R/L5fKDS8eeboTb+WeZiA== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4443 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C08B.E123C480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bernard, > Frank Mittelbach introducing "inpmath": > > \usepackage{inpmath} > > \DeclareMathMeaning{\"}{\ddot} > > pleased to see that project which was already implemented... > at least in French Pro along with the "keyboard" package. > Since i did that for the "mltex" option, i really appreciate > to have it available without it too. 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? > But.. i consider there is a little typographic pb because, in > the current example, the diacritic should not be at the same > place in math (italic) and in text since fonts are very different. > This is in fact a basic TeX pb. so it is, but so it is in my example, eg \"a -> either \accent a or \char % in text -> \ddot a % in math which sets the diacritics differently > Doing that, what about \c and \C? or \L and \o and such? > and \oe, \OE ? The pb is a little more complicated and > should often require a new definition of that macros. i'm at loss at what you are driving at here, can you explain? \DeclareMathMeaning{}{} defines a mapping for an object of LaTeX Internal Character = Representation, e.g. \L, to a math object. That math object needs to exist, ie eith = there is one or there isn't if there isn't you can't map to it, which means using = \L in math will give you an error telling you there is no definition for math. > > i would be very much interested in comments concerning the = approach the > > feasibility or anything else you find useful to discuss in this = respect, eg > > > > should such an implementation be incorporated (somehow not this = one), > > - as a package, > > - as a standard, > > yes, as a standard-goal. well, it still needs sorting out the obstacles that i describe in the docu. Only if that can be safely done one could use that approach as a standard, otherwise i see no chance. the reason that the textmath package by Vladimir works is because it is = geared towards a certain type of language and for a package to be valid that is enough but it wouldn't work properly with a Latin based language like = French or German where most chars are represented by themselves. I would be really interested to learn how the keyboard package = approaches these problems frank ------_=_NextPart_001_01C2C08B.E123C480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LICR objects in math

Bernard,

 > Frank Mittelbach introducing = "inpmath":
 >  > \usepackage{inpmath}
 >  > = \DeclareMathMeaning{\"}{\ddot}
 >
 > pleased to see that project which was = already implemented...
 > at least in French Pro along with the = "keyboard" package.
 > Since i did that for the "mltex" = option, i really appreciate
 > to have it available without it = too.

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?

 > But.. i consider there is a little = typographic pb because, in
 > the current example, the diacritic should = not be at the same
 > place in math (italic) and in text since = fonts are very different.
 > This is in fact a basic TeX pb.

so it is, but so it is in my example, eg

\"a  -> either \accent <something> = a or \char<somenumber>  % in text
     -> \ddot a % in math = which sets the diacritics differently


 > Doing that, what about \c and \C? or \L and = \o and such?
 > and \oe, \OE ? The pb is a little more = complicated and
 > should often require a new definition of = that macros.

i'm at loss at what you are driving at here, can you = explain?

\DeclareMathMeaning{<LICR>}{<code>}

defines a mapping for an object of LaTeX Internal = Character Representation,
e.g. \L, to a math object. That math object needs to = exist, ie eith there is
one or there isn't if there isn't you can't map to = it, which means using \L in
math will give you an error telling you there is no = definition for math.


 >  > i would be very much interested = in comments concerning the approach the
 >  > feasibility or anything else = you find useful to discuss in this respect, eg
 >  >
 >  >  should such an = implementation be incorporated (somehow not this one),
 >  >     - as a = package,
 >  >     - as a = standard,
 >
 > yes, as a standard-goal.

well, it still needs sorting out the obstacles that i = describe in the
docu. Only if that can be safely done one could use = that approach as a
standard, otherwise i see no chance.

the reason that the textmath package by Vladimir works = is because it is geared
towards a certain type of language and for a package = to be valid that is
enough but it wouldn't work properly with a Latin = based language like French
or German where most chars are represented by = themselves.

I would be really interested to learn how the keyboard = package approaches
these problems

frank

------_=_NextPart_001_01C2C08B.E123C480--