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 f1DHL8H27239 for ; Tue, 13 Feb 2001 18:21:08 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1DHL8d02151 . for ; Tue, 13 Feb 2001 18:21:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C095E1.5A355A00" 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 f1DHL2721992 for ; Tue, 13 Feb 2001 18:21:02 +0100 (MET) 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 SAA03090 for ; Tue, 13 Feb 2001 18:21:02 +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 mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1DHL1721986 for ; Tue, 13 Feb 2001 18:21:01 +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 <3.2A90624C@mail.listserv.gmd.de>; Tue, 13 Feb 2001 18:20:54 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488709 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 13 Feb 2001 18:20:57 +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 SAA06650 for ; Tue, 13 Feb 2001 18:20:56 +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 SAA39820 for ; Tue, 13 Feb 2001 18:20:54 +0100 Received: from Sina.sharif.ac.ir (sina.Sharif.AC.IR [194.225.40.9]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1DHKlg00643 for ; Tue, 13 Feb 2001 18:20:48 +0100 (MET) Received: from localhost (roozbeh@localhost) by Sina.sharif.ac.ir (8.9.3/8.9.3) with ESMTP id UAA07828 for ; Tue, 13 Feb 2001 20:50:43 +0330 In-Reply-To: <200102131655.QAA05656@penguin.nag.co.uk> Return-Path: X-Sender: roozbeh@Sina.sharif.ac.ir Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary Date: Tue, 13 Feb 2001 18:20:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Roozbeh Pournader" 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: 3883 This is a multi-part message in MIME format. ------_=_NextPart_001_01C095E1.5A355A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue, 13 Feb 2001, David Carlisle wrote: > > With math yes, but with other things no, the model is getting = stable. > It's not just math. 40000 (I think) Chinese characters just got added. > Unicode 2 was one plane of 2^16. Uniocde 3 is 17 planes of 2^16. > that's a lot of new slots for people to suggest ways to fill, it will = grow. I was talking about the model. I believe that more characters but fewer mechanisms are going to be added to Unicode (excluding math). > Going above 10FFFF might be dangerous (if you ever wanted a feature to > output the internal state you'd have problems) but plane 13 and 14 are > empty for private use, which is 2^17 spare slots, which ought to be > enough. For outputting internal state, one should use numerical codes or = something like that. That's even more debuggable. Also, private use places are for interchange, not for internal things. Internal things should use non-characters, I believe. > a) this might require omega to be more stable than omega users would > wish, ie it might prematurely limit addition of new features. I can't see why it should limit additions, as long as old things work as they worked. > b) it would cut out people using tex systems that don't include omega. > You might say they should all switch to web2c tex, but that's like > saying that everyone should use emacs on linux. Clearly it's true, but > it doesn't happen that way. On Windows, both MiKTeX and fpTeX have it. We're asking distributions to support Omega, we're not asking users to use some certain distributions. > d) It would require reasonably major surgery to LaTeX internals. It > would be possible to make documents and packages using "documented > interfaces" still work with a new internal character handling, but > ctan will reveal a lot of heavily used packages that for good (or bad) > reasons don't use documented interfaces, but just redefine arbitrary > macros. (Often because there isn't a documented interface). > A lot of these would break. We're talking about LaTeX3. The surgery will be needed for LaTeX3, isn't it? > So in short to medium term it seems there have to be two versions > latex/omega and latex/tex. How compatible they can be as latex/omega > uses more omega features I am not sure. There is some point I should mention: almost all TeX-world people have made themselves very busy, so they have much less time for TeX development these days. The two versions need lots of development time, so the thing (internationalized LaTeX with PDF and everything) will have to wait a long time. --roozbeh ------_=_NextPart_001_01C095E1.5A355A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary

On Tue, 13 Feb 2001, David Carlisle wrote:

> > With math yes, but with other things no, the = model is getting stable.
> It's not just math. 40000 (I think) Chinese = characters just got added.
> Unicode 2 was one plane of 2^16. Uniocde 3 is 17 = planes of 2^16.
> that's a lot of new slots for people to suggest = ways to fill, it will grow.

I was talking about the model. I believe that more = characters but fewer
mechanisms are going to be added to Unicode = (excluding math).

> Going above 10FFFF might be dangerous (if you = ever wanted a feature to
> output the internal state you'd have problems) = but plane 13 and 14 are
> empty for private use, which is 2^17 spare = slots, which ought to be
> enough.

For outputting internal state, one should use = numerical codes or something
like that. That's even more debuggable.

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

> a) this might require omega to be more stable = than omega users would
> wish, ie it might prematurely limit addition of = new features.

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

> b) it would cut out people using tex systems that = don't include omega.
> You might say they should all switch to web2c = tex, but that's like
> saying that everyone should use emacs on linux. = Clearly it's true, but
> it doesn't happen that way.

On Windows, both MiKTeX and fpTeX have it. We're = asking distributions to
support Omega, we're not asking users to use some = certain distributions.

> d) It would require reasonably major surgery to = LaTeX internals. It
> would be possible to make documents and packages = using "documented
> interfaces" still work with a new internal = character handling, but
> ctan will reveal a lot of heavily used packages = that for good (or bad)
> reasons don't use documented interfaces, but = just redefine arbitrary
> macros. (Often because there isn't a documented = interface).
> A lot of these would break.

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

> So in short to medium term it seems there have to = be two versions
> latex/omega and latex/tex. How compatible they = can be as latex/omega
> uses more omega features I am not sure.

There is some point I should mention: almost all = TeX-world people have
made themselves very busy, so they have much less = time for TeX
development these days. The two versions need lots of = development time,
so the thing (internationalized LaTeX with PDF and = everything) will have
to wait a long time.

--roozbeh

------_=_NextPart_001_01C095E1.5A355A00--