[Fontinst] Bug in fontinstversion{1.927}

[Peter Dyballa]

Am 02.01.2005 um 01:21 schrieb Lars Hellström:

>> 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.

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)
       )
    )


>> 485c486
>> < \setslot{lira}
>> ---
>>> \setslot{afii08941}
>> 527c528
>> < \setslot{baht}
>> ---
>>> \setslot{bahtthai}
>
> That's the more complicated solution, since it is harder to adapt.

Ahh, you don't imagine what hard things I can manage!

>
>> 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.

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

>
>> 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.

Well, I understood now, that it does not help just to copy things I've 
seen. The 8r encoded MTX files do not contain all the OT1 or T1 or TS1 
glyphs so it's close to nonsense to create an OT1 or T1 or TS1 based 
MTX from such a set.

>> 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! It either rejects them or claims 
"I've a better one already faked!" 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. At least with 
recent Unicode versions we have more than one real plane of 64k slots, 
i.e. more glyphs that 16 bits can count for. Our Latin glyphs + Greek, 
Cyrillic, Arabic, Hebrew, CJK, and many others are in the Basic Plane. 
Those who have Mac OS X 10.3 can open the Character Palette utility and 
if they scroll to the end see character positions beyond FFFF (ancient 
Linear B, Cypriot, so called Aegean Numbers, Etruscan, Ugaritic 
cuneiforms ...)! My first approach was to convert TT to PS pagewise in 
that plane, with pretty good results re-encoding the AFM freight into 
OT1, T1 and TS1 encoded metrics (or for math use). But it was a mess of 
PFB and enc files. So I decided to try a new approach, more 
conventional.

>> 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.
> 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
>
> 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.

It would be something like convert the ETX files OT1, T1 and TS1 into 
encodings 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!

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:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8+.etx
Type: text/x-setext
Size: 6188 bytes
Desc: not available
Url : http://tug.org/pipermail/fontinst/attachments/20050102/1dfffb2b/8.etx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8+.mtx
Type: application/octet-stream
Size: 10060 bytes
Desc: not available
Url : http://tug.org/pipermail/fontinst/attachments/20050102/1dfffb2b/8.obj
-------------- next part --------------


Are they right?

--
Greetings

   Pete

"One person with a belief is a social power equal to ninety-nine who 
have only interests." - John Stuart Mill