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 f4F9PDf27916 for ; Tue, 15 May 2001 11:25:13 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f4F9PC726507 . for ; Tue, 15 May 2001 11:25:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DD20.F1B16280" 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 f4F9PCU04661 for ; Tue, 15 May 2001 11:25:12 +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 LAA25584 for ; Tue, 15 May 2001 11:25:11 +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 f4F9P3005812 for ; Tue, 15 May 2001 11:25:11 +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 <6.EB90D719@mail.listserv.gmd.de>; Tue, 15 May 2001 11:23:25 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 495502 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 15 May 2001 11:25:01 +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 LAA01874 for ; Tue, 15 May 2001 11:24:59 +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 LAA33674 for ; Tue, 15 May 2001 11:24:56 +0200 Received: from wisbech.cl.cam.ac.uk (mta1.cl.cam.ac.uk [128.232.0.15]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f4F9OsQ03426 for ; Tue, 15 May 2001 11:24:55 +0200 (MET DST) Received: from pallas.cl.cam.ac.uk ([128.232.8.88] helo=cl.cam.ac.uk ident=rf) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 14zb4X-000178-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Tue, 15 May 2001 10:24:53 +0100 In-Reply-To: Your message of "Tue, 15 May 2001 10:40:31 BST." <200105150843.f4F8hiI25065@smtp.wanadoo.es> Return-Path: Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary 2.2 Date: Tue, 15 May 2001 10:24:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Robin Fairbairns" 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: 4069 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0DD20.F1B16280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > >>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.) 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). whatever, such behaviour would take the issue beyond the realms that latex would deal with, since (to first order) there's no control over ligaturing in macro code. ------_=_NextPart_001_01C0DD20.F1B16280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary 2.2

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

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

whatever, such behaviour would take the issue beyond = the realms that
latex would deal with, since (to first order) there's = no control over
ligaturing in macro code.

------_=_NextPart_001_01C0DD20.F1B16280--