Re: Font naming rears its ugly head again

[alanje@cogs.susx.ac.uk (Alan Jeffrey)]

>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 
package. 
 
>Conversely, I bet one can get a TFM/VF identical with yours using 
>afm2tfm. 
 
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 
needing 7. 
 
>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!
 
Alan.