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 f198q4H01689 for ; Fri, 9 Feb 2001 09:52:05 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f198q4d16931 . for ; Fri, 9 Feb 2001 09:52:04 +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 f198q3721711 for ; Fri, 9 Feb 2001 09:52:03 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09275.93826880" 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 JAA01757 for ; Fri, 9 Feb 2001 09:52:01 +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 f198q0M10859 for ; Fri, 9 Feb 2001 09:52:00 +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 <9.650C4C4B@mail.listserv.gmd.de>; Fri, 9 Feb 2001 9:51:53 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 487684 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 9 Feb 2001 09:51:54 +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 JAA10319 for ; Fri, 9 Feb 2001 09:51:53 +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 JAA27072 for ; Fri, 9 Feb 2001 09:51:55 +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 f198ptu24928 for ; Fri, 9 Feb 2001 09:51:55 +0100 (MET) Received: from [195.20.224.204] (helo=mrvdom00.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14R9HW-0001VW-00 for LATEX-L@urz.uni-heidelberg.de; Fri, 9 Feb 2001 09:51:54 +0100 Received: from manz-3e364596.pool.mediaways.net ([62.54.69.150] helo=istrati.zdv.uni-mainz.de) by mrvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14R9H4-00001r-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Fri, 9 Feb 2001 09:51:26 +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 JAA27049; Fri, 9 Feb 2001 09:50:16 +0100 In-Reply-To: <200102082216.RAA12899@hilbert.math.albany.edu> References: <200102082216.RAA12899@hilbert.math.albany.edu> 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 09:50:16 +0100 Message-ID: <14979.44872.211349.959138@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: 3764 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09275.93826880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bill, > > 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$ > > Whether or not text is in math mode is an important authoring issue > that requires explicit author indication. that's what i was trying to say, didn't I? the ambiguity is already = there and therefore needs explicit author indication already now. > For example: > > \begin{quote} > Everyone knows that the 2 most important numbers are $0$ and $1$\@. > \end{quote} nice example. > But inasmuch as LaTeX does not come with its own fonts, it seems to = me > that the pragmatic thing would be to provide dual handling of \alpha > etc. when possible with the fonts at hand and unified handling = otherwise. the problem that I think you are underestimating is that there is far = more to math then unicode code point specification. Unicode has the unfortunate believe that if two distinct character that by default "look" the same = could very well be presented by the same unicode code point. this is not the = case as there is additional sematic information to the glyph which makes them = from the language "mathematics" different characters. this is also true for some natural languages which got some of their = code points being scattered around just because a few of their characters already appeared in some legacy keyboard encoding so if i say \foo in math i do not only denote a unicode char but also = its mathematical type, eg, this is a relation or a binary operator or ... so = the same glyph might have different representations and only a single one of = those could be represented if you would try to make \alpha and \textalpha = being addressed by a single command. > P.S. I assume that this discussion, which began with your questions > about changing over to the T1 fontenc, is about LaTeX3 and not about > the next 2E (unless the next 2E is to be 3). it is mostly about 2e* or 2e+ in my book, ie the collection of packages starting with x... which are currently being added to the project web site. they run on top of 2e but once being stable and forming a whole = might as well provide the conceptual basis for a final kernel rewrite. at least = this is my view right now. frank ------_=_NextPart_001_01C09275.93826880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: inputenc text (and/or math)

Bill,

 > > 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$
 >
 > Whether or not text is in math mode is an = important authoring issue
 > that requires explicit author = indication.

that's what i was trying to say, didn't I? the = ambiguity is already there and
therefore needs explicit author indication already = now.

 > For example:
 >
 > \begin{quote}
 > Everyone knows that the 2 most important = numbers are $0$ and $1$\@.
 > \end{quote}

nice example.

 > But inasmuch as LaTeX does not come with = its own fonts, it seems to me
 > that the pragmatic thing would be to = provide dual handling of \alpha
 > etc. when possible with the fonts at hand = and unified handling otherwise.

the problem that I think you are underestimating is = that there is far more to
math then unicode code point specification. Unicode = has the unfortunate
believe that if two distinct character  that by = default "look" the same could
very well be presented by the same unicode code = point. this is not the case as
there is additional sematic information to the glyph = which makes them from the
language "mathematics" different = characters.
this is also true for some natural languages which = got some of their code
points being scattered around just because a few of = their characters
already appeared in some legacy keyboard = encoding

so if i say \foo in math i do not only denote a = unicode char but also its
mathematical type, eg, this is a relation or a binary = operator or ... so the
same glyph might have different representations and = only a single one of those
could be represented if you would try to make \alpha = and \textalpha being
addressed by a single command.


 > P.S.  I assume that this discussion, = which began with your questions
 > about changing over to the T1 fontenc, is = about LaTeX3 and not about
 > the next 2E (unless the next 2E is to be = 3).

it is mostly about 2e* or 2e+ in my book, ie the = collection of packages
starting with x... which are currently being added to = the project web
site. they run on top of 2e but once being stable and = forming a whole might as
well provide the conceptual basis for a final kernel = rewrite. at least this is
my view right now.

frank

------_=_NextPart_001_01C09275.93826880--