[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Font naming rears its ugly head again
- To: firstname.lastname@example.org
- Subject: Re: Font naming rears its ugly head again
- From: email@example.com (Alan Jeffrey)
- Date: Mon, 30 Aug 93 21:03 BST
- Flags: 000000000000
>ptmrq defines a unique font -- Adobe Times Roman in the Cork encoding.
>It shouldn't matter what generated it. If it does matter, then there
>must be some other difference in the font.
Indeed. The differences between the Cork encoded Adobe Times generated
by fontinst and that distributed with psnfss are (or rather, will be,
once I've finished the thing!):
* font dimensions: the afm2tfm program produces very sparse setting,
with large values for space, stretch and shrink. The fontinst package
produces much tighter setting
* kerning: the composite letters are kerned the same as the
non-composite equivalents, for example <Aacute> kerns like <A>, and
<IJ> kerns like <I> on the left and <J> on the right. This is
necessary because many PostScript fonts (notably those from Adobe)
don't have any kerning for non-American glyphs.
* monospace fonts: the fontinst package goes out of its way to make sure
the monospaced fonts are monospaced, for example letterspacing the
small caps so that they're the same width as the caps. It also
provides for number-range-dash and punctuation-dash ligatures in
Cork-encoded monowidth fonts.
* expert fonts: the fontinst package can produce fonts which mix glyphs
from the standard and expert font, so at a site with the expert fonts,
the <f> and <i> glyphs would come from the standard encoding, and the
<ffi> glyph from the expert encoding.
* digit styles: the fontinst package can generate fonts with ranging or
oldstyle digits, and with fixed-width or variable-width digits.
* rounding errors: the rounding errors produced by the fontinst package
when converting afm dimensions to TeX dimensions will be slightly
different from those produced by afm2tfm.
There are a few other differences (such as accent positioning) but I
don't think those make any difference to the tfm file.
The problem is that even just looking at the fonts generated by the
fontinst package, there's:
* the encoding (Cork, text symbol, math symbol, etc.)
* the digit styles (lining/oldstyle and fixed-width/variable-width)
* the letter styles (u&lc, c&sc, all-caps)
* whether the font was generated using the expert font or not
* the weight (light, medium, demi-bold, bold, ultra-bold, etc.)
* the width (condensed, semi-condensed, medium, semi-expanded, etc.)
* the shape (roman, italic, oblique, etc.)
Just by giving each of these parameters a letter, plus three letters for
the font family, I'd already have used ten letters!
This is a real pain :-( because I think your naming scheme is pretty
impressive, and I'd like to use it if possible. I'm just worried about
hitting the 8+3 MessyDOS wall pretty soon.
>Can't one generate a font that would be identical with the current
>ptmr.tfm (say) using fontinst?
One can, by switching off most of the extra features of the fontinst
>Conversely, I bet one can get a TFM/VF identical with yours using
If that was possible I wouldn't have written the fontinst package!
>As long as you realize this doesn't cover the possibilities, either ...
Indeed it won't, but then nothing stuck to an 8+3 filename will. I'd just
like a naming scheme that will cope with the fonts generated by v1.x of the
fontinst package, and have as much scope for expansion as I can get away
with using the silly 8+3 filenames we're stuck with for the moment. I'll
see if I can get away with just 6 characters for this, but I might end up
>That doesn't sound simple to me, because why do TeX fontnames
>necessarily have to map onto particular directory structures? Unless
>you want to limit names to 8 characters, they won't ...
Yes, I was expecting a limit to 8 characters between directory
separators. This is still a pain, but it's better than 8 characters for
the entire filename!