[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Long (font) filenames
- To: Karl Berry <firstname.lastname@example.org>, Lars.Hellstrom@math.umu.se, email@example.com
- Subject: Re: Long (font) filenames
- From: "Berthold K.P. Horn" <firstname.lastname@example.org>
- Date: Tue, 11 Aug 1998 10:45:53 -0400
- In-Reply-To: <199808101825.OAA16536@hub.cs.umb.edu>
At 02:25 PM 98/08/10 -0400, Karl Berry wrote:
>The underlying problem with any longname proposal is getting
>sufficiently widespread support that users can actually use long names
>in TeX documents. And to get support, the benefits have to be worth it
>to the implementors. So far that hasn't happened.
>For example, it's been possible to use PostScript font names in TeX
>documents with Web2c for years now, but there's no sign of anyone
>actually being interested in making use of that feature.
It may be of interest to note that the issue of how to refer to fonts in an
reliable platform independent way has plagued many applications developers.
(1) Using PS FontName is a good idea, because these ought to be unique
(although rip-off clones may steal the PS FontName also unless it is protected
by registered trademark). However, very few applications (except a couple
of top end ones) do this, probably because on both Mac and Windows it is
hard to get at that information. In some cases, the application would have
read all PFB files when starting in order the get a map from PS FontName
to other font information. This is expensive when several hundred fonts are
installed (as will happen with TeX using fonts that have optical scaling).
(2) Using the vendor font filename is simple, but not platform independent,
since on the Mac the actual font file name is algorithmically derived from
the PS FontName, while on the PC it is not related and assigned arbitrarily
by the vendor. If you use only fonts from one vendor these names are
guaranteed to be unique. Again, this is hard to do in an application because
fonts are not `registered' under this name, so one may have to enumerate all
fonts and build a mapping table (cheaper than reading all the PFBs, but
(3) On OS's with support for scalable fonts, the fonts are typically referred
to by yet another name, the `font menu' name plus style (italic, bold, etc.).
So in Windows and on the Mac, the font with PS FontName Times-BoldItalic
would be referred to as `Times' with style modifiers `BOLD' and `ITALIC'.
This is the naming convention that has direct support in the OS. All others
have to work by first developing a mapping to this convention. Typical
will store font references in files using this format. Generally font
try to make sure that the `font menu' names (Windows Face name and
QuickDraw font name) are the same on different platforms, but this is
not always the case.
One problem with this scheme is that some platforms really
only effectively support four standard styles (bold, italic/oblique, regular,
bold italic/oblique). So if you have regular/demibold/bold you need to
use a second menu name. Ditto if you have both italic and obliqued versions
of a font (not sure this is a good idea, but it is common in TeX useage
where fake obliqued, fake condensed and fake extended, and fake
(4) Some applications invent their own names. Sometimes constructed
from the font menu name with style modifiers tacked on. E.g.
TimesBI for Times-BoldItalic.
I don't know what the conclusion of all of this is. All of these schemes have
there advantages and disadvantages. Most applications use (3). Some top
end applications use (1). Y&Y TeX uses (2), but with an aliasing table that
makes the other schemes (including 1) easy to implement.
Note that constructing mapping tables that work on different versions of
an OS (e.g. Windows 3.1, Windows 95/98, Windows NT 4) and with
different font types (PS Type 1 and TrueType) and different versions of
the rasterizer (ATM 2.5, 26., 3.02, 4.0) can be a challenge, since the
information is hidden in different ways. For example, in Windows NT, the
font is registered under a (useless) name constructed from the PS FontName
by changing hyphens to spaces (which often makes it look like the PS
Berthold K.P. Horn
Cambridge, MA mailto:email@example.com