[Fontinst] Re: Bug in fontinstversion{1.927}

Lars Hellström Lars.Hellstrom at math.umu.se
Thu Jan 27 19:35:46 CET 2005


At 16.57 +0100 2005-01-27, Peter Dyballa wrote:
>Am 27.01.2005 um 12:19 schrieb Lars Hellström:
>
>> If you insist on assigning glyph names by encoding positions (in
>> general a
>> bad practice; there are lots of fonts out there which are broken
>> because of
>> that),
>
>I don't understand what you are trying to express! Is 8r or 8a
>something completely different than assigning a name to a code
>position?

Encodings rather assign code positions to names, which is different in
important aspects, but this terminology is not all that self-explanatory,
so I can agree the point may seem subtle.

What is _real_ when you're making virtual fonts are the _glyphs_ of the
base fonts. In traditional PS fonts these are identified by names, whereas
in CIDFonts and (I believe) TrueType fonts the glyphs are instead assigned
a number. Glyph names do a fairly good job of identifying the glyph (even
if many different names are being used by different fonts for the same
glyph, it is uncommon that the same name is used for different glyphs).
Where numbers are being used, there is often still a separate specification
to help determine the glyph identities (e.g. CIDFonts name an ordering, a
registry defining that ordering, and a supplement number).

When text is transmitted (e.g. from dvips to your printer), it has to be
encoded somehow, and the decoding is done in the printer by using the
encoding vector of the font. The point is that this encoding is often a bit
arbitrary, so there is not much reason to believe in general that a certain
code position should correspond to a particular glyph. Assigning names to
the glyphs of a font by their current code position is thus a bit of
mistaking the shadow for the real thing.

It could well be that ttf2pt1 is a bit of a Platonic cave-dweller in this
respect; I don't know for sure as I don't know what it does in detail.

>Why is then fontinst insisting on particular glyph names?

It doesn't. The only glyph name appearing anywhere in the fontinst utility
is .notdef, and that is standardised by the Postscript language.

What _is_ the case is that fontinst comes with a large set of standard ETX
and MTX files which specify hundreds of glyph names. You are not required
to use these files, but it may be convenient to do so, as some of the
issues taken care of by these files are rather obscure and have to do with
rather technical aspects of how TeX and related software works.

The names used in these files are mostly names that were commonly found in
fonts when that part of the file was written. In some cases (e.g.
rangedash, ringfitted) they were introduced to avoid some issue with a
"raw" glyph from a base font. In other cases (and many of the TS1 names
fall in this category) they were simply cooked up by fontinst maintainers,
as no standard name for that glyph existed (or at least: wasn't known).

>Not accepting uni00B9 or afii08941 or bahtthai?

I'm not saying the standard MTX and ETX files cannot be improved---a fully
up-to-2005 textcomp.mtx should be able to make use of any of the
above---but we haven't yet an artificial intelligence module of fontinst
with automagically figures out what glyphs are made available and generates
correct code for them. ;-)

Lars Hellström




More information about the fontinst mailing list