Comments wanted: Directory structure of fontinst/inputs/

Lars Hellström
Mon, 4 Sep 2000 12:26:03 -0400

At 14.20 +0200 2000-09-02, Vladimir Volovich wrote:
>"LH" == Lars Hellström writes:
> >>> BTW, didn't Vladimir Volovich some time ago write something about
> >>> that he was writing support for cyrillic fonts?  IMHO that seems
> >>> like a good starting point for two directories cyretx/ and
> >>> cyrmtx/!)
> >>  This is already part of the t2 package on CTAN.
> LH> So it is!
>so feel free to include these files into fontinst. :) i'll make
>changes from time to time to files contained in t2 package, and they
>will be migrated to fontinst, ok?

Or you could put those changes directly into the new fontinst/inputs/cyr...
(when we get it set up), which I think would be better, actually. I see no
reason why you shouldn't be allowed to update files that you have written
and maintain.

>this makes cyrillic fontinst files more available because e.g. tetex
>contains fontinst but does not contain cyrfinst; so when fontinst will
>include cyrfinst, it will be more available.
> LH> macros/latex/contrib/supported/t2 isn't where I would think of
> LH> looking for fontinst material, but the use of certain LaTeX
> LH> macros (\@ifundefined, \@for) in the code explains why it was put
> LH> there. (I have only had the time for a quick glance at it, but I
> LH> think fontinst v1.9 already contains analogues of all the LaTeX
> LH> macros used, so updating the t2 package for v1.9 would remove the
> LH> restriction that it must be used with a LaTeX format.)
>i'll try to adapt fnstcorr.tex to macros provided by fontinst.  btw,
>could you please consider the approach of glyps aliasing provided by
>fnstcorr.tex and maybe include it into fontinst? it is a more
>convenient (imho) mechanism for renaming glyphs <<on the fly>> than
>the one provided in fontinst.

It is an interesting approach (and I actually did something
similar---worked only in the AFM to MTX conversion---in the ancestor for
\reglyphfont), but there is a problem in connection to the map file writer.
If the glyphs in a font have been aliased using your mechanism and then
reencoded, then the glyph names in that reencoding will not match the glyph
names in the font, which means the encoding specified to the driver will
not use the right glyph names!

It may well be possible to get around this in some way, but it needs to be
thought about. It is probably possible to put both the original and the
aliased glyph name in the MTX in some way (and in the same \setrawglyph
command, not in two separate commands) so that finstmsc.sty could determine
what the original glyph names were, but you still have the problem that you
need several .enc files for what really is the same encoding.

Lars Hellström