Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 18:32:20 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0KHWH6C000764 for ; Mon, 20 Jan 2003 18:32:18 +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 h0KHKmZr015961; Mon, 20 Jan 2003 18:20:48 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C0A9.E263EA00" 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 h0K3Js7F000694; Mon, 20 Jan 2003 18:13:32 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 7516 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 20 Jan 2003 18:13:32 +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 h0KH3W5f009014 for ; Mon, 20 Jan 2003 18:03:32 +0100 Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0KHAZAL013474 for ; Mon, 20 Jan 2003 18:10:36 +0100 (MET) Received: from fwd07.sul.t-online.de by mailout03.sul.t-online.com with smtp id 18afRS-00043Z-0E; Mon, 20 Jan 2003 18:10:34 +0100 Received: from localhost.localdomain (520018396234-0001@[62.226.11.219]) by fmrl07.sul.t-online.com with esmtp id 18afRM-0hv9KSC; Mon, 20 Jan 2003 18:10:28 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0KHAR3k020331 for ; Mon, 20 Jan 2003 18:10:27 +0100 Received: (from dak@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id h0KHAQBh020327; Mon, 20 Jan 2003 18:10:26 +0100 In-Reply-To: <15916.8635.946195.989212@istrati.mittelbach-online.de> Lines: 52 References: <15915.60496.798501.907773@lin2.idris.fr> <15915.64379.146524.772099@istrati.mittelbach-online.de> <15916.8635.946195.989212@istrati.mittelbach-online.de> Return-Path: X-OriginalArrivalTime: 20 Jan 2003 17:32:20.0385 (UTC) FILETIME=[E29EA910:01C2C0A9] X-Sender: 520018396234-0001@t-dialin.net User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 x-mime-autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id h0KH3W5f009015 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -2.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA Content-class: urn:content-classes:message Subject: Re: LICR objects in math Date: Mon, 20 Jan 2003 18:10:26 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LICR objects in math Thread-Index: AcLAqeK7Kpb7RNPKR56bO22PSfbMfw== From: "David Kastrup" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4451 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C0A9.E263EA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank Mittelbach writes: > > > 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? > > > > One limited possibility would be > > \mathcode`\=E4=3D"8000 > > yes, that is the sort of only out one would have, but as far as we > could see it isn't going to allow a resolution. > > point is > > a) this doesn't help for LICR objects like \" as they potentially = execute > \accent and that bombs in math Nope. We would have the case where \"a has a proper letter equivalent. In that case we would write the following (excuse the illegal notation \def{\"a}{\ifmmode \relax \ifmmode \ddot a\else =E4\fi\else =E4\fi} Now if we accidentally produced the character =E4 while putatively in text mode, the mathcode "8000 would kick in and cause \"a to get reevaluated as long as the active character =E4 evaluated to \=E4.[1] If the object would evaluate to an accent, still no harm: \def{\"a}{\relax \ifmmode \ddot a\else \accentwhatever \fi} An accent does not kern or ligature, anyway. > b) and even if \"a expands to a \chardef then the chardef number > depends on the outer fontencoding so might vary from case to case That's the real problem. How about squashing this particular problem with \protected\def{\"a}{\ifmmode ...}? Footnotes: [1] BTW, this cries for a TeX extension: "8000 evaluates to the same character, only made active. Wouldn't it be nice if "80xx evaluated to a _different_ active character? Or even to some control sequence? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ------_=_NextPart_001_01C2C0A9.E263EA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LICR objects in math

        Frank = Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG> writes:

>  > > 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?
>  >
>  > One limited possibility would = be
>  > \mathcode`\=E4=3D"8000
>
> yes, that is the sort of only out one would = have, but as far as we
> could see it isn't going to allow a = resolution.
>
> point is
>
>  a) this doesn't help for LICR objects like = \" as they potentially execute
>  \accent and that bombs in math

Nope.  We would have the case where \"a has = a proper letter
equivalent.  In that case we would write the = following (excuse the
illegal notation

\def{\"a}{\ifmmode \relax \ifmmode \ddot a\else = =E4\fi\else =E4\fi}

Now if we accidentally produced the character =E4 = while putatively in
text mode, the mathcode "8000 would kick in and = cause \"a to get
reevaluated as long as the active character =E4 = evaluated to \=E4.[1]

If the object would evaluate to an accent, still no = harm:

\def{\"a}{\relax \ifmmode \ddot a\else = \accentwhatever \fi}

An accent does not kern or ligature, anyway.

>  b) and even if \"a expands to a = \chardef then the chardef number
>  depends on the outer fontencoding so might = vary from case to case

That's the real problem.

How about squashing this particular problem = with
\protected\def{\"a}{\ifmmode ...}?



Footnotes:
[1]  BTW, this cries for a TeX extension:  = "8000 evaluates to the same
character, only made active.  Wouldn't it be = nice if "80xx evaluated
to a _different_ active character?  Or even to = some control
sequence?

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

------_=_NextPart_001_01C2C0A9.E263EA00--