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 f19EWXH04520 for ; Fri, 9 Feb 2001 15:32:33 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f19EWWd17975 . for ; Fri, 9 Feb 2001 15:32:32 +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 f19EWVM10148 for ; Fri, 9 Feb 2001 15:32:31 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C092A5.238BD680" 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 PAA25975 for ; Fri, 9 Feb 2001 15:32: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 f19EWUM10144 for ; Fri, 9 Feb 2001 15:32:30 +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 <8.F6C9A045@mail.listserv.gmd.de>; Fri, 9 Feb 2001 15:32:24 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488469 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 9 Feb 2001 15:32:26 +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 PAA20115 for ; Fri, 9 Feb 2001 15:32:25 +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 PAA17182 for ; Fri, 9 Feb 2001 15:32:24 +0100 Received: from knatte.tninet.se (knatte.tninet.se [195.100.94.10]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with SMTP id f19EWNu24420 for ; Fri, 9 Feb 2001 15:32:23 +0100 (MET) Received: (qmail 3227 invoked from network); 9 Feb 2001 15:32:21 +0100 Received: from delenn.tninet.se (HELO algonet.se) (195.100.94.104) by knatte.tninet.se with SMTP; 9 Feb 2001 15:32:21 +0100 Received: from [195.100.226.130] (du130-226.ppp.su-anst.tninet.se [195.100.226.130]) by delenn.tninet.se (BLUETAIL Mail Robustifier 2.2.1) with ESMTP id 106234.729140.981delenn-s2 ; Fri, 09 Feb 2001 15:32:20 +0100 In-Reply-To: <200102091205.NAA12700@peano.cs.uni-dortmund.de> References: Message from Hans Aberg of "Fri, 09 Feb 2001 12:48:05 +0100." Return-Path: X-Sender: haberg@pop.matematik.su.se Content-class: urn:content-classes:message Subject: Re: inputenc text (and/or math) Date: Fri, 9 Feb 2001 15:26:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Hans Aberg" 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: 3775 This is a multi-part message in MIME format. ------_=_NextPart_001_01C092A5.238BD680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> I tend to think that there in a text mode for natural language alone, = there >> should be no numbers allowed, only letters and punctuation marks. Oops. I stepped on a touchy point, it seems. At 13:05 +0100 2001/02/09, Karsten Tinnefeld wrote: >Our (that is, German syntax) rules state that text mode numbers should = ouly >be written out as number words up to twelve. But there are text mode >numbers which are definitely not maths, as in > > ``in the summer of '69'' > ``they were not only pirates, they were The Wild 13'' > (The number of the beast is $666$? I don't think so.) >Also, I tend to treat enumeration numbers (\thesection, \itemize-items) >as text number's, raising them to the third makes to sense. At 12:14 +0000 2001/02/09, Sebastian Rahtz wrote: >not to mention telephone numbers Do you mean from a logical point of view or a rendering point of view? = -- From the logical point of view, those are all enumerations, standard = math objects. At 13:44 +0100 2001/02/09, Frank Mittelbach wrote: >i don't quite agree. there are certainly schools that would like to = bann >numbers in a context like this but even if you spell out all such = number as >text you still have the problem that you have to allow textual number, = or are >you really proposing that a reference to a page or a figure or heading = has to >be as "see figure seven.three"? This is not really what I said; if only math mode is available, one = should either write "see figure seven.three" or "see figure $7.3$", but not = simply "see figure 7.3", as the last is both logically wrong, and invites to making mistakes in markup. However, stepping into the question of renderings, one should in this = case have a special label environment, that makes the labels appear consistently, both logically and in rendering. Again, it should not be possible to write "see figure 7.3". >and depending on the design such number might get quite a different = treatment >to those being part of a math formula (eg they might be in old style or = they >might be in the text font family or ...) So then they should be put in special environments, separating them from the text. >so there are "textual digits" and there are "mathematical digits". I think that your "textual digits" only arise in the absence of proper markup, just as it is common to have other symbols sprayed into the = text, in the absence of a proper symbol environments. Hans Aberg ------_=_NextPart_001_01C092A5.238BD680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: inputenc text (and/or math)

>> I tend to think that there in a text mode for = natural language alone, there
>> should be no numbers allowed, only letters = and punctuation marks.
 Oops. I stepped on a touchy point, it = seems.

At 13:05 +0100 2001/02/09, Karsten Tinnefeld = wrote:
>Our (that is, German syntax) rules state that = text mode numbers should ouly
>be written out as number words up to twelve. But = there are text mode
>numbers which are definitely not maths, as = in
>
>        ``in = the summer of '69''
>        ``they = were not only pirates, they were The Wild 13''
>        (The = number of the beast is $666$? I don't think so.)

>Also, I tend to treat enumeration numbers = (\thesection, \itemize-items)
>as text number's, raising them to the third makes = to sense.

At 12:14 +0000 2001/02/09, Sebastian Rahtz = wrote:
>not to mention telephone numbers

Do you mean from a logical point of view or a = rendering point of view? --
>From the logical point of view, those are all = enumerations, standard math
objects.

At 13:44 +0100 2001/02/09, Frank Mittelbach = wrote:
>i don't quite agree. there are certainly schools = that would like to bann
>numbers in a context like this but even if you = spell out all such number as
>text you still have the problem that you have to = allow textual number, or are
>you really proposing that a reference to a page = or a figure or heading has to
>be as "see figure seven.three"?

This is not really what I said; if only math mode is = available, one should
either write "see figure seven.three" or = "see figure $7.3$", but not simply
"see figure 7.3", as the last is both = logically wrong, and invites to
making mistakes in markup.

However, stepping into the question of renderings, one = should in this case
have a special label environment, that makes the = labels appear
consistently, both logically and in rendering. Again, = it should not be
possible to write "see figure 7.3".

>and depending on the design such number might = get  quite a different treatment
>to those being part of a math formula (eg they = might be in old style or they
>might be in the text font family or ...)

So then they should be put in special environments, = separating them from
the text.

>so there are "textual digits" and there = are "mathematical digits".

I think that your "textual digits" only = arise in the absence of proper
markup, just as it is common to have other symbols = sprayed into the text,
in the absence of a proper symbol = environments.


  Hans Aberg

------_=_NextPart_001_01C092A5.238BD680--