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 f1EETFH00489 for ; Wed, 14 Feb 2001 15:29:15 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1EETEd06488 . for ; Wed, 14 Feb 2001 15:29:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09692.81982F80" 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 f1EETE715197 for ; Wed, 14 Feb 2001 15:29:14 +0100 (MET) 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 PAA26094 for ; Wed, 14 Feb 2001 15:29:13 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 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 f1EETDM01044 for ; Wed, 14 Feb 2001 15:29:13 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <0.54191D9E@mail.listserv.gmd.de>; Wed, 14 Feb 2001 15:29:05 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488569 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Wed, 14 Feb 2001 15:29:09 +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 PAA22352 for ; Wed, 14 Feb 2001 15:29:06 +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 PAA56978 for ; Wed, 14 Feb 2001 15:29:04 +0100 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 f1EET4x05803 for ; Wed, 14 Feb 2001 15:29:04 +0100 (MET) Received: from [62.36.81.109] (usuario2-36-81-109.dialup.uni2.es [62.36.81.109]) by smtp.wanadoo.es (8.10.2/8.10.2) with ESMTP id f1EESxg25563 for ; Wed, 14 Feb 2001 15:28:59 +0100 (MET) Return-Path: X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary Date: Wed, 14 Feb 2001 15:26:44 +0100 Message-ID: <200102141428.f1EESxg25563@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: 3922 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09692.81982F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > This does bring us to the point about "internal representation". > TeX has different levels of internals, and at the level where it = builds > a horizontal list (as opposed to the higher level of the macro = definitions) > the character tokens must map directly to the corresponding font. > Some can call this a lack of distinct internal representation. > Others can say the relevant representation is in the macros (as > with inputenc). Still others can say TeX's internal representation > is independent because of virtual fonts. Maybe "internal representation" is not the right term and more accurate expressions should be introduced: - protected expansion: the "representation" when we say things \protected@edef or write to a file. - full expansion: as done by \edef, but of little interest here. - evaluation: when all token are finally expanded, except primitives which are evaluated and chars which are added to the dvi file. In TeX, only the protected expansion is under our control. In Omega we can control evaluation somehow. Once tokens are expanded, primitives are evaluated as in TeX, but chars can be further processed using ocp's (if the result contains macros, they are expanded and evaluated in turn, and so on). I'm realizing that perhaps Frank and I are speaking of different "internal representations" since I think he refers to protected expansion while I refer to evaluation. In fact, in the draft I've written protected expansion preserves \" and the like, which are converted to Unicode chars only on evaluation. In other words, things like \"e are preserved when written to the aux file or moved around. Frank, what do you think? Javier ------_=_NextPart_001_01C09692.81982F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary

> This does bring us to the point about = "internal representation".
> TeX has different levels of internals, and at = the level where it builds
> a horizontal list (as opposed to the higher = level of the macro definitions)
> the character tokens must map directly to the = corresponding font.
> Some can call this a lack of distinct internal = representation.
> Others can say the relevant representation is in = the macros (as
> with inputenc).  Still others can say TeX's = internal representation
> is independent because of virtual fonts.

Maybe "internal representation" is not the = right term and more
accurate expressions should be introduced:
 - protected expansion: the = "representation" when we say things
   \protected@edef or write to a = file.
 - full expansion: as done by \edef, but of = little interest here.
 - evaluation: when all token are finally = expanded, except primitives
   which are evaluated and chars which are = added to the dvi file.

In TeX, only the protected expansion is under our = control. In Omega
we can control evaluation somehow. Once tokens are = expanded, primitives
are evaluated as in TeX, but chars can be further = processed using
ocp's (if the result contains macros, they are = expanded and evaluated
in turn, and so on).

I'm realizing that perhaps Frank and I are speaking of = different
"internal representations" since I think he = refers to protected
expansion while I refer to evaluation. In fact, in = the draft
I've written protected expansion preserves \" = and the like, which
are converted to Unicode chars only on evaluation. In = other words,
things like \"e are preserved when written to = the aux file or
moved around.

Frank, what do you think?

Javier

------_=_NextPart_001_01C09692.81982F80--