# [Fontinst] extension of \etxtoenc

Lars Hellström Lars.Hellstrom at math.umu.se
Thu Jun 24 16:17:05 CEST 2004

At 14.27 +0200 04-06-23, Werner LEMBERG wrote:
>[fontinst 1.926]
>
>. While the third argument of \installrawfont (and \installfont) can
>  take a list of ETX files, \etxtoenc currently can't.  Please add
>  this feature to \etxtoenc so that I can customize the creation of
>  the ENC file as with \installrawfont.

Hmm... I hadn't though of that. Shouldn't be too hard.

I'm not too fond of introducing LaTeX-style optional arguments in fontinst.
(I _did_ introduce such arguments for \usemtxpackage, but I now consider
that to be a mistake.) For one, there isn't any generic code for processing
such arguments, so it would be a bit messy.

>  to
>  \etxtoenc, specifying the name of the PS encoding?

Do you need to set a PS encoding name that is _different_ from the one
specified in the ETX file? What is the point of having two PS names for the
same encoding?

>  Currently, I do
>
>    \setstr{encodingname}{C90Encoding}
>    \offcommand{\setstr}
>    \etxtoenc{c90}{c90}

You don't have to do the \offcommand there, do you? Remember that \set...
means "assign if not already assigned".

>  which I've found only after looking into the sources.

True. It is described in the introductory section (of the source) on
fontinst variables, though.

>  I would like
>  to write this:
>
>    \etxtoenc[C90Encoding]{c90}{c90}

I think

\setstr{encodingname}{C90Encoding}
\etxtoenc{c90}{c90}

is quite reasonable. Of course, you can always define

\setcommand\etxtoencWithName#1#2#3{
\setstr{encodingname}{#1}
\etxtoenc{#2}{#3}
\unsetstr{encodingname}
}

if you do it a lot.

>. Another (minor) problem is the classification of glyphs in AFM files
>  with \setrawglyph and \setnotglyph.  I switch this off since I
>  always provide a custom encoding vector.  Currently, I do
>
>    \let\setnotglyph \setrawglyph
>
>  in the fontinst control file.  Is there a better, official' way?

This is pretty much what fontinst hacking look like, so no, there is no
higher level command for doing this kind of thing.

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.)

You could however get in trouble if something should have stayed a
\setnotglyph, because that would then be treated as a request for the glyph
in slot -1 of that font. I think it would simply be copied to the (V)PL,
which (at best) would result in some kind of out-of-bounds complaint from
VPtoVF.

>. In combination with the last item I find it surprising that there
>  apparently is no easy way in fontinst to activate warning messages
>  for missing glyphs.  For example, if glyph foo' is wanted in the
>  ETX file, and the MTX file(s) doesn't provide it, fontinst silently
>  goes on.

Good point. I suspect this is because traditionally there has almost always
been a couple of glyphs missing, but there should be an interface for it.

>  I have to use this ugly hack in the control file:
>
>    \fontinstcc
>      \def\do_slot{
>        \if_undefined{g-\slot_name}\then
>          \fontinstwarningnoline{fontinst}
>                                {missing~glyph~\slot_name'\space
>                                 for~slot~\the\slot_number\space
>                                 in~font~\out_filename'}
>        \fi
>        \do_character
>      }
>    }
>    \normalcc

It would probably have been slightly easier to redefine \do_character.

>. Finally, I suggest to suppress the creation of foo.pl in
>  \installrawfont while fontinst is reading foo.afm (creating only
>  foo.mtx) -- since no virtual font is created, there is no need for a
>  ligature-less base font.

Apart from the fact that it would be kind of messy to achieve this, I don't
think you can be sure that there is no need for that PL. Even though it is
not needed for the \installrawfont command, there _could_ be a subsequent
\installfont command which would use that as a base font for a virtual font.

Underneath this lies an assumption that if an MTX file declares raw glyphs
in some font then there will be a corresponding PL file for that font. This
assumption is not always correct, but I think changing fontinst to remove
it would be rather hard.

Lars Hellström