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 f16GxSH19434 for ; Tue, 6 Feb 2001 17:59:28 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f16GxSd05393 . for ; Tue, 6 Feb 2001 17:59:28 +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 f16GxRM15545 for ; Tue, 6 Feb 2001 17:59:27 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0905E.2A74D800" Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id RAA22301 for ; Tue, 6 Feb 2001 17:59:27 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f16GxQ723736 for ; Tue, 6 Feb 2001 17:59:26 +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.FF099907@mail.listserv.gmd.de>; Tue, 6 Feb 2001 17:59:21 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488906 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 6 Feb 2001 17:59: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 RAA10939 for ; Tue, 6 Feb 2001 17:59: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 RAA38632 for ; Tue, 6 Feb 2001 17:59:22 +0100 Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f16GxLu14364 for ; Tue, 6 Feb 2001 17:59:22 +0100 (MET) Received: from fell.open.ac.uk by venus.open.ac.uk via SMTP Local (Mailer 3.1) with ESMTP; Tue, 6 Feb 2001 16:59:17 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.9.3+Sun/8.9.1) id QAA16376; Tue, 6 Feb 2001 16:59:32 GMT In-Reply-To: <200102061631.QAA23642@nag.co.uk> References: <200102061609.LAA21018@pluto.math.albany.edu> <200102061631.QAA23642@nag.co.uk> Return-Path: X-Mailer: VM 6.76 under Emacs 20.7.1 X-Authentication-Warning: fell.open.ac.uk: car2 set sender to car2@fell.open.ac.uk using -f Content-class: urn:content-classes:message Subject: Re: default inputenc/fontenc tight to language Date: Tue, 6 Feb 2001 17:59:31 +0100 Message-ID: <14976.11635.576650.311233@fell.open.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Chris Rowley" 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: 3723 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0905E.2A74D800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Carlisle wrote -- > But whether the internal > canonical form is a unicode number or a latex style 7bit string \'e > the issues of mapping between input encodings and this internal form, > and from there to font encodings, are probably about the same. And I just want to agree with this. In fact I would go a lot further and say that the problems raised in this discussion such as the following are the same whatever system you use to do quality typesetting: what is a character? what is the relationship between character strings and relatively = positioned glyphs on a surface? Thus LaTeX and its choice of internally using 7-bit strings is a also a mere detail. And these problems do not go away just because you use larger integers to represent text streams. chris ------_=_NextPart_001_01C0905E.2A74D800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: default inputenc/fontenc tight to language

David Carlisle wrote --

> But whether the internal
> canonical form is a unicode number or a latex = style 7bit string \'e
> the issues of mapping between input encodings = and this internal form,
> and from there to font encodings, are probably = about the same.

And I just want to agree with this.

In fact I would go a lot further and say that the = problems raised in
this discussion such as the following are the same = whatever
system you use to do quality typesetting:

  what is a character?

  what is the relationship between character = strings and relatively positioned
  glyphs on a surface?

Thus LaTeX and its choice of internally using 7-bit = strings is a also
a mere detail.

And these problems do not go away just because you use = larger integers
to represent text streams.


chris

------_=_NextPart_001_01C0905E.2A74D800--