fi fl OR f_i f_l - which is right?

There's a difference between glyph names and encodings. Few if any applications rely on glyph names for these sorts of purposes, so there's not really any backwards compatibility issue there.

As you say, in an expert set, the /fl glyph is encoded in the slot typically used for "V" (or is it "W" perhaps?).

I'd be curious to hear the results of the test on QuarkXPress, but otherwise this is not a big deal.

One small point to clarify: the Unicode character names, although they are long strings, are really quite set character names, despite what I might have suggested previously. In fact, even if the "correct" description of the character is discovered to be different, the Unicode character name isn't allowed to change.

Regards,

T

Dear Thomas,

Thanks to you (and Adam) for the very precise and useful information. But, even if expert set character names are pretty old, wouldn't it be useful to keep them in OT fonts for backward-compatibility reasons. Imagine you have, for instance, an old Word file containing a Type 1 font and its expert set, plus maybe an extra SC/OsF variant (or a titling font). You want to replace this by a new OTF version and, maybe, on the same occasion, import it to a serious DTP app like InDesign. If /fl stays /fl, things might be easier. On the other hand, maybe I'm wrong, as /fl is "V" (?) in the expert font. Just getting a bit confused, I must admit...

Cheers,

Christoph

Unicode does not specify names for glyphs (although it does for characters, these are long names with spaces in them, and don't work as glyph names even when there is a one-to-one correspondence).

Expert sets pre-dated a lot of current thinking about glyph names. The best all-in-one-place explanation, with useful links, is here:


(Thanks to Adam for posting a great summary and links on the FontLab site.)

T

Dear Thomas,

Can you explain me the reason for the switch from /ft to /f_t, etc.? In expert sets, it used to be fl, fi, ff and all that. Are the new names the official Unicode standard (same question for A.sc instead of asmall, for example or the changes in oldstyle numbers' names there again I understand, as there is now a distinction between tabular and proportional)? Or are there other reasons, internal to Adobe? Maybe I should just check the most recent Unicode tables, but a quick answer from you might be easier for me ;-).

Regards,

Christoph

QuarkXPress probably relies on the MacRoman encoding mapping, not the glyph name. If so, it wouldn't matter what the glyphs are named (nor what their Unicode encoding is).

I would be curious if anybody has tested this. Our own internal testers should check it out to be sure....

T