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 f1BLZjH12243 for ; Sun, 11 Feb 2001 22:35:45 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1BLZjd26420 . for ; Sun, 11 Feb 2001 22:35:45 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09472.972F0E80" 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 f1BLZi727949 for ; Sun, 11 Feb 2001 22:35:44 +0100 (MET) 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 WAA00854 for ; Sun, 11 Feb 2001 22:35:44 +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 f1BLZiM16573 for ; Sun, 11 Feb 2001 22:35:44 +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 <12.6B3779A2@mail.listserv.gmd.de>; Sun, 11 Feb 2001 22:35:37 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 487831 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sun, 11 Feb 2001 22:35:36 +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 WAA27805 for ; Sun, 11 Feb 2001 22:35: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 WAA25138 for ; Sun, 11 Feb 2001 22:35:35 +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 f1BLZQu02173 for ; Sun, 11 Feb 2001 22:35:29 +0100 (MET) Received: from localhost (roozbeh@localhost) by Sina.sharif.ac.ir (8.9.3/8.9.3) with ESMTP id BAA20024 for ; Mon, 12 Feb 2001 01:05:20 +0330 In-Reply-To: <14982.59968.683159.480912@istrati.zdv.uni-mainz.de> Return-Path: X-Sender: roozbeh@Sina.sharif.ac.ir Content-class: urn:content-classes:message Subject: Re: LaTeX's internal char prepresentation (UTF8 or Unicode?) Date: Sun, 11 Feb 2001 22:35:20 +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: 3824 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09472.972F0E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sun, 11 Feb 2001, Frank Mittelbach wrote: > - it clearly can't provide the answer for chars not existing in = unicode There are also ones that will most probably never get into Unicode, like the dotless j. > - and it clearly can't provide the answer for math Unicode recommends modifiers for the unified math symbols, which will become something like \mathmakelonger{\rightarrow} internally. > yes and no, I tried to explain that there are limitations posed by the = current > implementation of the major underlying formatter (ie TeX) which you = can't > easily overcome and even if you do: which then needs a long time to = get > actually being deployed at sites that have not much use for anything = other > than ASCII plus perhaps a few accents. I understand. But the situation is different now. These days, developers do something interesting: they add an eye candy features (take support = for some new image format in YAP), and they user updates the whole system = and automatically gets all latest things. --roozbeh ------_=_NextPart_001_01C09472.972F0E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LaTeX's internal char prepresentation (UTF8 or = Unicode?)

On Sun, 11 Feb 2001, Frank Mittelbach wrote:

>  - it clearly can't provide the answer for = chars not existing in unicode

There are also ones that will most probably never get = into Unicode, like
the dotless j.

>  - and it clearly can't provide the answer = for math

Unicode recommends modifiers for the unified math = symbols, which will
become something like \mathmakelonger{\rightarrow} = internally.

> yes and no, I tried to explain that there are = limitations posed by the current
> implementation of the major underlying formatter = (ie TeX) which you can't
> easily overcome and even if you do: which then = needs a long time to get
> actually being deployed at sites that have not = much use for anything other
> than ASCII plus perhaps a few accents.

I understand. But the situation is different now. = These days, developers
do something interesting: they add an eye candy = features (take support for
some new image format in YAP), and they user updates = the whole system and
automatically gets all latest things.

--roozbeh

------_=_NextPart_001_01C09472.972F0E80--