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 f4MAcOf30621 for ; Tue, 22 May 2001 12:38:24 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f4MAcN700335 . for ; Tue, 22 May 2001 12:38:24 +0200 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 f4MAcN023848 for ; Tue, 22 May 2001 12:38:23 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E2AB.53D31000" 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 MAA17613 for ; Tue, 22 May 2001 12:38:23 +0200 (MEST) 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 f4MAcM023843 for ; Tue, 22 May 2001 12:38:22 +0200 (MET DST) 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 <1.4AF266AB@mail.listserv.gmd.de>; Tue, 22 May 2001 12:36:31 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 496372 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 22 May 2001 12:07:25 +0200 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 MAA19485 for ; Tue, 22 May 2001 12:07:22 +0200 (MET DST) Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id MAA140470 for ; Tue, 22 May 2001 12:07:22 +0200 Received: from musse.tninet.se (musse.tninet.se [195.100.94.12]) by relay2.uni-heidelberg.de (8.10.2+Sun/8.10.2) with SMTP id f4MA7Is16952 for ; Tue, 22 May 2001 12:07:22 +0200 (MET DST) Received: (qmail 1020 invoked from network); 22 May 2001 12:05:46 +0200 Received: from garibaldi.tninet.se (HELO algonet.se) (195.100.94.103) by musse.tninet.se with SMTP; 22 May 2001 12:05:46 +0200 Received: from [195.100.226.136] (du136-226.ppp.su-anst.tninet.se [195.100.226.136]) by garibaldi.tninet.se (BLUETAIL Mail Robustifier 2.2.2) with ESMTP id 484578.525943.990garibaldi-s2 for ; Tue, 22 May 2001 12:05:43 +0200 In-Reply-To: References: <15112.62969.545010.438829@gargle.gargle.HOWL> <15111.36254.279748.954703@hoelderlin.localdomain> <200105161742.MAA02503@riemann.math.twsu.edu> Return-Path: X-Sender: haberg@pop.matematik.su.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id MAA19486 Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary 2.2 Date: Tue, 22 May 2001 11:04: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: 4100 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E2AB.53D31000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 23:20 +0200 2001/05/21, Lars Hellstr=F6m wrote: >>Could you define the _problem_ you are trying to solve? > >...On one side, the problem is that in LaTeX today, I'm not >expected to write what I mean in math, I'm expected to specify the = visual >expression for what I mean. This goes very much against the general = trend >in the development of LaTeX, which is that you should say what you mean = and >leave to the style (documentclass, packages used, preamble = declarations, >etc.) to sort out what is the visual expression for this. There is nothing wrong with this objective in itself, but the = complication is the diverse use of mathematics and how mathematicians write it. >Now what would a math font designer who cuts only one glyph variant of >epsilon do today? Most likely put that epsilon in both slot "0F and = slot >"22 of the OML-encoded font in the family. This will work fine until = that >day when comes a document where (in the spirit of Hans Aberg but = against >better judgement) The problem here is that what one mathematian consider is poor judgement may be what another finds is better judgement. > \epsilon and \varepsilon are used to mean different >things---then the typeset result will be wrong but LaTeX doesn't know = this >and thus cannot give a warning about it. I don't think this will ever happen, as Unicode now has made the distinction clear to font designers. LaTeX will need to be based on fonts that use Unicode extend with some characters missing in Unicode. Then if one wants to use a font with only one epsilon variation, then = that font will have to be mapped through the Unicode+ system that the = extended TeX/LaTeX systems is using, and via that mapping the missing glyph will either substitute the right epsilon in a font already present, or = produce an error. The mapping is this LaTeX -> Unicode+ TeX -> { Output fonts } For the second mapping, one will have to make sure that: 1. For every glyph in Unicode+ there is a default output. 2. Every font that overrides the default mapping, will have to do that = in a prudent way, either by merely providing a new substitute glyph, or = making the use of some of the old glyphs impossible. For sure, it is possible with such a system to map the two different epsilons to the same output character, but it is not possibly in any = type of programming to make sure that the code is semantically sensible. Hans Aberg ------_=_NextPart_001_01C0E2AB.53D31000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary 2.2

At 23:20 +0200 2001/05/21, Lars Hellstr=F6m = wrote:
>>Could you define the _problem_ you are trying = to solve?
>
>...On one side, the problem is that in LaTeX = today, I'm not
>expected to write what I mean in math, I'm = expected to specify the visual
>expression for what I mean. This goes very much = against the general trend
>in the development of LaTeX, which is that you = should say what you mean and
>leave to the style (documentclass, packages used, = preamble declarations,
>etc.) to sort out what is the visual expression = for this.

There is nothing wrong with this objective in itself, = but the complication
is the diverse use of mathematics and how = mathematicians write it.

>Now what would a math font designer who cuts only = one glyph variant of
>epsilon do today? Most likely put that epsilon in = both slot "0F and slot
>"22 of the OML-encoded font in the family. = This will work fine until that
>day when comes a document where (in the spirit of = Hans Aberg but against
>better judgement)

The problem here is that what one mathematian consider = is poor judgement
may be what another finds is better judgement.

> \epsilon and \varepsilon are used to mean = different
>things---then the typeset result will be wrong = but LaTeX doesn't know this
>and thus cannot give a warning about it.

I don't think this will ever happen, as Unicode now = has made the
distinction clear to font designers.

LaTeX will need to be based on fonts that use Unicode = extend with some
characters missing in Unicode.

Then if one wants to use a font with only one epsilon = variation, then that
font will have to be mapped through the Unicode+ = system that the extended
TeX/LaTeX systems is using, and via that mapping the = missing glyph will
either substitute the right epsilon in a font already = present, or produce
an error.

The mapping is this
          LaTeX = -> Unicode+ TeX -> { Output fonts }
For the second mapping, one will have to make sure = that:
  1. For every glyph in Unicode+ there is a = default output.
  2. Every font that overrides the default = mapping, will have to do that in
a prudent way, either by merely providing a new = substitute glyph, or making
the use of some of the old glyphs impossible.

For sure, it is possible with such a system to map the = two different
epsilons to the same output character, but it is not = possibly in any type
of programming to make sure that the code is = semantically sensible.

  Hans Aberg

------_=_NextPart_001_01C0E2AB.53D31000--