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 f4EKa4f25362 for ; Mon, 14 May 2001 22:36:04 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f4EKa3723428 . for ; Mon, 14 May 2001 22:36:03 +0200 MIME-Version: 1.0 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 f4EKa3001076 for ; Mon, 14 May 2001 22:36:03 +0200 (MET DST) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DCB5.7EBED200" 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 WAA16671 for ; Mon, 14 May 2001 22:36:02 +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 f4EKa2001072 for ; Mon, 14 May 2001 22:36:02 +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 <0.7D921970@mail.listserv.gmd.de>; Mon, 14 May 2001 22:34:24 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 496443 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 14 May 2001 22:35:58 +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 WAA23964 for ; Mon, 14 May 2001 22:35:57 +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 WAA46746 for ; Mon, 14 May 2001 22:35:56 +0200 Received: from mail.umu.se (custer.umdac.umu.se [130.239.8.14]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f4EKZtQ17560 for ; Mon, 14 May 2001 22:35:56 +0200 (MET DST) Received: from [130.239.137.13] (mariehemsv093.sn.umu.se [130.239.137.13]) by mail.umu.se (8.8.8/8.8.8) with ESMTP id WAA20937 for ; Mon, 14 May 2001 22:35:56 +0200 (MET DST) In-Reply-To: <200105141900.f4EJ0VI25659@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 WAA23966 Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary 2.2 Date: Mon, 14 May 2001 21:35:55 +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: 4068 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0DCB5.7EBED200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 21.57 +0200 2001-05-14, Javier Bezos wrote: >> 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"? I explained what a top level font is. A base font (a.k.a. a raw font) is = a concept used in discussions of virtual fonts; it means a font which is = not a virtual font. In the present context (and in particular for modern = fonts which contain much more than 256 glyphs) one could also view a = reencoding of the font as a top level font in contrast to the base form the font = had before it was reencoded. The main reason for making this distinction is that foundries traditionally package their glyphs into fonts more based = on how common they are than on what makes sense for TeX, so you have to = create some intermediate layer to sort things out. >> 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). Yes. >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. >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. Provided that both glyphs have slots in the same font, yes, but I cannot see any reason why they should. >> 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.) This implies that there aren't any OCPs acting on typeset material at \shipout time, so why didn't you say so in the first place?! Lars Hellstr=F6m ------_=_NextPart_001_01C0DCB5.7EBED200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary 2.2

At 21.57 +0200 2001-05-14, Javier Bezos wrote:
>> 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"?

I explained what a top level font is. A base font = (a.k.a. a raw font) is a
concept used in discussions of virtual fonts; it = means a font which is not
a virtual font. In the present context (and in = particular for modern fonts
which contain much more than 256 glyphs) one could = also view a reencoding
of the font as a top level font in contrast to the = base form the font had
before it was reencoded. The main reason for making = this distinction is
that foundries traditionally package their glyphs = into fonts more based on
how common they are than on what makes sense for TeX, = so you have to create
some intermediate layer to sort things out.

>> 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).

Yes.

>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.

>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.

Provided that both glyphs have slots in the same font, = yes, but I cannot
see any reason why they should.

>> 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.)

This implies that there aren't any OCPs acting on = typeset material at
\shipout time, so why didn't you say so in the first = place?!

Lars Hellstr=F6m

------_=_NextPart_001_01C0DCB5.7EBED200--