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 f1KAbL108936 for ; Tue, 20 Feb 2001 11:37:21 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1KAbKd31443 . for ; Tue, 20 Feb 2001 11:37:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09B29.1AAEC680" 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 f1KAbJQ21684 for ; Tue, 20 Feb 2001 11:37:19 +0100 (MET) 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 LAA03058 for ; Tue, 20 Feb 2001 11:37:19 +0100 (MET) 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 f1KAbJQ21680 for ; Tue, 20 Feb 2001 11:37:19 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <12.EC88F047@mail.listserv.gmd.de>; Tue, 20 Feb 2001 11:37:09 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 490835 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 20 Feb 2001 11:37:15 +0100 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 LAA14860 for ; Tue, 20 Feb 2001 11:37:14 +0100 (MET) 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 LAA42986 for ; Tue, 20 Feb 2001 11:37:09 +0100 Received: from alpha.ntp.springer.de (alpha.ntp.springer.de [192.129.24.9]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1KAb9x05277 for ; Tue, 20 Feb 2001 11:37:09 +0100 (MET) Received: from ALPHA.NTP.SPRINGER.DE by ALPHA.NTP.SPRINGER.DE (PMDF V5.2-32 #35169) id <01K0BY7FRCOI000MZM@ALPHA.NTP.SPRINGER.DE> for LATEX-L@URZ.UNI-HEIDELBERG.DE; Tue, 20 Feb 2001 11:38:30 MEZ Return-Path: x-vms-to: IN%"LATEX-L@URZ.UNI-HEIDELBERG.DE" Content-class: urn:content-classes:message Subject: Re: glyph collections viz font encodings Date: Tue, 20 Feb 2001 11:38:30 +0100 Message-ID: <01K0BY7FRCOK000MZM@ALPHA.NTP.SPRINGER.DE> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "J%ORG KNAPPEN" 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: 3995 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09B29.1AAEC680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank schrieb: > Yes i'm seriously thinking that splitting TS1 into say, TSA (adobe = default) TSE > (with expert set) and so on would be helpful to actually make sure = that if you > have a font that claims to be in some encoding it really has the = glyphs of > that encoding. I suggested making a TSA encoding for Adobe fonts years ago, but noone undertook the work. > Similar T1 should then be expanded to have companion encodings which = are used > for fonts that do not have Ng etc. > The number of encodings wouldn't grow that much, but then you could = really be > sure that you get what you ask for and not just some square boxes in = the > output and some error messages from dvips. I'm afraid, the number of encodings will grow much. There are more = founderies than Adobe around (like Monotype, Linotype, Agfa, Berthold to drop some names) and they all have different basic and expert glyph sets in their = fonts. My font book from FontShop lists about 70 founderies, the new edition probably has even more of them. In addition, glyph sets aren't constant in time; older fonts lack the Euro sign newer fonts have. Fonts are a real mess (not only with (La)TeX, but also with the = so-called professional versions for PC and Mac) and I don't see that the state of = affairs will change on foreseeable future. IMHO, the black box replacements in vf's are an error: An unavailable = glyph should be unavailable in the tfm file as well and provoke a harsh TeX error message. To catch the black thingies at proof reading stage is = rather late and error prone. --J"org Knappen ------_=_NextPart_001_01C09B29.1AAEC680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: glyph collections viz font encodings

Frank schrieb:

> Yes i'm seriously thinking that splitting TS1 = into say, TSA (adobe default) TSE
> (with expert set) and so on would be helpful to = actually make sure that if you
> have a font that claims to be in some encoding = it really has the glyphs of
> that encoding.

I suggested making a TSA encoding for Adobe fonts = years ago, but noone
undertook the work.

> Similar T1 should then be expanded to have = companion encodings which are used
> for fonts that do not have Ng etc.

> The number of encodings wouldn't grow that much, = but then you could really be
> sure that you get what you ask for and not just = some square boxes in the
> output and some error messages from = dvips.

I'm afraid, the number of encodings will grow much. = There are more founderies
than Adobe around (like Monotype, Linotype, Agfa, = Berthold to drop some
names) and they all have different basic and expert = glyph sets in their fonts.
My font book from FontShop lists about 70 founderies, = the new edition
probably has even more of them.

In addition, glyph sets aren't constant in time; older = fonts lack the
Euro sign newer fonts have.

Fonts are a real mess (not only with (La)TeX, but also = with the so-called
professional versions for PC and Mac) and I don't see = that the state of affairs
will change on foreseeable future.

IMHO, the black box replacements in vf's are an error: = An unavailable glyph
should be unavailable in the tfm file as well and = provoke a harsh TeX
error message. To catch the black thingies at proof = reading stage is rather
late and error prone.

--J"org Knappen

------_=_NextPart_001_01C09B29.1AAEC680--