Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 12:53:23 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0MBrJ6C008456 for ; Wed, 22 Jan 2003 12:53:21 +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 h0MBcFSa001547; Wed, 22 Jan 2003 12:38:15 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C20C.DD6B7B80" 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 h0LN04IB021675; Wed, 22 Jan 2003 12:30:51 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 7259 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Wed, 22 Jan 2003 12:30:51 +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 h0MBUo5f026108 for ; Wed, 22 Jan 2003 12:30:50 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0MBbqSb001468 for ; Wed, 22 Jan 2003 12:37:58 +0100 (MET) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18bJ37-0003tt-00 for LATEX-L@listserv.uni-heidelberg.de; Wed, 22 Jan 2003 12:28:05 +0100 Received: from [80.129.0.69] (helo=istrati.mittelbach-online.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18bJ37-0003Ub-00 for LATEX-L@listserv.uni-heidelberg.de; Wed, 22 Jan 2003 12:28:05 +0100 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h0MBOvD19307; Wed, 22 Jan 2003 12:24:57 +0100 In-Reply-To: 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-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 22 Jan 2003 11:53:23.0788 (UTC) FILETIME=[DDE3B8C0:01C2C20C] x-mime-autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id h0MBUo5f026109 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: Wed, 22 Jan 2003 12:24:57 +0100 Message-ID: A<15918.32649.326340.239302@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: LICR objects in math Thread-Index: AcLCDN4CAUwqG138ThCjCNmv6Ef5pQ== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4468 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C20C.DD6B7B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Donald, you proved once more to be able to dish out very complex code in passing = :-) > > > Definition to convert from LICR to glyph: > > Note that statement! This really doesn't have anything to do with > *input* encoding, but deals with the output encoding. right and i think this is where the problem lies: i wrote: > > 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? > > Yes, this is pseudo-TeX. Replace \string =E4 with \\T1\"-a as = for T1. i understood that this is pseudo code what i meant is that the slot defined by inputenc for =E4 does not need = to have anything to do with the slot defined by the current font encoding. = however the trick you use makes use of such a relationship (more exactly of a 1-to-1 relationship). of course it is correct for T1 or LY1 in most cases, but = this is not a general rule. it will certainly fail the moment the input = encoding is, say, utf8, right? it will also fail if you start from the LICR directly, eg $\texteuro$ % perhaps put there manually or via some utf8 input method that goes of to try changing the fontencoding and then typeset some slot = from TS1. so even if we get to that point we issue \\TS1\texeuro finally the = number that refers to bears no relationship to the code attached to it by = inputenc (if any). so the trick to trigger the math mode using \char then sneak = back via "8000 to restart the definition of some active char would fail as we = don't know what to do then. so my claim is still, this doesn't work on a general basis. It would = work for most of current inputenc plus T1 fonts and similar constallations but = not otherwise, eg when supporting utf8 as an input encoding or for chars whose inputenc = slot bears no relation to the font slot. however as long as the two slots are the same thereisn't much need for something like inputenc anyway (as long as one only works in that = framework) which is nicely proven by Bernard since he uses catcode type letter to = input his upper 8bits. since i was wrong often enough perhaps also here ... but then i would = need a bit more pseudo code :-) ------ anyway, all that struggling nicely vanishes if one uses eTeX version 2. = so why not do that and have a package that tests for eTeX and if it finds out = that it doesn't run under eTeX emits a warning (at the beginning and end of the = run), eg \typeout{********************************************************^^J% *^^J% * WARNING: ^^J% *^^J% * \@spaces The inpmath package was written to support 8bit^^J% * \@spaces characters as they can be entered from the keyboard both^^J% * \@spaces in text as well as in math formulas.^^J% *^^J% * \@spaces However, for this to work in all circumstances the^^J% * \@spaces code uses a feature only available with the eTeX^^J% * \@spaces program.^^J% *^^J% * \@spaces eTeX is implemented both as a standalone replacement^^J% * \@spaces for TeX, as well as being part of pdftex.^^J% *^^J% * You do NOT use eTeX to process your document!^^J% *^^J% * \@spaces As a result the following might fail: Characters entered = at^^J% * \@spaces the beginning of an array cell (where the cell is typeset^^J% * \@spaces in math mode) might produce the wrong result or even = vanish^^J% * \@spaces without a warning!^^J% *^^J% * Resolution:^^J% *^^J% * \@spaces Either use eTeX instead of TeX for processing your^^J% * \@spaces documents, or put \noexpand\protect before a^^J% * \@spaces character that poses a problem.^^J% ********************************************************} questions: a) any obvious problems with this approach? b) more particular, can that approach replace textmath.sty, ie what is = the situation these days in Russia concerning eTeX? note, that even with normal TeX the package behaves well, except for the danger outlined in the warning and for that one one has a workaround. c) if consider a good thing then some suggestions for a better name for \DeclareMathMeaning would be helpful, and perhaps somebody who would = help to finish providing a base set of such declarations d) any other comments? (or perhaps pseudo code that proves there exist = a different solution) the implementation is finish for the above except that i not cheers frank ------_=_NextPart_001_01C2C20C.DD6B7B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LICR objects in math

Donald,

you proved once more to be able to dish out very = complex code in passing :-)

 > >  > Definition to convert from = LICR to glyph:
 >
 > Note that statement!  This really = doesn't have anything to do with
 > *input* encoding, but deals with the = output encoding.

right and i think this is where the problem = lies:

i wrote:

 > > 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?
 >
 > Yes, this is pseudo-TeX.  = Replace  \string =E4  with  \\T1\"-a  as for = T1.

i understood that this is pseudo code

what i meant is that the slot defined by inputenc for = =E4 does not need to have
anything to do with the slot defined by the current = font encoding. however the
trick you use makes use of such a relationship (more = exactly of a 1-to-1
relationship). of course it is correct for T1 or LY1 = in most cases, but this
is not a general rule. it will certainly fail the = moment the input encoding
is, say, utf8, right?

it will also fail if you start from the LICR directly, = eg

$\texteuro$  % perhaps put there manually or via = some utf8 input method

that goes of to try changing the fontencoding and then = typeset some slot from
TS1. so even if we get to that point we issue = \\TS1\texeuro finally the number
that refers to bears no relationship to the code = attached to it by inputenc
(if any). so the trick to trigger the math mode using = \char then sneak back
via "8000 to restart the definition of some = active char would fail as we don't
know what to do then.

so my claim is still, this doesn't work on a general = basis. It would work for
most of current inputenc plus T1 fonts and similar = constallations but not otherwise,
eg when supporting utf8 as an input encoding or for = chars whose inputenc slot
bears no relation to the font slot.

however as long as the two slots are the same = thereisn't much need for
something like inputenc anyway (as long as one only = works in that framework)
which is nicely proven by Bernard since he uses = catcode type letter to input
his upper 8bits.

since i was wrong often enough perhaps also here = ...  but then i would need a
bit more pseudo code :-)

------

anyway, all that struggling nicely vanishes if one = uses eTeX version 2. so why
not do that and have a package that tests for eTeX = and if it finds out that it
doesn't run under eTeX emits a warning (at the = beginning and end of the run),
eg

\typeout{*******************************************************= *^^J%
*^^J%
* WARNING: ^^J%
*^^J%
* \@spaces The inpmath package was written to support = 8bit^^J%
* \@spaces characters as they can be entered from the = keyboard both^^J%
* \@spaces in text as well as in math = formulas.^^J%
*^^J%
* \@spaces However, for this to work in all = circumstances the^^J%
* \@spaces code uses a feature only available with = the eTeX^^J%
* \@spaces program.^^J%
*^^J%
* \@spaces eTeX is implemented both as a standalone = replacement^^J%
* \@spaces for TeX, as well as being part of = pdftex.^^J%
*^^J%
* You do NOT use eTeX to process your = document!^^J%
*^^J%
* \@spaces As a result the following might fail: = Characters entered at^^J%
* \@spaces the beginning of an array cell (where the = cell is typeset^^J%
* \@spaces in math mode) might produce the wrong = result or even vanish^^J%
* \@spaces without a warning!^^J%
*^^J%
* Resolution:^^J%
*^^J%
* \@spaces Either use eTeX instead of TeX for = processing your^^J%
* \@spaces documents, or put \noexpand\protect before = a^^J%
* \@spaces character that poses a problem.^^J%
********************************************************}=


questions:

 a) any obvious problems with this = approach?

 b) more particular, can that approach replace = textmath.sty, ie what is the
    situation these days in Russia = concerning eTeX?

note, that even with normal TeX the package behaves = well, except for the
danger outlined in the warning and for that one one = has a workaround.

 c) if consider a good thing then some = suggestions for a better name for
 \DeclareMathMeaning would be helpful, and = perhaps somebody who would help to
 finish providing a base set of such = declarations

 d) any other comments? (or perhaps pseudo code = that proves there exist a
 different solution)


the implementation is finish for the above except that = i not
cheers
frank

------_=_NextPart_001_01C2C20C.DD6B7B80--