psfonts.beta/tools/fontinst.rc

[texadmin@fourier.grenet.fr (Thierry Bouche)]

Hello,

I am trying to generate the vf/tfm for quite a large class of fonts
including rich families. I realize that I am writing a shell script
in order to implement a replacement of the \latinfamily command which
is not a good solution because \latinfamily makes a good job in most
cases. (however the script also writes a .map file and will eventually
write a .sty file supporting all the fonts available)
My feeling is that \latinfamily is perfect in 2 cases:
 - you have a basic family (roman/italic in two or more weights,
perhaps 'c' or 'n' width also available): typically the 35 adobe fonts
or what is to be found on the bitstream CD. (Adding supported widths
and weights is not much pain.) 
 - you have an expert family. (Dealing with expert families with many
variants (such as Display Regular Italic) is however still difficult.)

The intermediate case where you have roman/italic/small caps/oldstyle
versions of the same font is not well supported. Especially \latinfamily
will fake bad looking small caps. This comes  (I beleive) from the fact that a
small cap font is encoded like a roman one, glyphs are called a, b,
rather than Asmall, Bsmall and fontinst knows only about Asmall when
dealing with small caps. It is far over my abilities just to guess how
much work it would be to implement the faking of the small caps in a
similar way to the one for slanted fonts (relying on the name of AFM
living in TEXINPUT rather than on the name of the glyphs declared in
these AFM and then using T1.etx instead of T1c.etx). 

By the way, does someone know how I should call a TeX font OT1 encoded
with oldstyle numerals (7d7t seems bad), and in the expert case ?  

An other remark regarding '8a'. Is there a reason not to prefer:
\def\adobe_encoding{}? Psnfss treats the type1 fonts as
raw data: only a set of glyphs and associated metric information, this
is not an encoded material (only drivers will assume adobe standard
encoding by default, the case 8x is obviously different). There is
some nonesense to change ptmr.pfb to ptmr0.pfb and then ptmr8a.pfb
when you only acces this font through 8r encoding. (the encoding is
more relevant to the AFM file, but not to the use fontinst does of
it).

Any comments/solutions appreciated...

Th. Bouche