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 f4DM0Rf18485 for ; Mon, 14 May 2001 00:00:27 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f4DM0R718057 . for ; Mon, 14 May 2001 00:00:27 +0200 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 f4DM0LU10208 for ; Mon, 14 May 2001 00:00:21 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DBF8.1E1D8F80" 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 AAA01374 for ; Mon, 14 May 2001 00:00:21 +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 mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f4DM0LU10203 for ; Mon, 14 May 2001 00:00:21 +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 <5.1B4B91C1@mail.listserv.gmd.de>; Sun, 13 May 2001 23:58:44 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 495096 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 14 May 2001 00:00:17 +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 XAA07174 for ; Sun, 13 May 2001 23:58:11 +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 XAA46168 for ; Sun, 13 May 2001 23:58:12 +0200 Received: from mail.umu.se (custer.umdac.umu.se [130.239.8.14]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f4DLwAQ18853 for ; Sun, 13 May 2001 23:58:10 +0200 (MET DST) Received: from [130.239.137.13] (mariehemsv093.sn.umu.se [130.239.137.13]) by mail.umu.se (8.8.8/8.8.8) with ESMTP id XAA10280; Sun, 13 May 2001 23:58:11 +0200 (MET DST) In-Reply-To: References: <200105112029.f4BKT3707962@smtp.wanadoo.es> Return-Path: X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id XAA07176 Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary 2.2 Date: Sun, 13 May 2001 22:58:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: =?iso-8859-1?Q?Lars_Hellstr=F6m?= 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: 4055 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0DBF8.1E1D8F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 21.32 +0200 2001-05-13, Hans Aberg wrote: >At 15:18 +0200 2001/05/13, Lars Hellstr=F6m wrote: >>Well, the \InputTranslation and \OutputTranslation primitives of Omega >>already provide that functionality, so there is no need to deal with >>variable-sized characters in the TeX programming. The problem is that = one >>might want to employ additional sets of translations (which would then = act >>on streams of equally-sized characters) between those extremes of the >>program, but Omega doesn't provide for this. > >I am not sure what you mean here: UTF-8 is variable sized. > >I suggested that for every file not using a 32-bit character type, one = has >an additional file (in ASCII) identified by some kind of file name = ending >with information about the encoding. (For example, if the file "" = is >not 32-bit, is there si also an ASCII file named ".encoding".) > >This way, one can provide as many IO code converters as one bothers to >write, without the extended TeX ever knows anything about it. (If Omega >uses C++ for IO, one can use something called a codecvt. Or use pipes, >where available.) Read Sections 8--12 (Section 12 in particular) of the Omega draft documentation---that will answer you question more thoroughly that I = bother to do right now. Marcel's summary contains a reference to it. But in = short the equivalent functionality is already implemented (without resorting = to language or platform specific mechanisms such as those you mention). Lars Hellstr=F6m ------_=_NextPart_001_01C0DBF8.1E1D8F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary 2.2

At 21.32 +0200 2001-05-13, Hans Aberg wrote:
>At 15:18 +0200 2001/05/13, Lars Hellstr=F6m = wrote:
>>Well, the \InputTranslation and = \OutputTranslation primitives of Omega
>>already provide that functionality, so there = is no need to deal with
>>variable-sized characters in the TeX = programming. The problem is that one
>>might want to employ additional sets of = translations (which would then act
>>on streams of equally-sized characters) = between those extremes of the
>>program, but Omega doesn't provide for = this.
>
>I am not sure what you mean here: UTF-8 is = variable sized.
>
>I suggested that for every file not using a = 32-bit character type, one has
>an additional file (in ASCII) identified by some = kind of file name ending
>with information about the encoding. (For = example, if the file "<name>" is
>not 32-bit, is there si also an ASCII file named = "<name>.encoding".)
>
>This way, one can provide as many IO code = converters as one bothers to
>write, without the extended TeX ever knows = anything about it. (If Omega
>uses C++ for IO, one can use something called a = codecvt. Or use pipes,
>where available.)

Read Sections 8--12 (Section 12 in particular) of the = Omega draft
documentation---that will answer you question more = thoroughly that I bother
to do right now. Marcel's summary contains a = reference to it. But in short
the equivalent functionality is already implemented = (without resorting to
language or platform specific mechanisms such as = those you mention).

Lars Hellstr=F6m

------_=_NextPart_001_01C0DBF8.1E1D8F80--