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 f1RFBuW07794 for ; Tue, 27 Feb 2001 16:11:56 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1RFBus27312 . for ; Tue, 27 Feb 2001 16:11:56 +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 f1RFBtQ23767 for ; Tue, 27 Feb 2001 16:11:55 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A0CF.9F708600" 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 QAA29885 for ; Tue, 27 Feb 2001 16:11:55 +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 f1RFBrQ23759 for ; Tue, 27 Feb 2001 16:11:54 +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 <7.6FC8E63E@mail.listserv.gmd.de>; Tue, 27 Feb 2001 16:11:42 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 494677 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 27 Feb 2001 16:11: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 QAA18070 for ; Tue, 27 Feb 2001 16:11: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 QAA24008 for ; Tue, 27 Feb 2001 16:11:43 +0100 Received: from knatte.tninet.se (knatte.tninet.se [195.100.94.10]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with SMTP id f1RFBhh12011 for ; Tue, 27 Feb 2001 16:11:43 +0100 (MET) Received: (qmail 25960 invoked from network); 27 Feb 2001 16:11:37 +0100 Received: from garibaldi.tninet.se (HELO algonet.se) (195.100.94.103) by knatte.tninet.se with SMTP; 27 Feb 2001 16:11:37 +0100 Received: from [195.100.226.142] (du142-226.ppp.su-anst.tninet.se [195.100.226.142]) by garibaldi.tninet.se (BLUETAIL Mail Robustifier 2.2.1) with ESMTP id 18384.286696.983garibaldi-s0 for ; Tue, 27 Feb 2001 16:11:36 +0100 In-Reply-To: <200102271007.KAA00521@penguin.nag.co.uk> References: (message from Hans Aberg on Mon, 26 Feb 2001 20:34:45 +0100) (message from Hans Aberg on Mon, 26 Feb 2001 16:37:33 +0100) (message from Hans Aberg on Fri, 23 Feb 2001 21:04:40 +0100) (message from Barbara Beeton on Fri, 23 Feb 2001 11:16:42 -0500) Return-Path: X-Sender: haberg@pop.matematik.su.se Content-class: urn:content-classes:message Subject: Re: LaTeX's internal char prepresentation (UTF8 or Unicode?) Date: Tue, 27 Feb 2001 16:10:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Hans Aberg" 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: 4023 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0A0CF.9F708600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 10:07 +0000 2001/02/27, David Carlisle wrote: >> Yes I did (apart from the fact that I could find no convenient = archive to >> pick them down, making the process excruciatingly slow on my = computer). > >There's a zip file of the spec linked from the front page. Well, I got the MathML spec, but it did not contain any glyphs. >You may also prefer the PDF charts available from the unicode.org site. I looked at that site, but I could not find suitably bundled PDF files. = (I am not sure it is so important anymore, as I found out what I wanted.) >> I think these should be >But that isn't the way ISO works. Well, as for the addition of math font shapes, it works so, because I = was the guy pointing out that it ought to be, in view of the math semantics. > It works by international ballot and >negotiation over a period of several years... (Just for this one >submission for math characters) But somehow it snowballed in another direction, it seems. :-) >> But perhaps Unicode has already made up its mind, so there is nothing = to do >> about it... > >Not quite, but almost. Well, I am not sure it's worth bother about it: On the one hand, it would be nice having access to the glyphs that might = be used in math. But on the other hand, if one should do anything along the line I suggested, one would have to rip out all the 1024 character positions, = with a new suggestion, and as you say re-vote... -- I can slip a remark about monospaced fonts here though: It seems me that the only(?) reason one is using a monospaced font in computer science, is in order to get the text properly aligned. So, if = one somehow can get a better tab alignment system, there would be no need of using a monospaced font. In fact, I have some (old) computer books where the code (in Pascal) is using normal (non-monospaced) fonts. And I recall that Unicode has = better tabs. (And books on parsers I looked into use normal math conventions, = that is, the use of fonts style with normal fonts in order to indicate semantics.) Perhaps LaTeX, as an alternative to a "verbatim" mode, should have an environment where merely the indentations using spaces are translated = into suitable tab alignments, but otherwise one is using normal = (non-monospaced fonts). Hans Aberg ------_=_NextPart_001_01C0A0CF.9F708600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LaTeX's internal char prepresentation (UTF8 or = Unicode?)

At 10:07 +0000 2001/02/27, David Carlisle = wrote:
>> Yes I did (apart from the fact that I could = find no convenient archive to
>> pick them down, making the process = excruciatingly slow on my computer).
>
>There's a zip file of the spec linked from the = front page.

Well, I got the MathML spec, but it did not contain = any glyphs.

>You may also prefer the PDF charts available from = the unicode.org site.

I looked at that site, but I could not find suitably = bundled PDF files. (I
am not sure it is so important anymore, as I found = out what I wanted.)

>> I think these should be
>But that isn't the way ISO works.

Well, as for the addition of math font shapes, it = works so, because I was
the guy pointing out that it ought to be, in view of = the math semantics.

> It works by international ballot and
>negotiation over a period of several years... = (Just for this one
>submission for math characters)

But somehow it snowballed in another direction, it = seems. :-)

>> But perhaps Unicode has already made up its = mind, so there is nothing to do
>> about it...
>
>Not quite, but almost.

Well, I am not sure it's worth bother about it:

On the one hand, it would be nice having access to the = glyphs that might be
used in math.

But on the other hand, if one should do anything along = the line I
suggested, one would have to rip out all the 1024 = character positions, with
a new suggestion, and as you say re-vote...

-- I can slip a remark about monospaced fonts here = though:

It seems me that the only(?) reason one is using a = monospaced font in
computer science, is in order to get the text = properly aligned. So, if one
somehow can get a better tab alignment system, there = would be no need of
using a monospaced font.

In fact, I have some (old) computer books where the = code (in Pascal) is
using normal (non-monospaced) fonts. And I recall = that Unicode has better
tabs. (And books on parsers I looked into use normal = math conventions, that
is, the use of fonts style with normal fonts in order = to indicate
semantics.)

Perhaps LaTeX, as an alternative to a = "verbatim" mode, should have an
environment where merely the indentations using = spaces are translated into
suitable tab alignments, but otherwise one is using = normal (non-monospaced
fonts).

  Hans Aberg

------_=_NextPart_001_01C0A0CF.9F708600--