8x.afm, no .vpl
Fri, 1 Feb 2002 16:35:37 +0100
At 14.36 +0100 2002-02-01, Christian H. Kuhn wrote:
>Axel Rose wrote:
>> To avoid confusion with Adobe produced fonts I first named
>> it "rhar8a.afm". I then went through the fontinst procedures
>> but was only partially successful. German umlauts and the EURO
>> could not be output.
>They will not be found at the proper positions. You will have to
>write your own .etx-file. good luck ;-)
Glyphs in a base font which do not have encoding positions (the AFM line
says C -1 ; ...) can not be accessed by TeX. You have to reencode the font
(\transformfont in fontinst, ReEncodeFont in dvips psfonts.map, etc.) ---
thus producing something which to TeX is a completely new font (it has a
different name, and hence a different TFM file) but where the glyphs are
accessible since they have encoding positions.
Glyphs in a base font which have encoding positions (the number after C in
the AFM line is non-negative) can be accessed by TeX regardless of what the
encoding as a whole looks like. fontinst can use the glyphs in the virtual
fonts it makes.
If fontinst is given (in parameter #2 of \installfont) two sets of metrics
for a font then any glyph accessible in at least one of them can be used in
the VPL generated; a glyph will be taken from the first font in which it is
accessible. In practice there is often a standard encoding which assigns
encoding positions to all glyphs in a font and therefore one seldom uses a
font in two different encodings, but in this case it might be the simplest
way (avoiding a custom ETX file) to access the euro glyph.
The umlaut is another matter. Is perhaps the glyph name `umlaut'? latin.mtx
only makes use of such a glyph if its name is dieresis. Putting the command
in a .mtx file that you list before latin.mtx in the \installfont argument
should fix things, if the problem is that the glyph is named `umlaut'.