[Fontinst] Re: glyph name aliasing

[Lars Hellström]

At 19.59 +0200 2005-05-03, Alexej Kryukov wrote:
>Dear Lars,
>
>sorry, I missed your reply to my message about
>aliasing, and only now found it in the mailing list archive.

My mistake. I got some sort of spam-filter-bounce, but (incorrectly)
presumed that you would anyway get the answer via the list.

>So I'm answering in another thread.
>
>> what will happen when some virtual font calls upon the glyph in
>> slot 17 (which fontinst was told by fasr8r.mtx is dotlessi)? The
>> PS interpreter will get element 17 of the TeXBase1Encoding array:
>> this is the name /dotlessi. Then it tries to look up the /dotlessi
>> entry in the font's CharStrings dictionary---but there isn't one,
>> since noone renamed the glyphs in the actual font! Instead the
>> substitution glyph /.notdef is  rendered.
>
>I don't see any problem here. Of course I understand, that, if I
>have processed a font with non-standard glyph names, I should
>also create a special *.enc file for it instead of relying on
>standard *.enc files (like 8r.enc) or on fontinst \etxtoenc macro.
>Since the enc file format is quite clear (at least much more simple
>than the etx format),

"More simple" I can agree on. "Quite clear" is more questionable; it's easy
to mistake simplicity for clarity of specification. Are spaces between
glyph names optional? Is the final "def" operator optional? Different
programs parsing ENC files have quite different opinions on these matters.

>this can be easily done by hand, and, once
>created, such *.enc file may be used in all subsequent versions
>of the font package, no matter, how many times the fonts itself
>are regenerated.

Well, if you've got the ENC (say foofont.enc) then to get the ETX you only
need to TeX a file saying
   \input finstmsc.sty
   \enctoetx{foofont}{foofont}
   \bye
so that's straightforward.

>> A solution which enables add-on packages such as fnstcorr.tex
>> to do this cleanly, namely the \aliased command, has been in place in
>> the core since v1.915 and is described in the current manual
>> (Subsection 6.4), but fnstcorr.tex still hasn't been updated to take
>> advantage of that.
>>
>> It should be sufficient to change
>>
>> \def\charnamealias#1{%
>>   \@ifundefined{GN@\charnameprefix#1}%
>>     {\@ifundefined{GN@#1}{#1}{\csname GN@#1\endcsname}}% was just {#1}
>>     {\csname GN@\charnameprefix#1\endcsname}}
>>
>> to
>>
>> \def\charnamealias#1{
>> \string\aliased{#1}{
>>   \@ifundefined{GN@\charnameprefix#1}%
>>     {\@ifundefined{GN@#1}{#1}{\csname GN@#1\endcsname}}% was just {#1}
>>     {\csname GN@\charnameprefix#1\endcsname}
>> }
>> }
>
>First, the definition you propose should at least be modified in order
>to prevent writing useless \aliasing commands even for those glyphs
>which already have "standard" (form fontinst's point of view) names.

Yes, one could do that, although the savings wouldn't be very noticable.
(\aliased is simply the macro #1#2 -> #1 or #1#2 -> #2, so the processing
time is near zero. One would gain something in reducing the file size and
thus do less I/O, but nowadays that's not very noticable either.) Anyway,
my main point was that one could accomplish this with a very small change.

>Second, using \aliasing means that I can get with single mtx for
>a specific set of glyphs, but still need separate etx files
>for almost any specific font I am installing. Unfortunately, this
>solves only a half of the problem. It is very inconvenient to
>write a new etx file just because of a buggy font with incorrect
>glyph names: much less convenient than creating only an *.enc file
>for dvips.

As explained above, one is only an autoconversion away from the other.

>And, of course, there is a problem of distribution. If I have used
>a specific *.etx file for installing a publicly available font package,
>I probably should make this file publicly available too. However, it
>is inconvenient to include it into the font package itself, since this
>file is not needed for its proper functioning (unlike the corresponding
>enc file, which *is* needed anyway). So, how should I distribute it?

Presumably the ETX file wouldn't be the only file you needed to do the
installation, so it would naturally be distributed along with the command
file that makes use of it. ;-)  It's all or nothing.

>This is one more reason to have as few etx files as possible and as
>many enc files as needed.

That can only work as long as you write all your map files yourself. If you
have a fixed set of base fonts that might be workable, but if it evolves
over time then it rather quickly stops being fun (especially if you make
use of things like \yscalefont). Generating ETX files (which, as explained
above, can be automated) for the proper encoding vectors is in comparison a
small effort.

It could however be more convenient.

When one generates an ETX file from an ENC file one doesn't want fontinst
to overwrite the original ENC file with one autogenerated from the ETX.
This is in principle simple --- all one needs to do is declare the encoding
so that the map file writer knows it doesn't have to generate an ENC file
for it, and this takes just a single \declarepsencoding command --- but for
this particular case when the ENC name etc. actually has been known to
fontinst at some point in time, it could be made even simpler. (All it
takes is recording in the generated ETX file the name of the original ENC
file and encoding vector, and then passing that information back to the
"recorded transforms" file.) I'll have a look at it.

Thanks for the inspiration!

Lars Hellström