Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Sat, 1 Feb 2003 04:11:21 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h113BI6D011381 for ; Sat, 1 Feb 2003 04:11:19 +0100 Received: from exfront2.zdv.uni-mainz.de (exfront2.zdv.Uni-Mainz.DE [134.93.8.76]) by mailgate1.zdv.Uni-Mainz.DE (8.12.6/8.12.6) with ESMTP id h113BFZK008531 for ; Sat, 1 Feb 2003 04:11:17 +0100 (MET) Received: from spamgate2.zdv.Uni-Mainz.DE ([134.93.8.232]) by exfront2.zdv.uni-mainz.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 1 Feb 2003 04:07:39 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C99F.982F1280" Received: from mailgate3.zdv.Uni-Mainz.DE (mailgate3.zdv.Uni-Mainz.DE [134.93.130.78]) by spamgate2.zdv.Uni-Mainz.DE (8.12.6/8.12.2) with ESMTP id h11377Jw012616 for ; Sat, 1 Feb 2003 04:07:07 +0100 (MET) Received: from tug.org (tug.org [130.225.2.178]) by mailgate3.zdv.Uni-Mainz.DE (8.12.6/8.12.6) with ESMTP id h11375S0029348 for ; Sat, 1 Feb 2003 04:07:06 +0100 (MET) Received: from tug.org (localhost.localdomain [127.0.0.1]) by tug.org (8.11.6/8.11.6) with ESMTP id h112bAx22947; Sat, 1 Feb 2003 03:37:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mutant.triumf.ca (mutant.Triumf.CA [142.90.112.22]) by tug.org (8.11.6/8.11.6) with ESMTP id h112aix22929 for ; Sat, 1 Feb 2003 03:36:45 +0100 Received: (from asnd@localhost) by mutant.triumf.ca (8.9.3/8.9.3) id SAA03278; Fri, 31 Jan 2003 18:38:30 -0800 In-Reply-To: Peter Schmitt's message of "Fri, 31 Jan 2003 16:05:27 +0100(CET)" Lines: 63 Organization: TRIUMF: Canada's national meson facility References: Return-Path: X-OriginalArrivalTime: 01 Feb 2003 03:07:39.0081 (UTC) FILETIME=[13E8EB90:01C2C99F] List-Id: List-Post: Errors-To: tex-implementors-bounces@tug.org X-BeenThere: tex-implementors@tug.org X-Mailman-Version: 2.1 List-Archive: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Authentication-Warning: mutant.triumf.ca: asnd set sender to asnd@triumf.causing -f X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -4.8 () EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA,X_AUTH_WARNING X-Spam-Report: CARRIAGE_RETURNS,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_GNUS_UA,X_AUTH_WARNING Content-class: urn:content-classes:message Subject: Re: [tex-implementors] TeX+locale, solution? Date: Sat, 1 Feb 2003 03:38:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tex-implementors] TeX+locale, solution? Thread-Index: AcLJn5khJznm7MBHQ1mG4aq2Oh01Hg== List-Help: List-Subscribe: , List-Unsubscribe: , From: "Donald Arseneau" To: "Peter Schmitt" Cc: Status: R X-Status: X-Keywords: X-UID: 4518 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C99F.982F1280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter Schmitt writes: > On 30 Jan 2003, Donald Arseneau wrote: >=20 > > I remember TeX on an ebcdic computer which had (quite correctly) > > a mapping of input characters to the canonical TeX-ascii set > > (including the logical-not sign for tilde). The transformation > > was compiled-in. > > > If I remember it correctly, transferring a text file to an ebcdic = computer > required recoding, even if no special characters like umlauts were > used. Yes. It is very non-ascii. > But -- TeX being platform independent -- I still would have expected > compiling a tex file to produce the same .dvi. > It seems, I would have been wrong? Sorry! I didn't mean the dvi file was in ebcdic (but the printer drivers had to do the TeX-ascii to ebcdic conversion). I was just referring to the standard IO affected by the encoding vector \input, \read, \write, .log, that we are discussing in this thread. > > simply *must* respect this. To ignore locale would be the > > same as requiring ascii TeX on an ebcdic computer. > > > Must it? Yes, if it supports one case it must support the other, because they are really the *same thing*. > Platform (and time/fashion) independence is a major feature of TeX Nonsense. As I am saying, there have always been different TeXs with different I/O translations to suit the local installation. Originally, it required a recompile to change the translation table. Later, it became possible to select a translation on the command line. Given that the translations exist, it makes the most sense=20 to use the standard mechanism for choosing it: locale. > which gets lost if you cannot transfer a file > (plus its format/macro files) from one computer to another. Of course you can transfer files. You don't transfer the binary=20 image of the file; you transfer the information. Files with different=20 encodings get automatically translated all the time for transfer. Yes there are glitches when people do it wrong, but that is not reason enough to force everyone to work in some TeX-standard but unnatural encoding. It is the same with ascii/ebcdic and CR/CRLF/LF line endings: people have to transfer files in text mode, not as binary images. =20 > should be done explicitly and _within_ TeX (format or style), > and the default should be "no conversion". No, what your scheme requires is that the encoding be specified within the document, or that "no conversion" is the only option. Otherwise, files from elsewhere (transferred as images in your world) could not be processed. =20 Donald Arseneau asnd@triumf.ca _______________________________________________ tex-implementors mailing list postmaster@tug.org http://tug.org/mailman/listinfo/tex-implementors ------_=_NextPart_001_01C2C99F.982F1280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [tex-implementors] TeX+locale, solution?

Peter Schmitt <schmitt@ap.univie.ac.at> = writes:

> On 30 Jan 2003, Donald Arseneau wrote:
>
> > I remember TeX on an ebcdic computer which = had (quite correctly)
> > a mapping of input characters to the = canonical TeX-ascii set
> > (including the logical-not sign for = tilde).  The transformation
> > was compiled-in.
> >
> If I remember it correctly, transferring a text = file to an ebcdic computer
>   required recoding, even if no = special characters like umlauts were
>   used.

Yes.  It is very non-ascii.

> But -- TeX being platform independent -- I still = would have expected
>   compiling a tex file to produce the = same .dvi.
>   It seems, I would have been = wrong?

Sorry!  I didn't mean the dvi file was in ebcdic = (but the printer
drivers had to do the TeX-ascii to ebcdic = conversion).  I was
just referring to the standard IO affected by the = encoding vector
\input, \read, \write, .log, that we are discussing = in this thread.

> > simply *must* respect this.  To ignore = locale would be the
> > same as requiring ascii TeX on an ebcdic = computer.
> >
> Must it?

Yes, if it supports one case it must support the = other, because they
are really the *same thing*.

>  Platform (and time/fashion) independence is = a major feature of TeX

Nonsense.  As I am saying, there have always been = different TeXs
with different I/O translations to suit the local = installation.
Originally, it required a recompile to change the = translation table.
Later, it became possible to select a translation on = the command
line.  Given that the translations exist, it = makes the most sense
to use the standard mechanism for choosing it: = locale.

>  which gets lost if you cannot transfer a = file
>  (plus its format/macro files) from one = computer to another.

Of course you can transfer files. You don't transfer = the binary
image of the file; you transfer the = information.  Files with different
encodings get automatically translated all the time = for transfer.
Yes there are glitches when people do it wrong, but = that is not
reason enough to force everyone to work in some = TeX-standard but
unnatural encoding.  It is the same with = ascii/ebcdic and CR/CRLF/LF
line endings: people have to transfer files in text = mode, not
as binary images. 

>  should be done explicitly and _within_ TeX = (format or style),
>  and the default should be "no = conversion".

No, what your scheme requires is that the encoding be = specified
within the document, or that "no = conversion" is the only option.
Otherwise, files from elsewhere (transferred as = images in your world)
could not be processed. 


Donald = Arseneau           = ;            =    asnd@triumf.ca
_______________________________________________
tex-implementors mailing list
postmaster@tug.org
http://tug.org/= mailman/listinfo/tex-implementors

------_=_NextPart_001_01C2C99F.982F1280--