Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:14:41 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0N9Ed6C011867 for ; Thu, 23 Jan 2003 10:14:39 +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 h0LBgCX3020235; Tue, 21 Jan 2003 12:42:13 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C2BF.DC475680" 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 h0L2ppEp012859; Tue, 21 Jan 2003 12:34:53 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 8550 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 21 Jan 2003 12:34:53 +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 h0LBOr5f016196 for ; Tue, 21 Jan 2003 12:24:53 +0100 Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0LBVSX6015196 for ; Tue, 21 Jan 2003 12:31:56 +0100 (MET) Received: from fwd01.sul.t-online.de by mailout03.sul.t-online.com with smtp id 18awJo-00063a-0C; Tue, 21 Jan 2003 12:11:48 +0100 Received: from localhost.localdomain (520018396234-0001@[62.226.11.225]) by fmrl01.sul.t-online.com with esmtp id 18awJj-0MCYpUC; Tue, 21 Jan 2003 12:11:43 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0LBBaUJ024165 for ; Tue, 21 Jan 2003 12:11:37 +0100 Received: (from dak@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id h0LBBX3R024161; Tue, 21 Jan 2003 12:11:34 +0100 In-Reply-To: <15917.9945.473122.219613@istrati.mittelbach-online.de> Lines: 59 References: <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-OriginalArrivalTime: 23 Jan 2003 09:14:41.0635 (UTC) FILETIME=[DCA83B30:01C2C2BF] 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 h0LBOr5f016197 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -2.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_GNUS_UA Content-class: urn:content-classes:message Subject: Re: LICR objects in math Date: Tue, 21 Jan 2003 12:11:32 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LICR objects in math Thread-Index: AcLCv9z8aklYIubwRnuTsLiOUUnJkw== From: "David Kastrup" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4459 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C2BF.DC475680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank Mittelbach writes: > > > that's for the case where \"a is precisely *not* executing an > > > \accent but is actually a glyph in the current font > > > > But that is the only case you have to handle! \accent combinations > > don't have the right kerning anyway, so just stick \relax before > > the \accent. > > you both are right and i was wrong (for the case of > accents). however you would have to identify that \"a is a glyph > first, even more, you would need to do the right thing concerning > any text character eg some are fetched from a different encoding so > all that would be very messy indeed > > > The (killer) problem I see has already been alluded to: The = inputenc > > characters are already active, so you have to have a single = definition > > that works for both the initial expansion of the input text and as = the > > math-active character, without recursion. > > > > David's usage of "=E4" is probably part of the "illegal notation", = but if > > I may either clarify or fix: > > > > Definition to convert from LICR to glyph: > > > > \def{\"a}{\ifmmode \relax % make sure we are in math mode to stay > > \ifmmode \ddot a% > > \else \string =E4\fi > > \else \string =E4\fi} > > sorry, perhaps i'm still dumb from my cold or else dumb anyway, but > i don't get you here. what is this supposed to tell me? > > one of the problem is that pressing key =E4 (umlaut-a) on the keyboard > maps to \"a alright in the LICR but that is not equiv to doing > > \string =E4 > > for typesetting --- the slot to use varies from encoding to > encoding. so if i interpret your definition above correctly then you > end up with exactly typesetting \char `=E4 always for \"a ... or what? Certainly. That is why I said that this would only work where input and font encoding matched. Then you said it would not work at all, then Donald explained why it would, and now you have forgotten already that I said it would only work with matching inputenc and fontenc. That is why I said that it would be nice to have the active mathcharcode thingie have an option mapping to a different active character. Not sure that would solve all problems, and it would probably be much saner to use \protected as explained instead of trying to fudge another extension into TeX. Anyhow, if your mail reader allows following a thread, I recommend that you go through the last few mails of this exchange again to get the context again. The above was only mentioned as an expedient for a special case, not as an actual implementation proposal. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ------_=_NextPart_001_01C2C2BF.DC475680 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:

>  > > that's for the case where = \"a is precisely *not* executing an
>  > > \accent but is actually a glyph = in the current font
>  >
>  > But that is the only case you have to = handle!  \accent combinations
>  > don't have the right kerning anyway, = so just stick \relax before
>  > the \accent.
>
> you both are right and i was wrong (for the case = of
> accents). however you would have to identify = that \"a is a glyph
> first, even more, you would need to do the right = thing concerning
> any text character eg some are fetched from a = different encoding so
> all that would be very messy indeed
>
>  > The (killer) problem I see has = already been alluded to: The inputenc
>  > characters are already active, so you = have to have a single definition
>  > that works for both the initial = expansion of the input text and as the
>  > math-active character, without = recursion.
>  >
>  > David's usage of "=E4" is = probably part of the "illegal notation", but if
>  > I may either clarify or fix:
>  >
>  > Definition to convert from LICR to = glyph:
>  >
>  > \def{\"a}{\ifmmode \relax % make = sure we are in math mode to stay
>  = >           = \ifmmode \ddot a%
>  = >           \else = \string =E4\fi
>  = >           \else = \string =E4\fi}
>
> sorry, perhaps i'm still dumb from my cold or = else dumb anyway, but
> i don't get you here. what is this supposed to = tell me?
>
> one of the problem is that pressing key =E4 = (umlaut-a) on the keyboard
> maps to \"a alright in the LICR but that is = not equiv to doing
>
>  \string =E4
>
> for typesetting --- the slot to use varies from = encoding to
> encoding. so if i interpret your definition = above correctly then you
> end up with exactly typesetting \char `=E4 = always for \"a ... or what?

Certainly.  That is why I said that this would = only work where input
and font encoding matched.  Then you said it = would not work at all,
then Donald explained why it would, and now you have = forgotten already
that I said it would only work with matching inputenc = and fontenc.
That is why I said that it would be nice to have the = active
mathcharcode thingie have an option mapping to a = different active
character.  Not sure that would solve all = problems, and it would
probably be much saner to use \protected as explained = instead of
trying to fudge another extension into TeX.

Anyhow, if your mail reader allows following a thread, = I recommend
that you go through the last few mails of this = exchange again to get
the context again.  The above was only mentioned = as an expedient for
a special case, not as an actual implementation = proposal.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

------_=_NextPart_001_01C2C2BF.DC475680--