[Fontinst] Bug in fontinstversion{1.927}

[Lars Hellström]

At 17.59 +0100 05-01-01, Peter Dyballa wrote:
>Am 01.01.2005 um 16:35 schrieb Lars Hellström:
>
>>> In t1.etx they're documented as being in the slots 141 and 173
>>
>> Yes.
>
>Doesn't this mean too that T1 encoding or font8t has eng/Eng?

If it is provided in the glyphbase, yes, ...

>I thought
>this is true, so I was a bit puzzled that that the glyphs were not put
>into the Property List files.

but what you see is most likely something like

(CHARACTER D 141 (COMMENT Ng)
   (CHARWD R 0.477)
   (CHARHT R 0.477)
   (MAP
      (SETRULE R 0.477 R 0.477)
      (SPECIAL Warning: missing glyph `Eng')
      )
   )

because the only metric command that made any attempt to set this glyph was
the "missing glyph" fallback \unfakable{Eng}. If you don't actually provide
the proper glyph, it cannot be used.

>This is a different problem the Lira/fii08941

It is an entirely similar problem, only with fewer variants. Where you have
Lira/afii08941/lira, someone once had to deal with Eng/Ng. None of these
glyphs is provided by the 8r encoding.

>(and bahtthai, the other
>glyph) problem. I solved this in creating new ETX files with these
>diff's:
>
>485c486
>< \setslot{lira}
>---
> > \setslot{afii08941}
>527c528
>< \setslot{baht}
>---
> > \setslot{bahtthai}

That's the more complicated solution, since it is harder to adapt.

>I made them two because *I* now know which font has lira and which not
>and don't know enough about TeX to make it a one of n select statement.

This is where it is convenient that fontinst's semantics for \setglyph (and
other \set... commands) is "if not already set, then set to ...". The
effect of

\ifisglyph{Lira}\then
   \setglyph{lira} \glyph{Lira}{1000} \endsetglyph
\Fi
\ifisglyph{afii08941}\then
   \setglyph{lira} \glyph{afii08941}{1000} \endsetglyph
\Fi
\unfakable{lira} % This is not a standard fontinst command,
                 % but many of the standard MTX files
                 % (e.g. textcomp.mtx) define it.

is precisely to select as 'lira' the first one that happens to exist of (i)
'lira', (ii) 'afii08941', (iii) 'Lira', and (iv) the "missing glyph"
fallback.

>And I actually don't know whether it works besides *not* telling me
>about the missing lira in TS1,

True, these "missing glyph" messages are emitted due to the \unfakable, not
because the glyph is not set. But you can try setting the 'requireglyphs'
integer before the \installfonts; this will cause \setslot to emit warnings
about undefined glyphs when making a font.

>because there are some more open issues
>before I can try a 'pdflatex nssfont'. For example to see no missing
>Greek glyphs I had to write statements à la
>
>\transformfont{slsrt7r}    {\reencodefont{ot1} {\fromafm{slsrt8a}}}
>
>and later
>
>  \installfamily{OT1}{slst}{\hyphenchar\font=-1}
>   \installfont  {slsrt7t}   {slsrt7r,slsrt8r,newlatin}
>{ot1tt} {OT1}{slst}{m}{n}{}
>   \installfont  {slsrct7t}  {slsrt7r,slsrt8r,newlatin}
>{ot1ctt}{OT1}{slst}{m}{sc}{}

Yes, that's roughly what you have to do; one base font won't provide all
the glyphs you need, so you need to use (at least) two base TeX fonts for
every TrueType font, just to cover all the glyphs. Since most of OT1 (over
100 glyphs) is already covered by 8r, it is suboptimal to use as additional
encoding. Better would (as I suggested previously) be to make up an
completely new encoding with only those glyphs that are not covered by 8r.

>Fontinst 1.x might be OK for that limited PostScript fonts, but for
>inclusion of TrueType in (La)TeX Fontinst seems to me a bit limited.

I can agree it may seem awkward, but the only restriction here that is due
to fontinst is that of not being able to read binary file formats directly,
and as you have noticed, it isn't much of a problem to generate AFMs for
TrueType fonts, so that is not the issue here.

The limitation you are encountering is that of byte-adressed fonts, and
this is nothing fontinst can do much about[*]; the restriction to 8 bits is
very firmly built into both TeX, Postscript, and most DVI drivers. This
restriction is also why ttf2pt1 support "plane language" options such as

  -l plane+0x02

-- not because a font which has Latin Extended-B glyphs in slots 0--79 and
IPA glyphs in slots 80--255 makes any logical sense, but because it is
rather awkward to make use of more than 256 glyphs from a single font, and
thus often convenient when generating PS or PDF to split up logical fonts
in pieces of 256 glyphs each. Sometimes this is done by splitting up into
several PFBs, sometimes it is done by having one huge PFB and reencode it
in several different ways, but either way the PS code generated will refer
to several different fonts with up to 256 glyphs in each. If the DVI driver
can't do that automatically for you, then you will have to handle this at
the virtual font level, and fontinst can get all the numbers right for you;
you only have to tell it which the pieces should be by providing the
relevant encodings.

>ttf2p1 V3.4.4 creates with t1asm's help PFB files that contain all
>glyphs of the original TrueType font and an AFM file describing them
>all. And I have finally to understand that T1 and 8r are two different
>things as an upright bike and a recumbent!

T1 was optimised for providing hyphenatable text in a large number of
languages. 8r was optimised for covering as many of the glyphs commonly
occuring in fonts of the time it was designed, but was never meant for
direct typesetting.

>Unless I create my own T1
>encoding for PostScript

Probably no need to create one yourself, there are oodles of them in the
standard dvips distribution.

>I won't see the glyphs as described in T1.etx
>(or TS1.etx). Is it this what you are trying to tell me?

Sort of, but it's not quite that strict. You don't have to use the same
encoding for a base font as for the virtual font that is built on top of
it, but the virtual font can only provide glyphs that are available in some
base font. When fontinst encounters the \setslot{Pi} in ot1.etx it will
look to see if a glyph named 'Pi' has been set in its glyphbase. The glyph
definition may (depending on which fonts \installfont was told to read the
metrics of) point to slot 5 in font slsrt7r, slot 80 in font psyr (Symbol),
slot 112 in font Math1 (a font that comes with Mathematica), or just
consist of a "missing glyph" rule, but fontinst will indifferently convert
that glyph definition to the equivalent CHARACTER property list and write
that to the VPL file.

To exemplify what I wrote last year, I would do

\transformfont{slsrt5z}{\reencodefont{slst5z}{\fromafm{slsrt8a}}}

and later

\installfont{slsrt7t} {slsrt8r,slsrt5z,newlatin} {ot1tt} {OT1}{slst}{m}{n}{}
\installfont{slsrt8t} {slsrt8r,slsrt5z,newlatin} {t1}    {T1}{slst}{m}{n}{}
\installfont{slsrt8c} {slsrt8r,slsrt5z,textcomp} {ts1}   {TS1}{slst}{m}{n}{}

where slst5z.etx can be

\relax
\encoding

\setslot{Gamma} \endsetslot

\setslot{Delta} \endsetslot

\setslot{Theta} \endsetslot

\setslot{Lambda} \endsetslot

\setslot{Xi} \endsetslot

\setslot{Pi} \endsetslot

\setslot{Sigma} \endsetslot

\setslot{Upsilon} \endsetslot

\setslot{Phi} \endsetslot

\setslot{Psi} \endsetslot

\setslot{Omega} \endsetslot

\setslot{afii08941} \endsetslot

\setslot{bahtthai} \endsetslot

\setslot{Lira} \endsetslot

\setslot{Eng} \endsetslot

\setslot{eng} \endsetslot

% And so on, listing all the glyphs you may have but are missing
% from 8r, in no particular order.

\endencoding


In addition to the above, one might also need an extra metrics file that
looks for glyphs under names that are alternative to those used in the
standard ETX files and copies them as in the 'lira' example above. If you
care to look, you will find that this trick is used in many places in
latin.mtx, textcomp.mtx, and friends.

Lars Hellström

[*] In fact, the only thing that restricts fontinst to making 8-bit fonts
is a technicality that slot numbers must be valid values for a \chardef. If
fontinst is run on Omega rather than TeX then it should be possible to
create fonts with slot numbers up to 65535. (TeX wouldn't be able to use
such fonts, because the TFM format does not support them, but Omega should,
after one converts the files generated by fontinst to OFM format.)