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 f4F8U4f27645 for ; Tue, 15 May 2001 10:30:04 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f4F8U4726222 . for ; Tue, 15 May 2001 10:30:04 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DD19.3D600E00" 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 f4F8U3000554 for ; Tue, 15 May 2001 10:30:03 +0200 (MET DST) 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 KAA09746 for ; Tue, 15 May 2001 10:30:02 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 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 f4F8U1000548 for ; Tue, 15 May 2001 10:30:01 +0200 (MET DST) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <9.3B739431@mail.listserv.gmd.de>; Tue, 15 May 2001 10:28:23 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 495397 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 15 May 2001 10:29:59 +0200 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 KAA01121 for ; Tue, 15 May 2001 10:29:58 +0200 (MET DST) 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 KAA29876 for ; Tue, 15 May 2001 10:29:57 +0200 Received: from smtp.wanadoo.es (m1smtpisp01.wanadoo.es [62.36.220.61] (may be forged)) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f4F8TpQ02666 for ; Tue, 15 May 2001 10:29:51 +0200 (MET DST) Received: from [62.36.81.1] (62-36-81-1.dialup.uni2.es [62.36.81.1]) by smtp.wanadoo.es (8.10.2/8.10.2) with ESMTP id f4F8Tm707443 for ; Tue, 15 May 2001 10:29:49 +0200 (MET DST) Return-Path: X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary 2.2 Date: Tue, 15 May 2001 10:26:36 +0100 Message-ID: <200105150829.f4F8Tm707443@smtp.wanadoo.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Javier Bezos" 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: 4070 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0DD19.3D600E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank wrote some days ago: > as a result one ends up to have to explain all those problems of > misinterpreting the internal forms if you do this or that at a certain = stage > (like storing text in a token register and reusing it at some other = point or > never pass it to the hlist builder (where the OTPs actually execute) For some reason, I missed this paragraph when I first read this message and it's a good point. The problem is not moving information around, but explaining how to do it (or even doing automatically at _every_ place where necessary without the user's intervention, I would say). From that point of view, Frank is right. > (and to be honnest to see the word "fontenc" on the left makes me = shudder > though I understand why Javier put it there originally; I think it is = a > horrible misinterpretation of what fontenc conceptually does) Yes, yes, using fontenc (as such) is conceptually an absurdity [that explains the (!) in the drawing]. Javier ------_=_NextPart_001_01C0DD19.3D600E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary 2.2

Frank wrote some days ago:

> as a result one ends up to have to explain all = those problems of
> misinterpreting the internal forms if you do = this or that at a certain stage
> (like storing text in a token register and = reusing it at some other point or
> never pass it to the hlist builder (where the = OTPs actually execute)

For some reason, I missed this paragraph when I first = read this
message and it's a good point. The problem is not = moving information
around, but explaining how to do it (or even doing = automatically at
_every_ place where necessary without the user's = intervention, I would
say). From that point of view, Frank is right.

> (and to be honnest to see the word = "fontenc" on the left makes me shudder
> though I understand why Javier put it there = originally; I think it is a
> horrible misinterpretation of what fontenc = conceptually does)

Yes, yes, using fontenc (as such) is conceptually an = absurdity [that
explains the (!) in the drawing].

Javier

------_=_NextPart_001_01C0DD19.3D600E00--