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 f19F03H04673 for ; Fri, 9 Feb 2001 16:00:03 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f19F03d18078 . for ; Fri, 9 Feb 2001 16:00:03 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f19ExwM12564 for ; Fri, 9 Feb 2001 15:59:58 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C092A8.FB05DB80" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id PAA02813 for ; Fri, 9 Feb 2001 15:59:57 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f19ExvM12560 for ; Fri, 9 Feb 2001 15:59:57 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <10.CCB482F2@mail.listserv.gmd.de>; Fri, 9 Feb 2001 15:59:51 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488534 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 9 Feb 2001 15:59: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 PAA20872 for ; Fri, 9 Feb 2001 15:59: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 PAA37190 for ; Fri, 9 Feb 2001 15:59:51 +0100 Received: from ams.org (sun06.ams.org [130.44.1.6]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f19Expu01873 for ; Fri, 9 Feb 2001 15:59:51 +0100 (MET) Received: (from mjd@localhost) by ams.org (8.11.1/8.11.1) id f19Exno20269; Fri, 9 Feb 2001 09:59:49 -0500 (EST) In-Reply-To: Frank Mittelbach's message of "Thu, 8 Feb 2001 21:44:57 +0100" Lines: 47 References: <01JZMVN1N7XK0009XR@ALPHA.NTP.SPRINGER.DE> <14979.1353.825196.318011@istrati.zdv.uni-mainz.de> Return-Path: X-Mailer: Gnus v5.7/Emacs 20.7 Content-class: urn:content-classes:message Subject: Re: inputenc text (and/or math) Date: Fri, 9 Feb 2001 15:59:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Michael John Downes" 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: 3777 This is a multi-part message in MIME format. ------_=_NextPart_001_01C092A8.FB05DB80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank Mittelbach writes: > but isn't this ambiguity already present anyway in TeX? and those = interfaces > have to deal with it? > 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. I didn't explain clearly. What we have now is that (a) For people with GUI interface like Scientific Word, the software has to deal with the ambiguity as best it can. (b) For people with non-GUI interface like vi, writing a Greek letter (for example) outside of math leads to a TeX error at run-time. If the 8-bit latin-1 characters that look like \times and \mu are made to work equally well in text as in math, then doesn't it seem likely that the people in case (b) are going to make more markup errors (writing \mu etc as a text symbol when it should be wrapped in a math formula) because there is nothing to bring it to their attention (other than reading the documentation :-) ? In other words currently it is easy for people in case (a) to make those markup errors, and the proposal under discussion would extend this so that it is easier for all users. It's not clear that this is progress. :-) I guess I don't have a solution, I am just reflecting on the idea that the restriction of mathchardef'd symbols to math mode was intended (I think) by Knuth to bring markup mistakes to the user's attention. Instead of an error, he could have arranged that \gamma triggers start-math, just as letter X triggers a switch from vmode to hmode. To be sure, because we have \ensuremath it is already possible for people who read the documentation to inconsistently omit math markup all over the place anyway. But it has always seemed to me that it might be better to tell the editor about the "ensuremath" objects and have the editor insert $ $ automatically when necessary rather than have LaTeX do it by using \ensuremath. If anyone is not sufficiently confused enough yet I invite them to consider how LaTeX might better handle "<" and ">" when someone uses them in text. In OT1 encoding LaTeX silently gives the wrong symbol, in T1 you get the math less and greater (when what the user wanted was probably langle rangle or else guillemets). ------_=_NextPart_001_01C092A8.FB05DB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: inputenc text (and/or math)

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

> but isn't this ambiguity already present anyway = in TeX? and those interfaces
> have to deal with it?

> 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.

I didn't explain clearly. What we have now is = that

(a) For people with GUI interface like Scientific = Word, the software has
to deal with the ambiguity as best it can.

(b) For people with non-GUI interface like vi, writing = a Greek letter
(for example) outside of math leads to a TeX error at = run-time.

If the 8-bit latin-1 characters that look like \times = and \mu are made
to work equally well in text as in math, then doesn't = it seem likely
that the people in case (b) are going to make more = markup errors
(writing \mu etc as a text symbol when it should be = wrapped in a math
formula) because there is nothing to bring it to = their attention (other
than reading the documentation :-) ?

In other words currently it is easy for people in case = (a) to make those
markup errors, and the proposal under discussion = would extend this so
that it is easier for all users. It's not clear that = this is progress.
:-)

I guess I don't have a solution, I am just reflecting = on the idea that
the restriction of mathchardef'd symbols to math mode = was intended (I
think) by Knuth to bring markup mistakes to the = user's attention.
Instead of an error, he could have arranged that = \gamma triggers
start-math, just as letter X triggers a switch from = vmode to hmode.

To be sure, because we have \ensuremath it is already = possible for
people who read the documentation to inconsistently = omit math markup all
over the place anyway. But it has always seemed to me = that it might be
better to tell the editor about the = "ensuremath" objects and have the
editor insert $ $ automatically when necessary rather = than have LaTeX do
it by using \ensuremath.

If anyone is not sufficiently confused enough yet I = invite them to
consider how LaTeX might better handle = "<" and ">" when someone uses
them in text. In OT1 encoding LaTeX silently gives = the wrong symbol, in
T1 you get the math less and greater (when what the = user wanted was
probably langle rangle or else guillemets).

------_=_NextPart_001_01C092A8.FB05DB80--