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 f4EJ0ef25156 for ; Mon, 14 May 2001 21:00:41 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f4EJ0e723052 . for ; Mon, 14 May 2001 21:00:40 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DCA8.2B925280" 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 f4EJ0d024964 for ; Mon, 14 May 2001 21:00:39 +0200 (MET DST) 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 VAA27415 for ; Mon, 14 May 2001 21:00: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 f4EJ0c024958 for ; Mon, 14 May 2001 21:00:38 +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 <11.2A0FB83E@mail.listserv.gmd.de>; Mon, 14 May 2001 20:59:00 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 496405 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 14 May 2001 21:00:34 +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 VAA22623 for ; Mon, 14 May 2001 21:00:33 +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 VAA59398 for ; Mon, 14 May 2001 21:00:34 +0200 Received: from smtp.wanadoo.es (m1smtpisp02.wanadoo.es [62.36.220.21] (may be forged)) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f4EJ0WQ10295 for ; Mon, 14 May 2001 21:00:33 +0200 (MET DST) Received: from [62.36.69.20] (62-36-69-20.dialup.uni2.es [62.36.69.20]) by smtp.wanadoo.es (8.10.2/8.10.2) with ESMTP id f4EJ0VI25659 for ; Mon, 14 May 2001 21:00:31 +0200 (MET DST) Return-Path: X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary 2.2 Date: Mon, 14 May 2001 20:57:17 +0100 Message-ID: <200105141900.f4EJ0VI25659@smtp.wanadoo.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Javier Bezos" 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: 4067 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0DCA8.2B925280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > For the base fonts I agree this makes sense, but for top level fonts = (i.e., > the ones which TeX/Omega actually works with) it is mainly a nuisance. = It What do you mean with "base fonts" and "top level fonts"? > also goes against much of the philosophy in LaTeX as you end up with = for > each character separately specifying what it should look like rather = than > what it logically is. I think we are speaking about different things. When you write a = document you use the logical value (eg, "fi") and TeX converts it to the corresponding glyph (ie, the fi ligature). 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). That can be done with ocp's -- the file = ell.fd defines a language property named beta with two possible values (oneform and twoform) which specifies how beta will be rendered. That can be done with tfm ligatures too, I think, but I cannot change how its rendered = from my document, except if a create new vf/tfm files for every font. > Now I don't understand. Are you saying that there is an OCP, but that = it > never changes anything? It changes things, but TeX was built in such a way that only the font encoding (ie, the encoding used in the tfm file; ie, the final form = after every single ocp has been processed) is used when hyphenating words. (And this problem has not been solved by Omega.) Javier ------_=_NextPart_001_01C0DCA8.2B925280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary 2.2

> For the base fonts I agree this makes sense, but = for top level fonts (i.e.,
> the ones which TeX/Omega actually works with) it = is mainly a nuisance. It

What do you mean with "base fonts" and = "top level fonts"?

> also goes against much of the philosophy in LaTeX = as you end up with for
> each character separately specifying what it = should look like rather than
> what it logically is.

I think we are speaking about different things. When = you write a document
you use the logical value (eg, "fi") and = TeX converts it to the
corresponding glyph (ie, the fi ligature).

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). That can be done with = ocp's -- the file ell.fd
defines a language property named beta with two = possible values (oneform
and twoform) which specifies how beta will be = rendered. That can be done
with tfm ligatures too, I think, but I cannot change = how its rendered from
my document, except if a create new vf/tfm files for = every font.

> Now I don't understand. Are you saying that there = is an OCP, but that it
> never changes anything?

It changes things, but TeX was built in such a way = that only the font
encoding (ie, the encoding used in the tfm file; ie, = the final form after
every single ocp has been processed) is used when = hyphenating
words. (And this problem has not been solved by = Omega.)

Javier

------_=_NextPart_001_01C0DCA8.2B925280--