[Fontinst] Bug in fontinstversion{1.927}

[Lars Hellström]

At 22.05 +0100 05-01-02, Peter Dyballa wrote:
>Am 02.01.2005 um 01:21 schrieb Lars Hellström:
>
>
>In an earlier attempt I had something like this:
>
>(CHARACTER D 141 (COMMENT Ng)
>    (CHARWD R 0.603)
>    (CHARHT R 0.723)
>    (CHARDP R 0.205)
>    (MAP
>       (SELECTFONT D 1) (COMMENT slsbt8r-01 at 1.0)
>       (SETCHAR D 74) (COMMENT Eng)
>       )
>    )

Good! This means you have a proper Eng (slot 74 in font slsbt8r-01) available.

Also, I have to ask: Is the font you're working with really a "Sun
LucidaSans Bold Typewriter", as is the Fontname scheme interpretation of
'slsbt'?


>So it should be worth to augment the official textcomp.mtx with names
>I'll find in my further (re)search?

Yes, that would probably be a good idea (Hilmar Schlegel suggested a
similar course of action to me off-list a couple of days ago): the fontinst
standard MTX and ETX files should probably be augmented to take advantage
out of the box of the larger glyph collections that are becoming common
nowadays.

But when you conduct this research, be sure to keep notes of which fonts
provide which glyphs and under which names, as that can be very valuable
information in the future development.

>>> 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.
>
>I understand and accept this limitations of TFM and VF formats. I just
>am not satisfied that fontinst can't fish the needful glyphs out of a
>big bowl of Unicode character soup!

Ah, but it can! What mostly seems to be troubling you is that one cannot
grab more than 256 glyphs in each bucket, because the bowl has a rather
small opening. It's true that you also get a lot of \setnotglyph's, but
these are just mirages: you can look through the sides of the bowl and see
how large the glyphs are, but you cannot use them to make an imprint on
anything. In order to fish out more glyphs, you need to grab a second
bucket.

If you mean to say that "why can't I just feed my huge AFM to fontinst and
have it split the font up into workable pieces" then you may have a point,
but I'm not sure it would be a good idea to do it like that. Automatically
splitting fonts up would mean automatically generating encoding files, and
the sheer number of these could easily become unworkable. If font A has one
glyph less than font B then the result could be that most pieces for A is
one position off from the pieces of B, in which case they would be
different and thus require separate encodings. One could easily end up with
a number of encodings that is an order of magnitude greater than the number
of fonts one is working with, which from most points of view is a
maintenance nightmare. Better then that someone sits down and manually
works out a couple of encodings that can be used for a large number of
fonts.

>It either rejects them or claims
>"I've a better one already faked!"

No, _that_ should not be the case. With the exception for some glyphs in
monowidth fonts, the standard MTX files do not overwrite an existing glyph
with a fake. (It's a bug if they do.) At worst, they may fail to make use
of an existing glyph if its name is unfamiliar.

> I think it's the matter with
>setnotglyph/setscaledrawglyph that makes it so ungrateful for such an
>overwhelming input ...
>
>> 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
>
>The use of the term plane is in this context wrong. IMO.

That complaint should of course be directed towards the ttf2pt1 developers,
as it's entirely their terminology.

>It would be something like convert the ETX files OT1, T1 and TS1 into
>encodings

(Which is what the finstmsc.sty command \etxtoenc is for.)

>and make of them a sorted list of unique PostScript glyph
>names. The same for 8r.enc. A bit of comm -- and the difference is
>almost 160 names!

Sounds plausible. About 60 of these are probably letters that are not found
in the classical Western European fonts but can be decently constructed by
fontinst. Another bunch of glyphs have traditionally been found in Expert
fonts, so it might be more fair to compare T1+OT1+TS1 against 8r+8x, but
indeed there is a difference.

>On the other hand ttf2pt1 allows to excerpt and encode only those
>glyphs as given in an encoding file. So I could create one PostScript
>font 8r encoded and another one 8+ encoded. Every OT1, T1, or TS1
>encoded TeX font would then use glyphs out of both PS fonts ...
>
>Lars, you're probably a man of phantasy

?

>and did imagine I'd write these
>two files:
>
>	name="8+.etx"

That looks OK. No need to quote me as an author. 8+ is probably not the
best name, though (looks a bit like it was generated by mistake).

>
>	name="8+.mtx"

This one does not make sense. Take for example

  \ifisglyph{Abreve}\then
     \unfakable{Abreve}
  \Fi

This does nothing if there is no 'Abreve' glyph, and it doesn't do anything
if there is an 'Abreve' glyph either, because \unfakable is usually defined
as

  % \unfakable is a glyph which can't be faked.
  \setcommand\unfakable#1{
     \setglyph{#1}
        \glyphrule{\int{xheight}}{\int{xheight}}
        \glyphwarning{missing glyph `#1'}
     \endsetglyph
  }

and \setglyph does nothing if the glyph it would have set has already been
set. The whole construction is just much ado about nothing, and all but two
commands in the file seems to be of this form.

Furthermore the use of the \unfakable command means there is a dependence
on some file that defines it, e.g. ltcmds.mtx, and a metrics file should
end with \endmetrics, not \endencoding.

The only two things that make sense are:

  \ifisglyph{afii08941}\then
     setglyph{lira} \glyph{afii08941}{1000} \endsetglyph
  \Fi
  \ifisglyph{bahtthai}\then
     \setglyph{baht} \glyph{bahtthai}{1000} \endsetglyph
  \Fi

Lars Hellström