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 f1KBSe116206 for ; Tue, 20 Feb 2001 12:28:40 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1KBSed31614 . for ; Tue, 20 Feb 2001 12:28:40 +0100 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 f1KBSYQ26184 for ; Tue, 20 Feb 2001 12:28:34 +0100 (MET) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09B30.45E8E400" 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 MAA15651 for ; Tue, 20 Feb 2001 12:28:29 +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 f1KBSTQ26170 for ; Tue, 20 Feb 2001 12:28:29 +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 <15.12AA2D0C@mail.listserv.gmd.de>; Tue, 20 Feb 2001 12:28:20 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 490890 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 20 Feb 2001 12:28:26 +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 MAA16221 for ; Tue, 20 Feb 2001 12:28:25 +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 MAA55010 for ; Tue, 20 Feb 2001 12:28:25 +0100 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 f1KBSQx00669 for ; Tue, 20 Feb 2001 12:28:26 +0100 (MET) 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 MAA26885 for ; Tue, 20 Feb 2001 12:26:27 +0100 (CET) In-Reply-To: <01K0BY7FRCOK000MZM@ALPHA.NTP.SPRINGER.DE> Return-Path: X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id MAA16224 Content-class: urn:content-classes:message Subject: Re: glyph collections viz font encodings Date: Tue, 20 Feb 2001 12:28:19 +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: 3996 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09B30.45E8E400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 11.38 +0100 2001-02-20, J%ORG KNAPPEN wrote: >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. I suspect I will split ts1.etx when I eventually get around to updating that, and thus create the basic fontinst support. (\latinfamily should probably also be reconstructed to use the proper symbol encoding, but = I'm not at all sure I will make the attempt.) That would however require = that the LaTeX definitions of the encodings are set first. >> 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. How large are the differences? It the common core of e.g. the basic encodings nearly as large as that provided by 8a? If it is a TSA can = still be reasonable. >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. There is a change in that more and more fonts are being made with more glyphs than what can fit in a single encoding vector. This may help to reduce the basic/expert sets problems. But yes, it will probably still = be a mess. >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. Usually these boxes are accompanied by a \special which should make the driver scream about them, but I agree it is mean on TeX to lie and say = the character is there when in reality it isn't. Hopefully the = reconstruction of latin.mtx (which I haven't done anything about for about a month now) should make it easier to not insert the \unfakables if you don't want = them. BTW, J=F6rg, any thoughts on my suggestion to add a comma accent = character (or rather two, when I think of it: one normal and one = reverse=3Dupside-down) to TS(1|A|E)? Faking it in VFs is no problem. Lars Hellstr=F6m ------_=_NextPart_001_01C09B30.45E8E400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: glyph collections viz font encodings

At 11.38 +0100 2001-02-20, J%ORG KNAPPEN wrote:
>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.

I suspect I will split ts1.etx when I eventually get = around to updating
that, and thus create the basic fontinst support. = (\latinfamily should
probably also be reconstructed to use the proper = symbol encoding, but I'm
not at all sure I will make the attempt.) That would = however require that
the LaTeX definitions of the encodings are set = first.

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

How large are the differences? It the common core of = e.g. the basic
encodings nearly as large as that provided by 8a? If = it is a TSA can still
be reasonable.

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

There is a change in that more and more fonts are = being made with more
glyphs than what can fit in a single encoding vector. = This may help to
reduce the basic/expert sets problems. But yes, it = will probably still be a
mess.

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

Usually these boxes are accompanied by a \special = which should make the
driver scream about them, but I agree it is mean on = TeX to lie and say the
character is there when in reality it isn't. = Hopefully the reconstruction
of latin.mtx (which I haven't done anything about for = about a month now)
should make it easier to not insert the \unfakables = if you don't want them.

BTW, J=F6rg, any thoughts on my suggestion to add a = comma accent character
(or rather two, when I think of it: one normal and = one reverse=3Dupside-down)
to TS(1|A|E)? Faking it in VFs is no problem.

Lars Hellstr=F6m

------_=_NextPart_001_01C09B30.45E8E400--