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 f1ECSoH31486 for ; Wed, 14 Feb 2001 13:28:50 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1ECSnd06034 . for ; Wed, 14 Feb 2001 13:28:49 +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 f1ECSnM19325 for ; Wed, 14 Feb 2001 13:28:49 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09681.AF28AD00" 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 NAA21476 for ; Wed, 14 Feb 2001 13:28:48 +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 f1ECSlM19318 for ; Wed, 14 Feb 2001 13:28:48 +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.8204F6EB@mail.listserv.gmd.de>; Wed, 14 Feb 2001 13:28:40 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488403 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Wed, 14 Feb 2001 13:28:44 +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 NAA19987 for ; Wed, 14 Feb 2001 13:28:43 +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 NAA37592 for ; Wed, 14 Feb 2001 13:28:32 +0100 Received: from ns.mccme.ru (ns.mccme.ru [195.133.68.22]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1ECSVx24107 for ; Wed, 14 Feb 2001 13:28:31 +0100 (MET) Received: from cherepan.UUCP (uucp@localhost) by ns.mccme.ru (8.8.5/8.8.5) with UUCP id PAA09710 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Wed, 14 Feb 2001 15:07:51 +0300 Received: by cherepan.mccme.ru (dMail for DOS v2.07b5, 02Jan00); Wed, 14 Feb 2001 15:22:30 +0300 Lines: 22 References: <3A8A1B63.1803CD0F@triumf.ca> Return-Path: X-Mailer: dMail [Demos Mail for DOS v2.07b5] Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary Date: Wed, 14 Feb 2001 13:22:30 +0100 Message-ID: <2.07b5.OEUX.G8QYDI@cherepan.mccme.ru> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Alexander Cherepanov" 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: 3919 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09681.AF28AD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 13-Feb-01 21:45 Donald Arseneau wrote: >> > - TeX diagnostic messages output the "internal representation", = which >> > can quickly become unreadable for scripts that are not = essentially >> > ASCII. >> >> which diagnostics we are talking about here? some of them are in the = font >> encoding (which is not the LICR at all) > I agree. This is not the issue. In fact, it is only an issue for > system configuration! Most TeX implementations now allow messages > to be printed without conversion to ^^ format. On the other hand, if input and font encodings are different then errors = in .tex file will be shown in one encoding while overfull messages in = another. So this is an argument for switching from TeX to another engine which doesn't have such a problem. Does Omega have this problem? Personally, I use tcx and quite happy with traditional TeX. Best regards, Sasha ------_=_NextPart_001_01C09681.AF28AD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary

13-Feb-01 21:45 Donald Arseneau wrote:
>>  > - TeX diagnostic messages output = the "internal representation", which
>>  >   can quickly become = unreadable for scripts that are not essentially
>>  >   ASCII.
>>
>> which diagnostics we are talking about here? = some of them are in the font
>> encoding (which is not the LICR at = all)

> I agree.  This is not the issue.  In = fact, it is only an issue for
> system configuration!  Most TeX = implementations now allow messages
> to be printed without conversion to ^^ = format.

On the other hand, if input and font encodings are = different then errors in
.tex file will be shown in one encoding while = overfull messages in another.
So this is an argument for switching from TeX to = another engine which
doesn't have such a problem. Does Omega have this = problem?

Personally, I use tcx and quite happy with traditional = TeX.

Best regards,
Sasha

------_=_NextPart_001_01C09681.AF28AD00--