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 f1HFQBf01959 for ; Sat, 17 Feb 2001 16:26:11 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1HFQBd19677 . for ; Sat, 17 Feb 2001 16:26:11 +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 f1HFQ5H15622 for ; Sat, 17 Feb 2001 16:26:05 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C098F5.F4EDAB80" 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 QAA11853 for ; Sat, 17 Feb 2001 16:26:05 +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 f1HFQ3H15618 for ; Sat, 17 Feb 2001 16:26:05 +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 <12.C3DE9A40@mail.listserv.gmd.de>; Sat, 17 Feb 2001 16:25:55 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 489498 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sat, 17 Feb 2001 16:26:00 +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 QAA20012 for ; Sat, 17 Feb 2001 16:25:59 +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 QAA38498 for ; Sat, 17 Feb 2001 16:25:59 +0100 Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1HFQ0x29195 for ; Sat, 17 Feb 2001 16:26:00 +0100 (MET) Received: from [195.20.224.208] (helo=mrvdom01.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 14U9FA-0004Df-00 for LATEX-L@urz.uni-heidelberg.de; Sat, 17 Feb 2001 16:25:52 +0100 Received: from manz-3e364838.pool.mediaways.net ([62.54.72.56] helo=istrati.zdv.uni-mainz.de) by mrvdom01.schlund.de with esmtp (Exim 2.12 #2) id 14U9FC-0003Y5-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Sat, 17 Feb 2001 16:25:54 +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 QAA05692; Sat, 17 Feb 2001 16:22:49 +0100 In-Reply-To: <200102122049.f1CKnvi13875@smtp.wanadoo.es> References: <200102122049.f1CKnvi13875@smtp.wanadoo.es> 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: LaTeX's internal char prepresentation (UTF8 or Unicode?) Date: Sat, 17 Feb 2001 16:22:49 +0100 Message-ID: <14990.38729.339038.149023@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: 3951 This is a multi-part message in MIME format. ------_=_NextPart_001_01C098F5.F4EDAB80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable some shorter answers to Javier's mail: > [Marcel:] > > > Anyway, Frank, I just got your last mail in my inbox (need to = read the > > > details more carefully), and I think we agree that it's worth > > > exploring if there would be a substantial advantage for having = some > > > engine with Unicode internal reprentation. > > [Frank:] > > it surely is, though i'm not convinced that the time has come, = given that the > > current LICR actually is as powerful (or more powerful in fact) = than unicode > > ever can be. > > Please, could you explain why? I mean that the LICR is (conceptually) a superset of unicode; it can = encode any unicode character but also can encode characters not in unicode. = Clearly you can do that in Omega as well, but my point is that the LICR is = invariant to certain operations, eg writing to files and reading back in. > PS. I would also apologize for discussing a set of macros which > has not been made public yet, but remember it's only a i see no grounds for the need to apologize here since you are discussing = the basic concepts of LaTeX and or how you think they could or need to = bedeveloped further (to, say, be usable with Omega) > draft and many thing are liable to change (and maybe > the final code can be quite different. As we Spaniards say, if we would only discuss final code, that is not going to change, what = should we discuss, any why should we discuss it? actually a large part your implementation should rather be discussed on = this list rather than on the omega developers list since it concerns = derivation or extensions to LaTeX's user interface --- that is if you (plural, ie the = omega developers) want to keep LaTeX compatible with a LaTeX variant on Omega so i would really appreciate a discussion concerning its features and = proposed document interfaces on this list. clearly the actual implementation or = details very specific to Omega might not be that interesting, but how you model language in the source and what kind of designer/user modifications are possible etc are very interesting in general. I can only repeat what i wrote to the developer list: if we go separate = pathes now and produce incompatible versions so that documents from LaTeXonTeX can't be processed on LaTeXonOmega and vice versa[1] then this is = hurting everybody but mostly will have the danger of leaving Omega behind since = the majority of package that need to hook into language features will hook = into those provided by LaTeXonTeX since that has the bigger basis. ------- [1] that direction is of course only possible if one doesn't use = features of omega not available in TeX but for many languages and documents it = should and would be possible to run on both systems (even if the output is slightly different). frank ------_=_NextPart_001_01C098F5.F4EDAB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LaTeX's internal char prepresentation (UTF8 or = Unicode?)

some shorter answers to Javier's mail:

 > [Marcel:]
 > >  > Anyway, Frank, I just got = your last mail in my inbox (need to read the
 > >  > details more carefully), = and I think we agree that it's worth
 > >  > exploring if there would = be a substantial advantage for having some
 > >  > engine with Unicode = internal reprentation.
 > > [Frank:]
 > > it surely is, though i'm not = convinced that the time has come, given that the
 > > current LICR actually is as powerful = (or more powerful in fact) than unicode
 > > ever can be.
 >
 > Please, could you explain why?

I mean that the LICR is (conceptually) a superset of = unicode; it can encode
any unicode character but also can encode characters = not in unicode. Clearly
you can do that in Omega as well, but my point is = that the LICR is invariant
to certain operations, eg writing to files and = reading back in.


 > PS. I would also apologize for discussing a = set of macros which
 > has not been made public yet, but remember = it's only a

i see no grounds for the need to apologize here since = you are discussing the
basic concepts of LaTeX and or how you think they = could or need to bedeveloped
further (to, say, be usable with Omega)

 > draft and many thing are liable to change = (and maybe
 > the final code can be quite different. As = we Spaniards say,

if we would only discuss final code, that is not going = to change, what should
we discuss, any why should we discuss it?

actually a large part your implementation should = rather be discussed on this
list rather than on the omega developers list since = it concerns derivation or
extensions to LaTeX's user interface --- that is if = you (plural, ie the omega
developers) want to keep LaTeX compatible with a = LaTeX variant on Omega

so i would really appreciate a discussion concerning = its features and proposed
document interfaces on this list. clearly the actual = implementation or details
very specific to Omega might not be that interesting, = but how you model
language in the source and what kind of designer/user = modifications are
possible etc are very interesting in general.

I can only repeat what i wrote to the developer list: = if we go separate pathes
now and produce incompatible versions so that = documents from LaTeXonTeX
can't be processed on LaTeXonOmega and vice versa[1] = then this is hurting
everybody but mostly will have the danger of leaving = Omega behind since the
majority of package that need to hook into language = features will hook into
those provided by LaTeXonTeX since that has the = bigger basis.

-------
[1] that direction is of course only possible if one = doesn't use features of
omega not available in TeX but for many languages and = documents it should and
would be possible to run on both systems (even if the = output is slightly
different).

frank

------_=_NextPart_001_01C098F5.F4EDAB80--