[tex-k] Bizarre coding system in lhr10.tfm

[Karl Berry]

Hi Julian,

(Tom Rokicki: please see end.)

    How come, then, that the cmr10.tfm in the TeXLive distribution does
    contain the encoding?  

I (or maybe it was Thomas Esser, or someone, can't remember now)
generated the basic cm*.tfm and others long, long, ago. Before TeX Live
existed, I believe. At that time, I had modes.mf automatically
including the codingscheme (so-called "Xerox-world info") in generated
tfms, by redefining MF's end primitive.

This was the case until 2008, when DEK ran afoul of this, and asked me
(rather insistently :) to let "end" mean "end". So I dutifully changed
modes.mf so that now "mode_extra_info" has to be called (which no one
does) to generate the extra info.

However, I did not think it was necessary or desirable to regenerate
cm*.tfm merely to remove the extra info, nor did Don request this or
mention it as a problem. Better to let sleeping tfms lie, it seemed to me.

Therefore, tfms generated before 2008 will have the info, and ones
generated after (e.g., dynamically, as with the lh* fonts) will not, by
default. 

    Presumably that was produced using something
    like the code in dummy.mf, but I wonder where that is?

Ultimately what generates that stuff is the MF "headerbyte" primitive
(for the tfm) and "special" primitive (for the gf). I haven't looked
into what the lh* fonts do. You could presumably figure out what it is
writing. Maybe it is not writing anything.

In general, you cannot rely on the codingscheme (or related information)
to be present, or to be useful or correct even if it is. There is,
sadly, no general way to determine the encoding of a given tfm presented
in a vacuum.

If you must know the encoding, and not just process the characters as
they come, then you'll have to somehow look up the filename. I am not
aware of any global mapping of tfm names to encodings for such lookups,
either. Fonts available in PostScript/PDF format can be found in
psfonts.map, etc., which often has encoding info, but lh* is mf-only --
probably the most significant remaining mf-only font.

That said, Tom Rokicki just worked on this whole mess in some depth in
order to introduce encodings for Type 3 fonts in dvips. I do not know if
he discerned encodings for lh*, though. Tom?

Sorry for the long and unsatisfying answer. Good luck. --best, karl.