Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f18KkxH32061 for ; Thu, 8 Feb 2001 21:46:59 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f18Kkxd14805 . for ; Thu, 8 Feb 2001 21:46:59 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f18Kkw715875 for ; Thu, 8 Feb 2001 21:46:58 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09210.47E9A380" Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id VAA27501 for ; Thu, 8 Feb 2001 21:46:58 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f18Kkt715870 for ; Thu, 8 Feb 2001 21:46:55 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <11.1AFC1C60@mail.listserv.gmd.de>; Thu, 8 Feb 2001 21:46:49 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488843 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 8 Feb 2001 21:46:52 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id VAA01604 for ; Thu, 8 Feb 2001 21:46:51 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id VAA25280 for ; Thu, 8 Feb 2001 21:46:51 +0100 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f18Kkpu16700 for ; Thu, 8 Feb 2001 21:46:51 +0100 (MET) Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14Qxxq-0000VV-00 for LATEX-L@urz.uni-heidelberg.de; Thu, 8 Feb 2001 21:46:50 +0100 Received: from manz-3e364807.pool.mediaways.net ([62.54.72.7] helo=istrati.zdv.uni-mainz.de) by mrvdom03.kundenserver.de with esmtp (Exim 2.12 #2) id 14Qxxg-00055S-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Thu, 8 Feb 2001 21:46:40 +0100 Received: (from latex3@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA07632; Thu, 8 Feb 2001 21:44:57 +0100 In-Reply-To: References: <01JZMVN1N7XK0009XR@ALPHA.NTP.SPRINGER.DE> Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 X-Authentication-Warning: istrati.zdv.uni-mainz.de: latex3 set sender to frank@mittelbach-online.de using -f Content-class: urn:content-classes:message Subject: Re: inputenc text (and/or math) Date: Thu, 8 Feb 2001 21:44:57 +0100 Message-ID: <14979.1353.825196.318011@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3758 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09210.47E9A380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael wrote: > > The text/math ambiguity is a major problem for higher-level user > interfaces like Scientific Word. If the user enters \gamma + 1 = without > first starting a math formula, then the proper way for the software = to > write it is: > > \textgamma \textplus 1 > > instead of > > $\gamma + 1$ but isn't this ambiguity already present anyway in TeX? and those = interfaces have to deal with it? E.g., if you write 1+2 without explicitly marking = it as a math formula you get a text string 1+2 not $1+2$ or to remind you = about the nice little article by Don Knuth years back when he explained that he = learned he was misusing the fact that digits in text and math when using CM = fonts look the same so that his book Concrete math ended up looking horrible = because there digits for text were coming from concrete roman while those in = math where coming from the euler fonts. so i see no solution here for such systems other than forcing the user = to explicitly mark math as being math. so from that perspective I see no argument against having the = possibility to use keys generating 8bit characters to be used in text and math = producing different glyphs. my argument why i do not want of offer something like this as a default = is that: - it can't be explained which keys will work and which not (okay that = is already difficult with claiming only visible ascii can be used in = both by default, but the latter is far easier to explain) - we have no reliable solution unfortunately to resolve that \halign = problem so far since Donald unfortunately has fail us :-) (so far that is) the first point in my opinion is important enough to make a new set of inputenc files all produce text only results. As long as the second one remains unresolved i do have even qualms about offering something like \DeclareInputTextAndMath for preamble or private packages use since it would mean one would need to explain why in = certain situation one can get errors or worse (?) bad/incorrect typesetting = results, but i guess for the benefit of languages like Russian or Greek which = really do need such a feature it should probably be provided nevertheless. However i still would hope one could find a way to get rid of it = somehow. > Nevertheless it seems clear that it would be better to have a = separate > hash table for math commands and text commands. So \gamma could have = one > definition in math and another one in text without the constant use = of > \relax \ifmmode a\else b\fi. This of course is not possible in TeX = 3.x; > perhaps in NTS or e-TeX or Omega. but that would not solve the problem either (though I agree it would = perhaps be a good extension) since the problem with the \halign really is the = timing: you see the \"a under the assumption that you are parsing for text mode = so you expand whatever the internal form expands to, eg \OT1-cmd \"\OT1\", then = you expand \OT1-cmd which i wont bother to write down here :-) and by the = time you reach, say \accent and trigger the template's u-part your original \" is = long gone; so if now the u-part puts a $ in front you are too late. frank ------_=_NextPart_001_01C09210.47E9A380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: inputenc text (and/or math)

Michael wrote:
 >
 > The text/math ambiguity is a major problem = for higher-level user
 > interfaces like Scientific Word. If the = user enters \gamma + 1 without
 > first starting a math formula, then the = proper way for the software to
 > write it is:
 >
 >   \textgamma \textplus 1
 >
 > instead of
 >
 >   $\gamma + 1$

but isn't this ambiguity already present anyway in = TeX? and those interfaces
have to deal with it? E.g., if you write 1+2 without = explicitly marking it as
a math formula you get a text string 1+2 not $1+2$ or = to remind you about the
nice little article by Don Knuth  years back = when he explained that he learned
he was misusing the fact that digits in text and math = when using CM fonts look
the same so that his book Concrete math ended up = looking horrible because
there  digits for text were coming from concrete = roman while those in math
where coming from the euler fonts.

so i see no solution here for such systems other than = forcing the user to
explicitly mark math as being math.

so from that perspective I see no argument against = having the possibility to
use keys generating 8bit characters to be used in = text and math producing
different glyphs.

my argument why i do not want of offer something like = this as a default is
that:

 - it can't be explained which keys will work and = which not (okay that is
   already difficult with claiming only = visible ascii can be used in both by
   default, but the latter is far easier to = explain)

 - we have no reliable solution unfortunately to = resolve that \halign problem
   so far since Donald unfortunately has = fail us :-) (so far that is)

the first point in my opinion is important enough to = make a new set of
inputenc files all produce text only results.

As long as the second one remains unresolved i do have = even qualms about
offering something like \DeclareInputTextAndMath for = preamble or private
packages use since it would mean one would need to = explain why in certain
situation one can get errors or worse (?) = bad/incorrect typesetting results,
but i guess for the benefit of languages like Russian = or Greek which really do
need such a feature it should probably be provided = nevertheless.

However i still would hope one could find a way to get = rid of it somehow.

 > Nevertheless it seems clear that it would = be better to have a separate
 > hash table for math commands and text = commands. So \gamma could have one
 > definition in math and another one in text = without the constant use of
 > \relax \ifmmode a\else b\fi. This of = course is not possible in TeX 3.x;
 > perhaps in NTS or e-TeX or Omega.

but that would not solve the problem either (though I = agree it would perhaps
be a good extension) since the problem with the = \halign really is the timing:
you see the \"a under the assumption that you = are parsing for text mode so you
expand whatever the internal form expands to, eg = \OT1-cmd \"\OT1\", then you
expand \OT1-cmd which i wont bother to write down = here :-) and by the time you
reach, say \accent and trigger the template's u-part = your original \" is long
gone; so if now the u-part puts a $ in front you are = too late.

frank

------_=_NextPart_001_01C09210.47E9A380--