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 f12E5X705597 for ; Fri, 2 Feb 2001 15:05:33 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f12E6L707617 . for ; Fri, 2 Feb 2001 15:06:24 +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 f12E5O721089 for ; Fri, 2 Feb 2001 15:05:24 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D21.350F3480" 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 PAA10602 for ; Fri, 2 Feb 2001 15:05:18 +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 f12E5HM12717 for ; Fri, 2 Feb 2001 15:05:18 +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.0243AD71@mail.listserv.gmd.de>; Fri, 2 Feb 2001 15:05:14 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 486120 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 2 Feb 2001 15:05:14 +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 PAA26606 for ; Fri, 2 Feb 2001 15:05:13 +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 PAA22574 for ; Fri, 2 Feb 2001 15:05:13 +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 f12E5Bu17381 for ; Fri, 2 Feb 2001 15:05:11 +0100 (MET) Received: (from mjd@localhost) by ams.org (8.11.1/8.11.1) id f12E56T25093; Fri, 2 Feb 2001 09:05:06 -0500 (EST) In-Reply-To: J%ORG KNAPPEN's message of "Fri, 2 Feb 2001 13:00:06 +0100" Lines: 35 References: <01JZMVN1N7XK0009XR@ALPHA.NTP.SPRINGER.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, 2 Feb 2001 15:05:05 +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: 3696 This is a multi-part message in MIME format. ------_=_NextPart_001_01C08D21.350F3480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable J%ORG KNAPPEN writes: > Yes, this was my intention. If I type "=D7" (the times sign in > Latin-1,2,3, and 4) I want that it works both in text and in math mode = giving > something sensible (i.e. \textmultiply or \times resp.) I don't want = to > have the command \times in text mode and \textmultiply in math mode = necessarily 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$ Or, if all the math symbols are made to work equally well outside of math, simply \gamma +1 in the middle of the text. This is first of all bad markup, and thus sure to lead to problems later on; but there is already a problem at the outset, namely that there will be either no space around the plus sign, or (if the user explicitly adds spaces, which requires extra typing on their part) then the spacing will not be the correct math formula spacing for a binary operator. 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. ------_=_NextPart_001_01C08D21.350F3480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: inputenc text (and/or math)

J%ORG KNAPPEN <KNAPPEN@ALPHA.NTP.SPRINGER.DE> = writes:

> Yes, this was my intention. If I type = "=D7" (the times sign in
> Latin-1,2,3, and 4) I want that it works both in = text and in math mode giving
> something sensible (i.e. \textmultiply or \times = resp.) I don't want to
> have the command \times in text mode and = \textmultiply in math mode necessarily

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$

Or, if all the math symbols are made to work equally = well outside of
math, simply

  \gamma +1

in the middle of the text. This is first of all bad = markup, and thus
sure to lead to problems later on; but there is = already a problem at the
outset, namely that there will be either no space = around the plus sign,
or (if the user explicitly adds spaces, which = requires extra typing on
their part) then the spacing will not be the correct = math formula
spacing for a binary operator.

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.

------_=_NextPart_001_01C08D21.350F3480--