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 f1KIEg123434 for ; Tue, 20 Feb 2001 19:14:42 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1KIEcd00388 . for ; Tue, 20 Feb 2001 19:14:42 +0100 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 f1KIEbQ00874 for ; Tue, 20 Feb 2001 19:14:37 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09B68.FECB1500" 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 TAA21949 for ; Tue, 20 Feb 2001 19:14:37 +0100 (MET) 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 f1KIEaQ00870 for ; Tue, 20 Feb 2001 19:14:36 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <1.CE571CFC@mail.listserv.gmd.de>; Tue, 20 Feb 2001 19:14:27 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 491503 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 20 Feb 2001 19:14:31 +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 TAA25638 for ; Tue, 20 Feb 2001 19:14:30 +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 TAA43326 for ; Tue, 20 Feb 2001 19:14:30 +0100 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1KIEVx04444 for ; Tue, 20 Feb 2001 19:14:31 +0100 (MET) Received: from [195.20.224.204] (helo=mrvdom00.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14VHIz-0007EK-00 for LATEX-L@urz.uni-heidelberg.de; Tue, 20 Feb 2001 19:14:29 +0100 Received: from manz-3e36595e.pool.mediaways.net ([62.54.89.94] helo=istrati.zdv.uni-mainz.de) by mrvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14VHIS-0006FD-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Tue, 20 Feb 2001 19:13:56 +0100 Received: (from latex3@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id TAA08127; Tue, 20 Feb 2001 19:02:52 +0100 In-Reply-To: <01K0BY7FRCOK000MZM@ALPHA.NTP.SPRINGER.DE> References: <01K0BY7FRCOK000MZM@ALPHA.NTP.SPRINGER.DE> Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 X-Authentication-Warning: istrati.zdv.uni-mainz.de: latex3 set sender to frank@mittelbach-online.de using -f Content-class: urn:content-classes:message Subject: Re: glyph collections viz font encodings Date: Tue, 20 Feb 2001 19:02:52 +0100 Message-ID: <14994.45388.921099.45213@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" 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: 3997 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09B68.FECB1500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable J%ORG KNAPPEN writes: > 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. :-) why do this statement makes me smile? the point is really that all = this needs people and time, there is unfortunately a big gap between = suggesting something and finding people to do it or to do it yourself. but i don't want to claim that my idea is original > > 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. there is a difference however between a font encoding and an encoding = provided for, say, NFSS. You do not need to model all encodings as 1-1 NFSS = encodings, since you have to build vfs or at least tfms anyway you can ignore that = some font has a few additional glyphs. So if one would come up with an = alternative to T1, that could be implemented with many basic fonts that would = already be a big help > 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. yes sure, fonts are a mess (for any system) and you can't change that fact. however we can make our lives somewhat more comfortable by not = building extra problems, and T1 was a mistake as it was designed with the world = view of "TeX lives in a world of its own and all it has to do is to provide a wonderful font set which can typeset as many (latin based) languages as possible and then all is perfect". unfortunately less would be more now > 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. agreed frank ------_=_NextPart_001_01C09B68.FECB1500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: glyph collections viz font encodings

J%ORG KNAPPEN writes:
 > 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.

:-) why do this statement makes me smile? the point is = really that all this
needs people and time, there is unfortunately a big = gap between suggesting
something and finding people to do it or to do it = yourself.

but i don't want to claim that my idea is = original


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

there is a difference however between a font encoding = and an encoding provided
for, say, NFSS. You do not need to model all = encodings as 1-1 NFSS encodings,
since you have to build vfs or at least tfms anyway = you can ignore that some
font has a few additional glyphs. So if one would = come up with an alternative
to T1, that could be implemented with many basic = fonts that would already be a
big help

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

yes sure, fonts are a mess (for any system) and you = can't change that
fact. however we can make our lives somewhat more = comfortable by not building
extra problems, and T1 was a mistake as it was = designed with the world view of
"TeX lives in a world of its own and all it has = to do is to provide a
wonderful font set which can typeset as many (latin = based) languages as
possible and then all is perfect".

unfortunately less would be more now

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

agreed
frank

------_=_NextPart_001_01C09B68.FECB1500--