You are making a Type 1 font, yes? In FontInfo/Encodings try selecting 'Bitstream Font Set' in the Microsoft Character Set. This is a strict cell-by-cell encoding of what you have in your FontLab font window in Names mode.

Right, Type 1 -- I thought that way I could just keep Monotype's hinting and not worry about it.

Thanks for the tip. I'll definitely try that.

I'm a little lost on what it actually means, though. What does the Character Set option do to the encoding? And how does one decide which set to select?

The Character Set option determines how the first 256 characters in the font are interpreted, and whether they are re-ordered. If, for example, you select 'Western (Latin 1)...' the characters will be re-ordered to match that character set. The Bitstream Font Set is a fixed encoding that is not re-ordered, hence its usefulness for making custom fonts.

<i>And how does one decide which set to select?</i>

Years of painful experience.

But why does the ordering matter?

I thought the point of the encoding table was to match a standard set of names with glyphs. Unless the ordering alters which name is paired with which glyph, how does it affect the application?

I tried your advice, and using the Bitstream Character Set results in a font that works fine for applications that operate under Classic in OS X. But it still produces weird results in OS X proper (in both Carbon and Cocoa apps). E. g., the same file comes up correct in Endnote 5, but not in Endnote 6. It's even worse in Mellel and Word.

For some reason, InDesign seems to get everything right, EXCEPT the character that was mapped to nbspace (00A0).

Unfortunately, until everything is Unicode compatible, I have to find a solution.

OK, I've made some headway on this.

Two things that helped:

1. I went back to an old postscript Type 1 version of the font issued with GreekKeys, "Athenian" (circa 1991) and saved the encoding, which I then used for the new remapped fonts.

2. Following John Hudson's advice, I changed the Microsoft Character Set in Font Info (under Encoding and Unicode) to "Bitstream Font Set," to enforce the encoding.


This was sufficient to get rid of the problem with iota acute and the Euro symbol swap. (In the old encoding, iota acute is in the "currency" slot.)

But it did not get rid of the missing omega lenis acute (which occupies the nbspace slot) in certain applications. After extensive testing, here is what I discovered:


A. What is crucial to the GreekKeys keyboard is the *index* number of the glyph. Therefore, you have to have a glyph for every glyph in the Athenian font (all 217 of them), and they have to be in the right order.

To get this, you have to start by appending an empty slot named ".notdef" which has the first index; and then paste each of the glyphs into a new font window, in the order their names appear in the GreekKeys encoding in Names mode.

B. But it also appears that the font can *not* have *more* than 217 glyphs. (When I did, the letters collapsed on each other in both Word X and FrameMaker 7. I still don't understand why this happened.)

So to solve the omega lenis acute problem, you have to replace an existing character, such as the backslash, in Names mode; then switch to Index mode, and drag and drop the appended glyph to the index slot occupied by backslash (59); and then *delete* the backslash glyph, which is not in index slot 60. Then return to Names mode and generated the Mac suitcase.

Anyway, that's what I did. Here are the results:


Everything works fine in BBEdit, Word X, FrameMaker 7, and Endnote 6. The normal omega lenis acute is missing in InDesign and Mellel, but the secondary one substituting for backslash works fine. (Iota acute, as noted, works fine.)

One oddity is that Mellel screws up on two other characters: eta acute iota subscript and eta asper iota subscript. (It swaps them with pi and Omega, respectively, from some symbol font.)

On the other hand, my legacy documents are likely to go straight into InDesign. In Mellel, one can (and should) use a unicode version.

Best, Victor