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 f1DITeH27805 for ; Tue, 13 Feb 2001 19:29:40 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1DITed02394 . for ; Tue, 13 Feb 2001 19:29:40 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1DITd727905 for ; Tue, 13 Feb 2001 19:29:39 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C095EA.ED26C200" Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id TAA18534 for ; Tue, 13 Feb 2001 19:29:39 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1DITc727899 for ; Tue, 13 Feb 2001 19:29:38 +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 <9.C0390B38@mail.listserv.gmd.de>; Tue, 13 Feb 2001 19:29:30 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488800 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 13 Feb 2001 19:29:35 +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 TAA07842 for ; Tue, 13 Feb 2001 19:29:34 +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 TAA31880 for ; Tue, 13 Feb 2001 19:29:34 +0100 Received: from server-14.tower-4.starlabs.net (mail.london-1.starlabs.net [212.125.75.12]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with SMTP id f1DITXg06320 for ; Tue, 13 Feb 2001 19:29:33 +0100 (MET) Received: (qmail 16861 invoked from network); 13 Feb 2001 18:26:19 -0000 Received: from nagmx1e.nag.co.uk (HELO nag.co.uk) (62.232.54.130) by server-14.tower-4.starlabs.net with SMTP; 13 Feb 2001 18:26:19 -0000 Received: from penguin.nag.co.uk (IDENT:root@penguin.nag.co.uk [192.156.217.14]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id SAA21105 for ; Tue, 13 Feb 2001 18:29:25 GMT Received: by penguin.nag.co.uk (8.9.3) id SAA06291; Tue, 13 Feb 2001 18:29:24 GMT In-Reply-To: (message from Roozbeh Pournader on Tue, 13 Feb 2001 20:50:42 +0330) References: Return-Path: X-VirusChecked: Checked Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary Date: Tue, 13 Feb 2001 19:29:24 +0100 Message-ID: <200102131829.SAA06291@penguin.nag.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "David Carlisle" 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: 3889 This is a multi-part message in MIME format. ------_=_NextPart_001_01C095EA.ED26C200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Also, private use places are for interchange, not for internal > things. Internal things should use non-characters, I believe. Hmm a reasonable argument. Not sure I agree with it (just now) will think about that. > I can't see why it should limit additions, as long as old things work = as > they worked. Exactly. Having spent around 12 years distributing TeX code, I am convinced that there is no change ever made to anything related to TeX that has not broken a package (and thus a few hundred or thousand documents) somewhere. The TeX macro model is so open, the full implementation of every macro is available to be inspected by any other macro, that changing anything (just adding a \relax) will break something. There is no sense in which you can re-implement something with the same behaviour as the original unless it is identical. > On Windows, both MiKTeX and fpTeX have it. both web2c aren't they? > We're asking distributions to > support Omega, we're not asking users to use some certain = distributions. and Y&Y? and vtex and pctex and trutex (but trutex has omega I believe) (and on the Mac, textures? oztex?, and MVS mainfame?) some of the commercial systems have diverted greatly from the original Web source to offer things like dynamic memory allocation. probably they will move to a unicode based tex once sufficiently stable, but are you really ready to tell them to commit resources now? > We're talking about LaTeX3. The surgery will be needed for LaTeX3, = isn't > it? well, true. But if we are talking about changes that break everything we shouldn't try to fool ourselves with statements that "old things will work". > The two versions need lots of development time, Yes (finding time for one version is hard enough). I don't think there is any chance of having a replacement for LaTeX that was not going to work with pdftex (or pdfomega) as without pdftex a large part of the existing users wouldn't move to a new system and many uses for xml typesetting would be lost. Having a tex system that produces pdf with type1 fonts is so much more comforting to people who want to have tex as a black box typesetter for xml systems. Unless a system works with all the major tex distributions (either because it uses standard TeX, or because the TeX distributions distribute omega or pdftex or etex) it will never replace LaTeX for many purposes. So I can't see any alternative but to have parallel development paths. I'd like to work on both (but find it hard to work on either at present) On the other hand the two versions don't have to be completely different. For example xmltex shows that utf8, cjk and the others show utf8 handling isn't impossible with TeX. Given that one would presumably still have the \' syntax, and also ready composed unicode characters in many cases, just saying that combining characters don't work if running over a standard TeX wouldn't be the end of the world. David _____________________________________________________________________ This message has been checked for all known viruses by Star Internet = delivered through the MessageLabs Virus Control Centre. For further information = visit http://www.star.net.uk/stats.asp ------_=_NextPart_001_01C095EA.ED26C200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary

> Also, private use places are for interchange, not = for internal
> things. Internal things should use = non-characters, I believe.

Hmm a reasonable argument. Not sure I agree with it = (just now)
will think about that.

> I can't see why it should limit additions, as = long as old things work as
> they worked.

Exactly. Having spent around 12 years distributing TeX = code, I am
convinced that there is no change ever made to = anything related to TeX
that has not broken a package (and thus a few hundred = or thousand
documents) somewhere. The TeX macro model is so open, = the full
implementation of every macro is available to be = inspected by any other
macro, that changing anything (just adding a \relax) = will break
something. There is no sense in which you can = re-implement something
with the same behaviour as the original unless it is = identical.


> On Windows, both MiKTeX and fpTeX have it.
both web2c aren't they?

> We're asking distributions to
> support Omega, we're not asking users to use = some certain distributions.

and Y&Y? and vtex and pctex and trutex (but trutex = has omega I believe)
(and on the Mac, textures? oztex?, and MVS mainfame?) = some of
the commercial systems have diverted greatly from the = original Web
source to offer things like dynamic memory = allocation. probably they
will move to a unicode based tex once sufficiently = stable, but
are you really ready to tell them to commit resources = now?


> We're talking about LaTeX3. The surgery will be = needed for LaTeX3, isn't
> it?

well, true. But if we are talking about changes that = break everything
we shouldn't try to fool ourselves with statements = that "old things will
work".

> The two versions need lots of development = time,
Yes (finding time for one version is hard = enough).

I don't think there is any chance of having a = replacement for LaTeX
that was not going to work with pdftex (or pdfomega) = as without
pdftex a large part of the existing users wouldn't = move to a new system
and many  uses for xml typesetting would be = lost. Having a tex
system that produces pdf with type1 fonts is so much = more comforting to
people who want to have tex as a black box typesetter = for xml systems.

Unless a system works with all the major tex = distributions (either
because it uses standard TeX, or because the TeX = distributions
distribute omega or pdftex or etex) it will never = replace LaTeX for many
purposes.

So I can't see any alternative but to have parallel = development
paths. I'd like to work on both (but find it hard to = work on
either at present)

On the other hand the two versions don't have to be = completely
different. For example xmltex shows that utf8, cjk = and the others show
utf8 handling isn't impossible with TeX. Given that = one would presumably
still have the \' syntax, and also ready composed = unicode characters in
many cases, just saying that combining characters = don't work if running
over a standard TeX wouldn't be the end of the = world.

David



________________________________________________________________= _____
This message has been checked for all known viruses = by Star Internet delivered
through the MessageLabs Virus Control Centre. For = further information visit
http://www.star.net.uk/stats.as= p

------_=_NextPart_001_01C095EA.ED26C200--