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 f19GIWH05075 for ; Fri, 9 Feb 2001 17:18:32 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f19GIWd18295 . for ; Fri, 9 Feb 2001 17:18:32 +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 f19GIV702499 for ; Fri, 9 Feb 2001 17:18:31 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C092B3.F1CE3C00" 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 RAA20787 for ; Fri, 9 Feb 2001 17:18:31 +0100 (MET) 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 f19GIVM18984 for ; Fri, 9 Feb 2001 17:18:31 +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 <14.C43D4E1C@mail.listserv.gmd.de>; Fri, 9 Feb 2001 17:18:21 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488833 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 9 Feb 2001 17:18:23 +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 RAA23147 for ; Fri, 9 Feb 2001 17:18:22 +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 RAA16076 for ; Fri, 9 Feb 2001 17:18:23 +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 f19GINu24225 for ; Fri, 9 Feb 2001 17:18:23 +0100 (MET) Received: from [195.20.224.209] (helo=mrvdom02.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14RGFa-0008IU-00 for LATEX-L@urz.uni-heidelberg.de; Fri, 9 Feb 2001 17:18:22 +0100 Received: from manz-3e364854.pool.mediaways.net ([62.54.72.84] helo=istrati.zdv.uni-mainz.de) by mrvdom02.schlund.de with esmtp (Exim 2.12 #2) id 14RGFz-00008J-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Fri, 9 Feb 2001 17:18:48 +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 RAA28591; Fri, 9 Feb 2001 17:16:51 +0100 In-Reply-To: References: <01JZMVN1N7XK0009XR@ALPHA.NTP.SPRINGER.DE> <14979.1353.825196.318011@istrati.zdv.uni-mainz.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: Fri, 9 Feb 2001 17:16:51 +0100 Message-ID: <14980.6131.413948.678289@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: 3779 This is a multi-part message in MIME format. ------_=_NextPart_001_01C092B3.F1CE3C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael, > 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. and what I am saying is that they can't, really, deal with it. they have = to provide a math markup and there is no way to identify something as "this should be math" automatically. so there is no real solution to the = problem that people by mistake leave the needed markup out. > 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. > :-) it is not and i agree with you on that but i also think that for = situations like writing in a cyrillic languages where i want to use both in text as = in math cyrillic letters (comparable to the use of latin letters in math as = far as i understand) it seems appropriate to provide the same type of = ambiguity we currently have with latin in that we should say "the variable $x$ has = the ..." with the danger of having users type "the variable x has the ...". why appropriate because it is a horrible scenario if you would have to = write $(\matha + \mathb)^\mathtwo =3D \matha^\mathtwo + \mathtwo\matha\mathb + \mathb^\mathtwo$ wouldn't it? And that is essentially what people in Russia have to face, isn't it? Still, i would like to have this additional ambiguity being added to the document as a concious act and not by default. Ie the standard input = encodings should be in my opinion mapping to text only ie use \DeclareInputText = only frank ------_=_NextPart_001_01C092B3.F1CE3C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: inputenc text (and/or math)

Michael,

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

and what I am saying is that they can't, really, deal = with it. they have to
provide a math markup and there is no way to identify = something as "this
should be math" automatically. so there is no = real solution to the problem
that people by mistake leave the needed markup = out.

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

it is not and i agree with you on that but i also = think that for situations
like writing in a cyrillic languages where i want to = use both in text as in
math cyrillic letters (comparable to the use of latin = letters in math as far
as i understand) it seems appropriate to provide the = same type of ambiguity we
currently have with latin in that we should say = "the variable $x$ has the ..."
with the danger of having users type "the = variable x has the ...".

why appropriate because it is a horrible scenario if = you would have to write

 $(\matha + \mathb)^\mathtwo =3D \matha^\mathtwo = +
          &nbs= p;         \mathtwo\matha\mathb = + \mathb^\mathtwo$

wouldn't it?

And that is essentially what people in Russia have to = face, isn't it?


Still, i would like to have this additional ambiguity = being added to the
document as a concious act and not by default. Ie the = standard input encodings
should be in my opinion mapping to text only ie use = \DeclareInputText only

frank

------_=_NextPart_001_01C092B3.F1CE3C00--