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 f5BD9Qf12301 for ; Mon, 11 Jun 2001 15:09:26 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f5BD9Qp26505 . for ; Mon, 11 Jun 2001 15:09:26 +0200 MIME-Version: 1.0 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 f5BD9PU04778 for ; Mon, 11 Jun 2001 15:09:25 +0200 (MET DST) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F277.BD758700" 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 PAA06004 for ; Mon, 11 Jun 2001 15:09:24 +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 f5BD9OU04771 for ; Mon, 11 Jun 2001 15:09:24 +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 <8.A1DBDFC1@mail.listserv.gmd.de>; Mon, 11 Jun 2001 15:07:02 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 497672 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 11 Jun 2001 15:09:21 +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 PAA15896 for ; Mon, 11 Jun 2001 15:09:20 +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 PAA49274 for ; Mon, 11 Jun 2001 15:09:20 +0200 Received: from algonet.se (franklin.tninet.se [195.100.94.106]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f5BD9J113730 for ; Mon, 11 Jun 2001 15:09:20 +0200 (MET DST) Received: from [195.100.226.135] (du135-226.ppp.su-anst.tninet.se [195.100.226.135]) by franklin.tninet.se (BLUETAIL Mail Robustifier 2.2.2) with ESMTP id 236732.264951.992franklin-s2 for ; Mon, 11 Jun 2001 15:09:11 +0200 In-Reply-To: <15139.58926.526127.21111@localhost.localdomain> References: <15119.62808.151690.192812@gargle.gargle.HOWL> Return-Path: X-Sender: haberg@pop.matematik.su.se Content-class: urn:content-classes:message Subject: Re: \InputTranslation Date: Mon, 11 Jun 2001 14:07:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Hans Aberg" 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: 4123 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0F277.BD758700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 23:27 +0200 2001/06/10, Marcel Oliver wrote: >I don't think this means we have to support arbitrary encodings of >auxiliary files. Editing such files is, after all, undocumented >practice, and using an UTF8 editor will (rather elegantly) provide >full access to these files. Do we need more? As you say, it is the formats that editors can handle that is = controlling the formats that one wants to be able to have in the files. But what says that UTF8 is the preferred format of editors; what says = that they will not simply use Unicode? -- I do not know the editor market, = but I think one should check if UTF8 will be a format that every editor will = be able to handle, before excluding all other formats. Also, if the TeX successor has an input/output encoding mechanism which = is external to the TeX engine, then it can easily handle different = encodings in any type of text file. The question becomes fairly redundant as far = as LaTeX and TeX programming is concerned. Hans Aberg ------_=_NextPart_001_01C0F277.BD758700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: \InputTranslation

At 23:27 +0200 2001/06/10, Marcel Oliver wrote:
>I don't think this means we have to support = arbitrary encodings of
>auxiliary files.  Editing such files is, = after all, undocumented
>practice, and using an UTF8 editor will (rather = elegantly) provide
>full access to these files.  Do we need = more?

As you say, it is the formats that editors can handle = that is controlling
the formats that one wants to be able to have in the = files.

But what says that UTF8 is the preferred format of = editors; what says that
they will not simply use Unicode? -- I do not know = the editor market, but I
think one should check if UTF8 will be a format that = every editor will be
able to handle, before excluding all other = formats.

Also, if the TeX successor has an input/output = encoding mechanism which is
external to the TeX engine, then it can easily handle = different encodings
in any type of text file. The question becomes fairly = redundant as far as
LaTeX and TeX programming is concerned.

  Hans Aberg

------_=_NextPart_001_01C0F277.BD758700--