<div dir="ltr">There's some information here:<div><br></div><div> <a href="https://github.com/rokicki/type3search/">https://github.com/rokicki/type3search/</a></div><div><br></div><div>Ultimately I was less interested in the encoding *names* than</div><div>in the actual PostScript glyph names, and the best source I</div><div>found for that was in the psfonts.map files, and, failing that, in</div><div>the PFB files. Almost all current METAFONT fonts have</div><div>workalike Type 1 fonts at this point, so I mostly leveraged that</div><div>work.</div><div><br></div><div>I am not aware of any code that depends on, or uses, any sort</div><div>of encoding string in the TFM file in any meaningful way.</div><div><br></div><div>There are still a bunch of additional fonts I need to derive</div><div>reasonable glyph names for.</div><div><br></div><div>I don't seem to have lhr10 in my texlive tree . . .</div><div><br></div><div>-tom</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 20, 2019 at 2:40 PM Karl Berry <<a href="mailto:karl@freefriends.org">karl@freefriends.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Julian,<br>
<br>
(Tom Rokicki: please see end.)<br>
<br>
How come, then, that the cmr10.tfm in the TeXLive distribution does<br>
contain the encoding? <br>
<br>
I (or maybe it was Thomas Esser, or someone, can't remember now)<br>
generated the basic cm*.tfm and others long, long, ago. Before TeX Live<br>
existed, I believe. At that time, I had modes.mf automatically<br>
including the codingscheme (so-called "Xerox-world info") in generated<br>
tfms, by redefining MF's end primitive.<br>
<br>
This was the case until 2008, when DEK ran afoul of this, and asked me<br>
(rather insistently :) to let "end" mean "end". So I dutifully changed<br>
modes.mf so that now "mode_extra_info" has to be called (which no one<br>
does) to generate the extra info.<br>
<br>
However, I did not think it was necessary or desirable to regenerate<br>
cm*.tfm merely to remove the extra info, nor did Don request this or<br>
mention it as a problem. Better to let sleeping tfms lie, it seemed to me.<br>
<br>
Therefore, tfms generated before 2008 will have the info, and ones<br>
generated after (e.g., dynamically, as with the lh* fonts) will not, by<br>
default. <br>
<br>
Presumably that was produced using something<br>
like the code in dummy.mf, but I wonder where that is?<br>
<br>
Ultimately what generates that stuff is the MF "headerbyte" primitive<br>
(for the tfm) and "special" primitive (for the gf). I haven't looked<br>
into what the lh* fonts do. You could presumably figure out what it is<br>
writing. Maybe it is not writing anything.<br>
<br>
In general, you cannot rely on the codingscheme (or related information)<br>
to be present, or to be useful or correct even if it is. There is,<br>
sadly, no general way to determine the encoding of a given tfm presented<br>
in a vacuum.<br>
<br>
If you must know the encoding, and not just process the characters as<br>
they come, then you'll have to somehow look up the filename. I am not<br>
aware of any global mapping of tfm names to encodings for such lookups,<br>
either. Fonts available in PostScript/PDF format can be found in<br>
psfonts.map, etc., which often has encoding info, but lh* is mf-only --<br>
probably the most significant remaining mf-only font.<br>
<br>
That said, Tom Rokicki just worked on this whole mess in some depth in<br>
order to introduce encodings for Type 3 fonts in dvips. I do not know if<br>
he discerned encodings for lh*, though. Tom?<br>
<br>
Sorry for the long and unsatisfying answer. Good luck. --best, karl.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>-- <a href="http://cube20.org/" target="_blank">http://cube20.org/</a> -- <a href="http://golly.sf.net/" target="_blank">http://golly.sf.net/</a> --</div></div></div></div></div>