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

[Julian Gilbey]

On Sun, Oct 20, 2019 at 03:32:36PM +0100, Julian Gilbey wrote:
> Dear all,
> 
> I've been presented with an interesting bug in mftrace when ported to
> Python 3: it blows up on lhr10.mf (the bug report is available at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941885).  I've been
> digging through the tfm file generated by mktextfm lhr10, and
> discovered that the coding system is recorded as follows (with the
> hexadecimal and character/octal values of each byte shown):
> 
> 0000000  c0  00  00  26  c0  00  00  22  c0  00  00  1a  c0  00  00  18
>         300  \0  \0   & 300  \0  \0   " 300  \0  \0 032 300  \0  \0 030
> 0000020  c0  00  00  1f  c0
>         300  \0  \0 037 300
> 
> I have no idea from looking briefly at the Metafont source for the lh
> fonts how this has happened, and why the coding system is not "TeX
> Cyrillic Font Encoding - LCY" as it appears from fikparm.mf that it
> should be.
> 
> Any ideas?  Or should I ask somewhere else?
> 
> Thanks!
> 
>    Julian

Oh, I think I've figured it: mktextfm doesn't record the font encoding
in the generated TFM file.  I tried running it step by step to create
cmr10.tfm, and that too does not have the encoding in it.  How come,
then, that the cmr10.tfm in the TeXLive distribution does contain the
encoding?  Presumably that was produced using something like the code
in dummy.mf, but I wonder where that is?

Best wishes,

   Julian