[Fontinst] extension of \etxtoenc

[Lars Hellström]

At 16.42 +0200 04-06-24, Werner LEMBERG wrote:
>> >  Currently, I do
>> >
>> >    \let\setnotglyph \setrawglyph
>> >
>> >  in the fontinst control file.
>>
>> I can't see why it would be necessary, though.  If you always assign
>> slots to all glyphs then it shouldn't make any difference, since all
>> these commands would become \setrawglyphs after reencoding anyway.
>> (Or actually, they would become \setscaledrawglyph commands.)
>
>Hmm.  Assume that glyph `foo' has index 1 in the AFM file and `bar'
>index -1.  Without the above \let, the names within fontinst for those
>two glyphs are `foo' and `bar-not'.  If I have e.g.
>
>  \Ligature{LIG}{foo}{bar}{foobar}     ,
>
>fontinst emits a warning that glyph `bar' isn't available, and I had
>to write
>
>  \setglyph{bar}
>    \glyph{bar-not}{1000}
>  \endsetglyph
>
>to overcome this.
>
>Am I missing something?  Actually, I can't see any reason to ever use
>\setnotglyph in case an ETX file is used.  Can you give an example for
>a useful \setnotglyph?

The way \setnotglyph works is very much a compromise. The basic argument is
that \setnotglyph{bar}...  should _not_ set the 'bar' glyph because the
next base font may contain a \setrawglyph{bar}...  This is very important
with large fonts, where a single base font encoding might not be enough to
cover all available glyphs, and one thus have to use several.

The question is then why \setnotglyph does anything at all. I think the
reasoning behind that was that some fonts (in the early 90's, at least)
contained a lot of CC glyphs for accented letters, including some for
eastern European languages (thus wanted for T1 fonts). These could not be
made available as individual glyphs in the base font (there wasn't enough
slots, or perhaps font reencoding wasn't commonly available back then), but
they could be built in the virtual font. \afmtomtx interprets CC lines and
generates equivalent \glyphpcc instructions to support precisely that. The
only catch is that CC lines do not specify the metrics of these composite
glyphs -- that is instead to be found in a previous C line, which would
have been turned into a \setnotglyph. Hence \setnotglyph had to stick the
metric information somewhere that it could be retrieved. Therefore the -not
glyphs were born.

As for ways to overcoming your problems, there are two approaches:

1. If 'bar' is supposed to appear in actual documents, then you have to
make 'bar' really available in some base font. There is no way around that!
Your DVI driver cannot access unencoded glyphs, because there is no such
thing as encoding position -1 in postscript. Indeed, the VF format does not
support negative character indices (such as the -1 for 'bar') in base
fonts, so trying to use such a character will probably lead to complaints
from VPtoVF.

2. If 'bar' is not supposed to appear in actual documents (only 'foobar'
is, and 'bar' is simply some helper similar to 'lslashslash'), then you
probably rather want some equivalent of \unfakable{bar}, i.e.,

   \setglyph{bar}
      \glyphrule{500}{500}
      \glyphwarning{missing glyph `bar'}
   \endsetglyph

or

   \setglyph{bar}
      \glyphrule{500}{500}
      \glyphspecial{Warning: missing glyph `bar'}
   \endsetglyph

fontinst won't complain (at least not with the latter), and anyone failing
to get the foobar ligature should get some kind of warning when printing or
previewing the DVI.

Lars Hellström