Comments wanted: Directory structure of fontinst/inputs/

[Lars Hellström]

At 19.14 +0200 2000-09-05, Vladimir Volovich wrote:
>"LH" == Lars Hellström writes:
[snip]
> LH> It is an interesting approach (and I actually did something
> LH> similar---worked only in the AFM to MTX conversion---in the
> LH> ancestor for \reglyphfont), but there is a problem in connection
> LH> to the map file writer.  If the glyphs in a font have been
> LH> aliased using your mechanism and then reencoded, then the glyph
> LH> names in that reencoding will not match the glyph names in the
> LH> font, which means the encoding specified to the driver will not
> LH> use the right glyph names!
>
> LH> It may well be possible to get around this in some way, but it
> LH> needs to be thought about. It is probably possible to put both
> LH> the original and the aliased glyph name in the MTX in some way
> LH> (and in the same \setrawglyph command, not in two separate
> LH> commands) so that finstmsc.sty could determine what the original
> LH> glyph names were,
>
>yes, it should be thought about; afaik, this aliasing mechanism can
>affect only the .enc writer of fontinst

It does in fact affect the map file writer as well, since I've assumed that
there is a mapping from ETX files (that are used in reencoding) to ENC
files. (This mapping is implemented as the \pse-ENCODING table.)

>(which appeared just
>recently). other possible solutions could be:
>
>* redefine mtx-reading commands instead of afm-to-mtx-writer so that
>  the glyph description commands from mtx files would search for
>  aliasing glyph names. with this we will loose useful comments in VPL
>  files that some glyph taken from some font is really the aliased
>  glyph (but not an incorrect name specified in AFM files)
>
>* extend the \setrawglyph command (which is only used for ENC-writer?)
>  with one more argument specifying the original glyph name. Other
>  commands such as \setkern should use aliased glyph names.

What I think would be the best solution is this: Change the glyph aliasing
mechanism to write \setrawglyph commands as

  \setrawglyph{\aliased{<font's glyph name>}{<your glyph name>}}...

(not changing the syntax of \setrawglyph itself; adding another argument is
hardly possible since \setscaledrawglyph already has 9 parameters). The
\aliased macro is normally defined to be \second_of_two, i.e., #1#2->#2,
although \mtxtomtx would redefine it locally. This way, you can still use
your glyph names in files analogous to latin.mtx and the ETX files used
with \install... commands.

When reencoding a font, \mtxtomtx would instead go by the first argument of
\aliased, and the entire first argument of \setrawglyph would be copied
verbatim to the new MTX. That way, raw fonts would be reencoding using ETX
files which use the same glyph names as the base font, and the map file
writer would be happy. An example: Suppose you've got two raw fonts---one
called za which uses afii-names for the glyphs and one called zu which uses
urw-names. Then you would generate the corresponding 6r-enconded (I'm
assuming 6r is the raw encoding for cyrillic, but I'm not sure) MTXs as

\transformfont{za6r}{\reencodefont{6rafii}{\fromafm{za}}}
\transformfont{zu6r}{\reencodefont{6rurw}{\fromafm{zu}}}

where 6rafii lists the encoding using afii glyph names whereas 6rurw lists
the encoding using urw- glyph names. It would be possible to make
6rafii.etx and 6rurw.etx mere derivatives of 6r by using some trick similar
to the \uc, \lc, \lclig, etc. macros in ot1.etx and t1.etx. Anyway, since
the map file writer sees two different encoding names, it won't get
confused.

In a little longer perspective, it would probably be possible to make an
"intelligent" form of \reencodefont that automatically selects the right
encoding variant by looking at what glyph names are used in the MTX to
transform.

> LH> but you still have the problem that you need several .enc files
> LH> for what really is the same encoding.
>
>why? only one enc file is needed -- with glyph names corresponding to
>original font (i.e. non-aliased).

You can cope with one file if you only got one font, but in a system with
many fonts you may need to have several ENC files. In the above example,
you cannot use the same 6r.enc for both za and zu. Using 6rafii.enc and
6rurw.enc for za and zu respectively would however work.

Lars Hellström