Re: Feature request for DVIPS... (at the last minute?)

["Melissa O'Neill" <oneill@cs.sfu.ca>]

Timothy Murphy writes:
> But surely you would have had to create a TFM file to get this far anyway,
> and it would have been obvious at that point that you would have to create
> a PFB/PFA file ?
> 
> Wouldn't it be more natural to get whatever process you used
> to create the TFM file to automatically create the Type 1 font?

Yes and no. It might be more natural, but it's also more costly. A TFM
file only needs about 12K or so of diskspace, whereas a PFA file can take
more than 10 times that amount.

Generally, I feel like TeX and friends should do more of their font
behaviour on-the-fly, rather than require that a variety of TeX-specific
files be installed for every font. If you have a good typeface, you can
easily have weights that include Light, Regular, SemiBold, Bold and
Black (l|r|s|b|c) with shapes including Regular, Italic, Small Caps,
Italic Small Caps and Swash (|c|i|ci|w), plus Expert sets with additional
glyphs for some or all of those fonts. Add to that the way TeX uses
encodings whereby you have separate 7t, 7d, 9t, and 9o fonts if you're
using the OT1 encoding; 8t, 8d, 9e, and 9d fonts if you're using the T1
encoding; and 8c and 9c fonts if you're using the TS1 encoding.  Finally,
if you have a font that includes an optical size axis, you need have
separate TFMs for each size used by TeX (5, 6, 7, 8, 9, 10, 10.95, 12,
14.40, 17.28, 20.74 and 24.88 points).

Put all this together and for just one font (Kepler in my case) you've
got a ton of TFMs that TeX could potentially use (6048, in fact) and a
similar number of VFs, so it makes sense to make them dynamically. For
TFMs it makes sense to make them and keep them around afterwards, but
for anything much bigger than a TFM, that might not make the same sense.

Even if you don't have a large number of TFMs to make, the hassle factor
for the current TeX font scheme is pretty big. I'm sure there are many
users of TeX on Linux, Windows and the Mac who have not set TeX up to
reference locally installed fonts.  As I see it, they shouldn't have
to, it should just work. Maybe we can hope for that one day?

Returning to my own situation, I found that I could realistically build
TFMs on the fly (using an ugly little Perl script), and I could generate
a line for psfonts.map, such as:

  pkpb8r1728 KeplMM_650_575_17.28_ "TeXBase1Encoding ReEncodeFont" <8r.enc

... without much trouble.

However, the problem was and is that if DVIPS is asked to include the
font, you run into trouble.

First, you need to make it not look like a font at all (i.e., not call
it `.pfa' or `.pfb'), or DVIPS includes it multiple times (my guess is
that DVIPS uses the PostScript name of the font to differentiate fonts).

This not calling it `.pfa' (or `.pfb') has the side-effect of disabling
partial font downloading -- this is almost certainly a blessing right
now, since I'm pretty sure that the partial font downloading present in
DVIPS is too primitive to handle multiple master fonts. But, because
we're sending the font whole, it takes a pretty big chunk of printer
memory and can leave us with documents too memory hungry to print.

One solution is to use Adobe Acrobat Distiller and Acrobat Reader as a
way to load and subset the fonts, taking the task away from DVIPS. This
works, mostly, but it requires proprietary software, time, and in my
case, a trip to another machine.

So, a glimmer of a solution seemed to me to use MMPFB to make stand-alone
MM instances, which would therefore not require DVIPS to worry. As
Timothy Murphy points out, I could generate a PFB when I make the TFM
file, but I feared that it could rapidly suck up disk space to work this
way.

Of course, the real fix is to get DVIPS's font subsetting machinery to
properly grok multiple master fonts. I don't think it'd take all that
much to do this, but t1part.c is fairly nightmarish. I'm fairly sure
it'd just need to pay attention to definitions for NDV and CDV in the
Private dictionary, and if definitions are present, make sure that the
Subrs they refer to are included. Oh, and then one has to make sure that
when one uses the FontName_<WeightNo>_<WidthNo>_<OpSizeNo>_ convention
and has several names refering to the same PFA file, that PFA file only
needs to be included once.

Further thoughts welcome,

    Melissa.

P.S. While I've managed to figure out a way to use Kepler under Unix,
it seems like you can't use the `generate on-the-fly' approach under
OzTeX on the Mac.  It would certainly be nice to do be able to use fonts
easily regardless of which platform one is on.