Christopher Adams skrev:
What I don't understand is why A/E/a/eogonek and gbreve are not being taken
directly from the font, while, for example, iacute and acircumflex are.
First note that "the font", as it gets defined in a PS or PDF file, is
the *base* font; all glyphs will have to be expressed in terms of slots
in this font.
Second, look in the MTX file for the base font you're feeding into
\installfont, and compare the entries for e.g. iacute and eogonek. Most
likely, one is like
\setscaledrawglyph{iacute}{...}{...}{...}{237}{...}{...}{...}{...}
and the other is either missing or like
\setscalednotglyph{eogonek}{...}{...}{...}{-1}{...}{...}{...}{...}
The first says an iacute glyph appears in slot 237 of that font (named
in second argument). The second says an eogonek glyph is currently
unencoded (but might become available if the font is reencoded). The
first really defines an iacute glyph to fontinst, and the second
doesn't. Hence llbuild.mtx will later find eogonek undefined, and do
its best to provide one.
(For various arcane reasons, which are related to the AFM CC commands
Hilmar wrote about off-list, the \setscalednotglyph command *does*
define a pseudoglyph eogonek-not, but that's probably of no use to you.
There's still no slot in a font defined through any .map file which
corresponds to the proper eogonek defined in the PFB.)
The main point is that fontinst can't reach into the bowels of a font
and access arbitrary fonts therein, it can only make use of glyphs that
the DVI drivers assign to some slot of some font.
This point is somewhat blurred by the fact that it is often fontinst
that manufactures the mapfile lines that told the drivers about the
fonts in the first place, but in this area fontinst merely follows
orders, so if you didn't tell it to reencode a base font so that its
eogonek appears in some slot, then the eogonek of that base font won't
be available (as far as \installfont is concerned).
Lars Hellström
