[Fontinst] Re: Bug in fontinstversion{1.927}

[Lars Hellström]

At 13.40 +0100 2005-01-31, Peter Dyballa wrote:
>Am 30.01.2005 um 16:25 schrieb Lars Hellström:
>
>> At 22.05 +0100 2005-01-27, Peter Dyballa wrote:
>>> It's no problem for me to write that I do not understand (now or in
>>> future) what you wrote,
>>
>> It sometimes happens that the reason a student fails to understand
>> something is that (s)he spends too much time asking and not enough time
>> studying the available literature. :-)
>
>Yes, can be. My problem is that for my other problem there is almost no
>literature available: how to map the fontinst names to Unicode
>descriptions?

The available literature should be sufficient to tell you that you
shouldn't do that (at least not for the purpose you have in mind). The
fontinst names are descriptions of glyph shapes, whereas the Unicode
standard is very explicit that its characters are _not_.

>Which is the right tie accent? What do I need to do with
>all those capital or bigger accents that can't easily be mapped?

Any sensible mapping to Unicode loses the distinctions between these.

>Neglect them? If so: when will I see boxes in a TeX document? And,
>damned, why do I see a tie accent hovering over soufflés that comes
>>from some completely different font?! (There *can* be some literature
>about exactly this that I haven't discovered or searched for yet!)

Checking the definition of \t in ltoutenc.dtx should explain at least how
this happens.

>>
>>> it's a bit too far away from my experience and
>>> my understanding. Isn't this statement doing the translation I
>>> mentioned before:
>>>
>>> 	\ifisglyph{afii61352}\then              \setglyph{numero}
>>> \glyph{afii61352}{1000} \endsetglyph \Fi
>>
>> This selects a glyph by name, not by its slot in some encoding.
>
>This is exactly what I believe too. I tried to give an example for what
>I call a "name translation." The cited one happens late during the
>\installfonts phase. I think it's worth doing it before, as a
>preparation of this final step of setting all already set up together.

Yes, that's how \reglyphfont is used. Explicit metric commands are easiler
when there are just a few glyphs that have to be given a new name, but when
there are a lot of them and it is just the name that is off, then
\reglyphfont is easier.

>To me it makes no difference whether I reference something by a number
>or a name, it's just one of many techniques to deal with things that
>are more complicated and meaningful than nothing. In real life I prefer
>real names, in IT life I prefer numbers,

Haven't you heard one should always define named constants to make the code
easier to modify?

>for example "(a) show" as in
>PostScript. (Can it be that it's not possible to write "(/a) show" in
>PS trying to output only the "a" without the "/" that addresses the "a"
>by its proper name?)

It is possible to write "/a glyphshow". (I've found this handy in PS code
for figures, as it takes away the need to bother with a font encoding, but
that's another matter.)

>And my access of IT things is rewarded from

Here you forgot a "partial" ...

>success: although the different TT fonts use different names I do not
>have to create different TeX formats as TT font drivers, it's
>completely sufficient that I stay to one syntax when addressing the
>wanted glyph by different TrueType glyph names (baht or bahtthai or
>Thaibhat or ...).

... since that's what it all comes down to. For some thing a mapping via
Unicode works fine; this is your partial success. For other things (such as
capital accents) it won't work.

>As far as I know TeX addresses members of a font set
>by numbers, at least for DVI output.

Yes. And this is part of the reason why in LaTeX every font has to be
declared as having a particular encoding.

>My understanding of my procedure
>
>    ttf2pt1 -l adobestd font.ttf font8a
>    ttf2pt1 -L 8p.map   font.ttf font8p
>
>and then in fontinst
>
>    \transformfont{font8r}{\reencodefont{8r}{\fromafm{font8a}}}
>    \afmtomtx{font8p} {font8p}
>    \mtxtopl{font8p} {font8p}

The last two commands are (mostly) unnecessary, since (if no MTX or PL file
already exists) \installfont et al. will do that automatically.

>                                 the name translation as mentioned above
>and a bit later in fontinst             |
>                                         v
>     \installfont{font8t}{font8r,font8p,8p,newlatin}{t1}{T1}{fnt}{m}{n}{}

8p.mtx is probably not the best name for that file. The existing
<encoding>.mtx files are meant for use with \installrawfont, and this file
is quite different from those.

>and in the map file
>
>     font8p FontName <font8p.pfb
>     font8r FontName <8r.enc <font8a.pfb " TeXBase1Encoding ReEncodeFont
>"
>
>is that I create a set of files that all bear a certain rule, an
>encoding -- or two, 8a and 8p (8r is something hypothetical or virtual
>to me since it is in the map file accomplished).

There's nothing virtual about 8r, it's just not built into the font as you
cause 8p to be. (And the comparison 8a/8r probably was the first example of
why it was _necessary_ to transcend the numbers: most 8a-encoded fonts have
glyphs that are not listed in the encoding, e.g. odieresis. Reencoding is
one way of doing that.)

>When I then do the
>"translation"
>
>   let:   name 2b at pos 2 in b of class 8p   equal   name 2a at pos 2
>in a of class 8p (too)
>
>no encoding changes (in the MTX file), except for the "encoding by
>name," that's now different -- but who else except of you cares?

I've never said it is wrong to change glyph names (although there are some
potential problems---see below). I said it is important to think of glyphs
in terms of names (rather than in terms of characters or numbers, since
these do not cover all possibilities).

And to answer your question, the PS interpreter that you target most
definitely cares about the names of glyphs. To it, the names of glyphs are
names of subroutines to execute!

Internally in fontinst, glyph names are just like variable names and can be
changed however one likes (i.e., the value of one glyph variable can be
copied to any other glyph variable). As far as things one does at
\installfont time are concerned, there is no risk that such name changes
can ever leak out to a PS interpreter, but name changes followed by a
\transformfont can screw up your encoding. Therefore the map file writer
will report an error if you try to do that.

>(Well,
>it's me, of course, since I don't have to learn by heart another
>encoding of up to 256 different names. The first 256 numbers I know by
>heart since some war time.) As I tried to show above, in my
>understanding TeX does not care of names but takes the position in an
>ordered set (my English can be bad at this point and I'm not used to
>mathematics too) to address a member of this set. So why should I
>consider names?

Because the names can identify the glyphs pretty much regardless of
context, whereas numbers are meaningless without a context. It is true that
the same glyph may come under several different names, but that is easy to
handle using e.g. \reglyphfont. (The opposite---a single name is used for
two very different glyphs---would be impossible to handle automatically.)

>They're just for us not that perfect humans planning
>globalization and other means of terrorism, as software and computers.
>
>>
>> Selecting glyphs by Unicode character is even at best an
>> imperfect mechanism, so there are tasks at which it will fail. (Cf. the
>> tex-fonts list posting on ttf2afm by Laurent SIEBENMANN recently.)
>
>Yes, I did understand that he is doing the same mistake

You mean Han The Thanh (Laurent merely forwarded a mail) is doing a
mistake? Ha! Not very likely in this case.

>so I reassured
>myself again not to pay that much attention to ttf2afm -- since *I* can
>use my own software! Or XeTeX/XeLaTeX.
>
>
>> And, to reiterate, I think \reglyphfont can do what you wanted
>> \translatefont to do, even though it doesn't quite have the interface
>> you
>> imagined.
>
>In my understanding of \reglyphfont it is not the same as the proposed
>\translatefont because it needs to know both *names* ("to" and
>particularly "from")

Yes.

>exactly which I try to avoid because it's sheer
>nonsense to write routines for literally thousands of deviating names
>that can change with re- or new release!

They don't. At worst there could be something like half a dozen (per glyph)
different names around, mostly because different foundries are using
different names, but they don't increase much over time.

Lars Hellström