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 f4FD4nf30589 for ; Tue, 15 May 2001 15:04:49 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f4FD4m727487 . for ; Tue, 15 May 2001 15:04:49 +0200 MIME-Version: 1.0 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f4FD4eU25522 for ; Tue, 15 May 2001 15:04:40 +0200 (MET DST) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DD3F.9F336E80" 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 PAA00525 for ; Tue, 15 May 2001 15:04:39 +0200 (MEST) 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 f4FD4d027241 for ; Tue, 15 May 2001 15:04:39 +0200 (MET DST) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <10.98CD47C1@mail.listserv.gmd.de>; Tue, 15 May 2001 15:03:00 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 495867 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 15 May 2001 15:04:36 +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 PAA04798 for ; Tue, 15 May 2001 15:04:35 +0200 (MET DST) 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 PAA106310 for ; Tue, 15 May 2001 15:04:33 +0200 Received: from abel.math.umu.se (abel.math.umu.se [130.239.20.139]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f4FD4WP14415 for ; Tue, 15 May 2001 15:04:32 +0200 (MET DST) Received: from [130.239.20.144] (mac144.math.umu.se [130.239.20.144]) by abel.math.umu.se (8.9.2/8.9.2) with ESMTP id PAA23656 for ; Tue, 15 May 2001 15:01:12 +0200 (CEST) In-Reply-To: <200105150843.f4F8hiI25065@smtp.wanadoo.es> Return-Path: X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id PAA04801 Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary 2.2 Date: Tue, 15 May 2001 14:04:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: =?iso-8859-1?Q?Lars_Hellstr=F6m?= 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: 4072 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0DD3F.9F336E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 11.40 +0200 2001-05-15, Javier Bezos wrote: >>>The same should apply to, say, Greek. If I write "barbaros" [well, >>>imagine it written in Greek] using the same beta, sometimes I would = like to >>>see the first one using a differenf glyph from the second one (a = medial >>>beta, not used currently). >> >> And then I suggest that you do this by selecting a (top level) font = in >> which the beta has the medial form, not by using a special = \medialbeta >> command or by requesting that the LICR should incorporate something >> equivalent to this. > >Thus, we need 2 virtual font for every font encoding. Don't forget >that iota can be rendered below a letter or "in-line" (2), >iota and upsilon can be rendered inverted (2), and there is >the lunate sigma (2). Since these options are independent, are you >suggesting the creation of 16 (!) vf files and tfm files for every >font (and encoding)? (And regarding that, Greek is easy compared >with scripts like Devanagari or Arabic.) If you have four characters with to glyph variants each and you write 16 documents in which you realize each of the possible selections of glyph variants (one selection per document) then you deserve to have to use different fonts for each document. However: At 11.24 +0200 2001-05-15, Robin Fairbairns wrote: >isn't this sort of thing done by ligaturing a "boundary character", so > > "bnd" "beta" -> "initial beta" > ... > "sigma" "bnd" -> "terminal sigma" > >and so on? > >(i've never really understood boundary characters so i may have this >wrong). (Looks right to me, Robin.) If that is the kind of variants you are = talking about then of course they should all be in the same font, but the point = is that all these replacements of glyphs should be handled by the font, not = by the user or by LaTeX. In particular there shouldn't be an internal character representation for the variants in LaTeX, because the variants are semantically equivalent and therefore identical as characters. The idea that OCPs could be used to select between variant glyphs in the font is not without merit, though, _provided_ it does not mess up the = LICR. I'm also sceptical towards that it should be the language which selects = a certain variant form of a character, as that can become a severe drag on font design. If anything, it should be the font (or its FD file) which declares that "I provide the following variants of this character", together with the code for choosing one or the other (this code could = well consist of pushing an OCP). Languages could by all means request a = certain variant form, but the font shouldn't always have to provide it! I math fonts something like that could be used to handle the choice = between \epsilon and \varepsilon. As I understand it, these are semantically equivalent---i.e., people will think you've done something wrong if you = try to use them both in the same formula to mean different things (but maybe Barbara has some counterexample)---and so shouldn't have different = internal representations in LaTeX (as they do today). Lars Hellstr=F6m ------_=_NextPart_001_01C0DD3F.9F336E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary 2.2

At 11.40 +0200 2001-05-15, Javier Bezos wrote:
>>>The same should apply to, say, Greek. If = I write "barbaros" [well,
>>>imagine it written in Greek] using the = same beta, sometimes I would like to
>>>see the first one using a differenf glyph = from the second one (a medial
>>>beta, not used currently).
>>
>> And then I suggest that you do this by = selecting a (top level) font in
>> which the beta has the medial form, not by = using a special \medialbeta
>> command or by requesting that the LICR = should incorporate something
>> equivalent to this.
>
>Thus, we need 2 virtual font for every font = encoding. Don't forget
>that iota can be rendered below a letter or = "in-line" (2),
>iota and upsilon can be rendered inverted (2), = and there is
>the lunate sigma (2). Since these options are = independent, are you
>suggesting the creation of 16 (!) vf files and = tfm files for every
>font (and encoding)? (And regarding that, Greek = is easy compared
>with scripts like Devanagari or Arabic.)

If you have four characters with to glyph variants = each and you write 16
documents in which you realize each of the possible = selections of glyph
variants (one selection per document) then you = deserve to have to use
different fonts for each document. However:

At 11.24 +0200 2001-05-15, Robin Fairbairns = wrote:
>isn't this sort of thing done by ligaturing a = "boundary character", so
>
>  "bnd" "beta" -> = "initial beta"
>  ...
>  "sigma" "bnd" -> = "terminal sigma"
>
>and so on?
>
>(i've never really understood boundary characters = so i may have this
>wrong).

(Looks right to me, Robin.) If that is the kind of = variants you are talking
about then of course they should all be in the same = font, but the point is
that all these replacements of glyphs should be = handled by the font, not by
the user or by LaTeX. In particular there shouldn't = be an internal
character representation for the variants in LaTeX, = because the variants
are semantically equivalent and therefore identical = as characters.

The idea that OCPs could be used to select between = variant glyphs in the
font is not without merit, though, _provided_ it does = not mess up the LICR.
I'm also sceptical towards that it should be the = language which selects a
certain variant form of a character, as that can = become a severe drag on
font design. If anything, it should be the font (or = its FD file) which
declares that "I provide the following variants = of this character",
together with the code for choosing one or the other = (this code could well
consist of pushing an OCP). Languages could by all = means request a certain
variant form, but the font shouldn't always have to = provide it!

I math fonts something like that could be used to = handle the choice between
\epsilon and \varepsilon. As I understand it, these = are semantically
equivalent---i.e., people will think you've done = something wrong if you try
to use them both in the same formula to mean = different things (but maybe
Barbara has some counterexample)---and so shouldn't = have different internal
representations in LaTeX (as they do today).

Lars Hellstr=F6m

------_=_NextPart_001_01C0DD3F.9F336E80--