[Fontinst] Mantinia

[Adrian Heathcote]

>> VI
>> MB
>> MD
>> MP
>> TY
>> the tall I
>>
>> are not in the print outs. Other glyphs get substituted. So it
>> looks as though the glyphs are not exactly where they are in the
>> Windows distribution---which is what Alan used.
>
> So what's in the afm files? How are these glpyhs labeled?

The file names conform to the Mac Roman encoding.

>  Are they
> encoded by default?

Yes, that's the good news. Nothing in this font has slot -1. Everything 
is encoded. The problem is just the names.
>
>> So my question is: can I find out by some method---I guess by
>> reverse engineering---where these missing glyphs are?
>
> Look at it in a font viewer/editor that will display the encoding slot
> number along with the PostScript glyph name. Which platform are you
> on? I could recommend some UNIX apps...

On MacOsX. So UNIX apps are good.
>
>> I know the
>> key strokes that produce them. So, for example, VI is produced by
>> shift-option-v in the standard Mac program. But that ought to be
>> slot 215: lozenge. But fontinst chokes when I substitute lozenge
>> into the \saveglyphas{}{} (first) slot. And when I look at the afm
>> of another font, with Adobe Standard Encoding, slot 215 seems not
>> to exist at all.

But if I know the keystrokes that produce the problem glyphs, and I can 
use that to find the slot number, then can't I just use your extended 
8r encoding to access these glyphs under their MacRoman names? But am I 
right in thinking that the first line here

\transformfont{manr8r}{\reencodefont{8r}{\fromafm{manr8a}}}
\installfonts


needs to be changed to something like

\transformfont{manr8r}{\reencodefont{8r}{\fromafm{manr8m}}}
\installfonts                                                           
                       ^^

Or should it be left as 8a?
>
> Hhm, that reminds me of the problems I was facing when trying to
> install FF Kievit. That's what triggered the update to 8r. Basically,
> it's like this:
>
> Kievit is based on Adobe Standard encoding but since it apparently
> comes from the Mac, some of the glpyhs are labeled using MacRoman
> glyph names. The non-standard 'fj' ligature was encoded as the
> MacRoman glpyh 'Delta', 'ffi' is labeled 'infinity' and so on.

How did you find out they were there in this instance?

>  Since
> the actual encoding of the PS fonts is MacRoman, these glpyhs are
> unencoded (slot -1) in the final fonts. So this is what the afm files
> have:
>
> C -1 ; WX 537 ; N Delta ; B 20 -230 449 732 ;   # in fact fj
> C -1 ; WX 799 ; N infinity ; B 20 0 711 732 ;   # in fact ffi
>
> The fact that these glyphs are unencoded is the tricky part because
> you can't rename them in this state. I modified 8r, adding the
> MacRoman glyph names so that 'Delta' and 'infinity' are picked up
> when fontinst reencodes the font to 8r. These changes are in the 8r
> vectors I've sent to you. If Mantinia uses MacRoman glyph names as
> well, you're almost set.
>
> The second step is renaming the glyphs to something meaningful. For
> example, I've put the following in a dedicated metric file:
>
> \resetglyph{ffi}
>   \glyph{infinity}{1000}
> \endsetglyph
> \setleftrightkerning{ffi}{infinity}{1000}
> \unsetglyph{infinity}
>
> \resetglyph{fj}
>   \glyph{Delta}{1000}
> \endsetglyph
> \setleftrightkerning{fj}{Delta}{1000}
> \unsetglyph{Delta}
>
> When building T1 encoded VFs, the 'ffi' ligature will be instantly
> available. 'fj' still requires modifying t1.etx, but that's easier as
> you don't need to reencode on the VF level so all you need to do is
> hack the encoding file for fontinst without having to worry about
> dvips, map files etc.
>
> Does that come close to your problem?

I think this must about solve it. Thanks a lot.

Cheers

Adrian Heathcote