There was a discussion about this recently over on the FontLab forum. Adding "Greek" to the supported code pages and unicode ranges fixes it for some mysterious reason, even if you don't have a full Greek character set. I tried it on a set of fonts I'm working on and it works.

hmmm... just tried that and it still didn't work. i can't figger this out! i musta really screwed it up.

Make sure you quit all the Adobe CS applications, clear out your font caches, etc. (assuming you are on OS X). I've also found that it helps to start up the Adobe apps without the font(s) installed before attempting to install them again.

I'm not able to make this work, font cache dumps and all.

I'm stumped then.

One thing I noticed before I tried this was that my fonts were showing up in FontBook with all sorts of accents sprouting out of the characters in the basic A-Z, a-z, 0-9 font showing. When I got it working with CS apps, the accents disappeared. This makes me think this is an OS X problem, not an Adobe CS problem.

Hasn't this dilemma come up here before?

The answer is often both.

OS X has had various font related bugs. One was associated with how it maps glyphs to characters for fonts with extended language support in apps that are not doing Unicode. Sometimes weird stuff would show up in what ought to have been the regular MacRoman range. I believe this was fixed in 10.3.6 IIRC.

OS X and InDesign both have a notion of being able to identify the primary codepage of a font. This is an obviously questionable idea in today's universe of multi-lingual fonts, but they try to do it. InDesign uses this info to group fonts in its font menus, so all the Cyrillic fonts will be in one group below the western fonts, and so on.

First, in addition to the obvious problems with the idea itself, there have been errors in the heuristics used by both OS X and InDesign to do this. InDesign has fixed some of its errors, but if the font is installed at the OS level, InD will simply query the OS for info.

Adobe recognizes that there is a real problem here, and hopes to significantly improve this area in the future. However, I can't comment specifically on features and bug fixes for unannounced future products.

Even if it solved the problem, I wouldn't recommend labeling your fonts as supporting codepages they do not in fact support. That sort of thing is bound to get you into trouble.

If within a given family, some fonts are sorting differently than others, I would check your settings for supported codepages and make sure they are consistent for all fonts in the family. After that, I'd try cleaning both the OS X font cache and the Adobe font cache files. Also see if the behavior is the same if the font is installed in a private Adobe fonts location rather than in the Mac OS.

Regards,

T

I guess I should have said this at the beginning:

I'm running Windows XP and generating TTFs. I don't know if this makes any difference... i'm sure it does somehow...

curiouser and curiouser...
i just put the fonts in the C: >ProgramFiles >Common Files >Adobe >Fonts folder and the fonts show up just fine in the font listing. then installing the exact same fonts in Windows will split up the Regular and the Italic with the Italic showing up marked as Cyrillic. So apparently it's an OS thing... whether Mac or Win (???) It's still really annoying tho.
So is the best thing to do to recommend different installation proceedures depending on whether the user plans on using these fonts with Adobe or Microsoft apps? If so, that's kinda funny...

Thomas, thanks for all the info. I thought lying about Greek support sounded a little dubious, even though it seems to work.

One question: Where are the Adobe font cache files located? Knowing where they are so I can delete them would probably be more reliable than my method described above of quitting and launching with the fonts not installed (which I assume does something similar but don't really know for sure).

Mark - I think some caches are in user > Library > Application Support > Adobe > Fonts
and the folder at the same path for root has some sort of cache file.

The fact that you're on Windows simplifies things. Don't have to worry about FOND IDs or the system font cache.

Adobe font caches can be all over. Often (but apparently not always) in the same location as the fonts. The "adobefnt*.lst" files are the caches, where "*" is usually a two-digit number.

Quitting and relaunching with the fonts not installed does indeed do the same thing.

As long as you've made sure that the fonts are okay, it may be best to do nothing and let the OS makers and Adobe sort out the problem.

That being said, in this particular case, if you get fonts in the same family being separated into different sections of the font menu, it's best to sort that out. With any luck it will turn out to be a caching problem.

T

Paul, there is a file AdbW1Fnt07.lst where every installed font has its own entry. Every font also has following line:

WritingScript:Roman

Instead of Roman could be Cyrillic etc.

Unfortunately, when you regenerate font file (with correct Script) and install the new one, the entry in this database file will remain wrong (in your case Cyrillic).

Before you install newly generated fonts, delete particular entries in the AdbW1Fnt07.lst file - the structure of the file is very easy.

Thomas -

Are there plans to display fonts alphabetically regardless of
language support for Adobe apps?

(Since offering an extended latin typeface last fall I've been receiving
complaints from customers about the bottom menu placement)

Okay.

So this is a problem that Apple and/or Adobe will fix eventually, so mucking around with adding unsupported codepages (even though it seems to work, at least in some cases) should be avoided.

In the mean time, I tried a bunch of stuff this morning trying to change things in the fonts, clearing caches, restarting, voodoo, standing on my head while crossing my fingers, etc. with no success.

Out of desperation, I waded through the message boards at the FontLab Forums (why in hell there is no way to search them is beyond me, and half the time Safari tries to download the .msnw pages instead of displaying them, arrgh!), and lo and behold, I found a work-around devised by John Butler that appears to be reliable and doesn't involve doing anything dodgy to the fonts themselves.

Here it is:

In addition to installing the problematic OTF font in the usual way (I use FontBook), put a copy in [your hard drive name here]/Library/Application Support/Adobe/Fonts/ .

This is actually slightly modified from John's version. He says to put them in a folder for a specific Adobe application, but this one is used by all of them (presumably) and seems more logical.

The way it seems to work is that Adobe apps look in Adobe's font directories first, correctly identify the main script supported and place it in the correct section of the font menu. The other copy installed in the system font directory is ignored, but makes the font available to non-Adobe apps.

I don't know if a similar procedure would work with Windows. I don't have Windows copies of Adobe apps to test.

This general idea was touched on above when Thomas mentioned moving fonts to Adobe's private font locations for testing purposes, but that hides the fonts from other apps. The key thing that makes this work is putting copies of problem fonts in both Adobe and system locations.

So far, I haven't found any problems with this work-around, and it seems like it would be a simple enough procedure to explain to customers, not that this sort of thing should be necessary in the first place.

I remember this but was too scared to trudge through the
FontLab message board and find it. It's too bad because
there is some great stuff buried in there.

Anyway, yeah, this is why the Adobe fonts that ship with CS
apps show up alphabetically.

So, have you tried this? Does it work for you?

(I'm sitting here half expecting this not to work for other people. Call me superstitious.)

Thank you, Mark! The fonts show up where the should and group perfectly when using this method (placing the fonts in the C: >ProgramFiles >Common Files >Adobe >Fonts folder and installing them in the Windows >Fonts folder).
I knew i didn't stick anything screwy in the font information fields, but somewhere between Windows and Adobe apps, certain fonts get labeled as Cyrillic (when simply installing to the Windows >Fonts folder) This still seems very bizarre to me , especially since last night I took out any characters that were not in the Mac Roman charset and still had the same problems (Maybe i shoulda used the WinANSI charset).
Anyhow, this seems to work (on Windows as well as Mac). I guess it's the best possible solution until Adobe and Microsoft sort things out.

Mark

Yes I've done this but I've never suggested it to customers as
most people are pretty tied to font managment software.

Speaking of which... MasterJuggler has eased most of my font cache pain.
(but not the above mentioned problem as it's a little more complex...)

Actually, I found a fly in this lovely ointment: The system treats the fonts as CE fonts and pushes them down to near the bottom of font menus (except in Adobe apps because of the work-around). Some Carbon apps don't display them correctly at all, showing Geneva instead, or completely absent from the font menu in the case of Quark 6.

I notice if I remove one of Adobe's Pro OTF fonts from the Adobe font folder and install it using FontBook, it still shows up correctly in InDesign anyway. What is Adobe doing differently when it creates OTF CFF fonts that makes them work correctly? I'm beginning to suspect FontLab as the culprit here. There's got to be some way to make these work properly.

So, any work in pig farming these days?

Would using the Adobe FDK rather than FontLab make any difference?

I'm still screwing around with this...

If I remove all codepages except 1252 Latin 1, it still shows up as a CE font with all the same font menu and access problems. If I add "1253 Greek", it works perfectly. WHY??? There has got to be some reason this works that should point to the solution. After all there are plenty of working fonts on my system with extended character sets. Why can't FontLab generate an extended character set OT font that works without resorting to hacks???

Sorry, I'm a little upset and frustrated about this.

Mark,

> Why can't FontLab generate an extended
> character set OT font that works without
> resorting to hacks???

This reads as if you were suggesting that the situation is somewhat FontLab's fault. As Thomas Phinney explained above, it isn't. This problem occurs with some (but not all) multilingual OpenType fonts created by Adobe using their FDK for OpenType.

But altogther, it's really not an issue of the applications that create the fonts. The fonts are fine and conform to the specifications. Currently, it's a problem of systems and applications that use the fonts.

I sincerely hope that both Apple and Adobe fix this behavior. I strongly recommend that every developer whose fonts are affected by this bug makes an archive with a documented case (detailed description, sample fonts, screenshots), puts that archive somewhere on your website (not publicly linked) and then writes and submits a bug report on that to Adobe and Apple. Your bug report should include a detailed description of the problem and a link to the archive containing the attachments.

Please use the bug report forms:
http://www.adobe.com/misc/bugreport.html
http://developer.apple.com/bugreporter/bugrptform.html

If you wish, you can also submit a copy of the bug report to us (adam at fontlab dot com). We have already documented some cases and filed a report, but from my experience I can say, the more problem reports and complaints the better.

Regards,
Adam

In this case, there really isn't a need to report a new bug to Adobe. I have done so myself, using third-party complaints, and overseen the whole process.

I wish I could talk more about it, but we aren't supposed to discuss bug fixes for unannounced future applications, so you'll just have to wait and see how things look.

Regards,

T

BTW, the reason many Adobe multilingual OpenType fonts do not exhibit this buggy behavior is... that there used to be (I'm not sure if there still is) a mis-behavior (sort of "buglet") of the Adobe FDK for OpenType that automatically turned on the flag indicating support for the Greek codepage even if just the Omega and the mu characters were included.

As we know, these characters are included in most Western and also Western+CE fonts because they're in the MacOS Roman codepage. According to the spec and general reason, a flag indicating support for a given codepage in a font should only be set if the font includes all or, at least, most characters of that codepage. But indeed, the Adobe FDK for OpenType logic that controlled the codepage support flags used to be *very liberal*.

Therefore, a large majority of Adobe OpenType fonts -- even those that only contain Omega and mu -- indicate the support of the Greek codepage. This leads to various problems in applications such as Microsoft Word, Internet Explorer, Firefox etc. For example, under certain circumstances, Internet Explorer may pick one of these fonts as the basic text font for Greek even if the font only contains these two Greek glyphs.
Since FontLab 4 uses the Adobe FDK for OpenType (AFDKO) code to produce OpenType fonts, in the 4.0 and (I believe) 4.5 versions, FontLab behaved similarly. When an OpenType PS (.otf) font was produced, FontLab 4.0 and 4.5 ignored the Supported Codepages settings in the Font Info dialog and used the very "liberal" logic of the AFDKO code to generate the flags.

A side-effect of this mis-behavior was that, indeed, the presence of the Greek flag prohibited most of AFDKO- or FontLab-made OpenType PS fonts from being listed in the non-Western part of the font list in Apple and Adobe applications.

So the bug in the Adobe applications e.g. InDesign, and in Mac OS X was initially overlooked due to a bug in the AFDKO code that was used by Adobe to produce their OpenType fonts, and is also used by FontLab.

As I explained above, FontLab 4.0 and 4.5 ignored the Supported Codepage settings in Font Info when making OpenType PS fonts and used the AFDKO auto-logic. Since the stand-alone AFDKO version does not have explicit means to set the codepage flags, the use of the auto-logic in the stand-alone AFDKO did make sense (although the problem of course was that the logic was flawed.) But since FontLab has the Supported Codepage dialog to set these fields explicitly, the product should use them rather than always use the AFDKO logic. So with FontLab 4.6, we stopped using the AFDKO logic and started using the Font Info settings (that were always used in OpenType TT fonts, BTW).

At that moment, the Apple/Adobe problem with listing the OpenType PS fonts in the non-Western section manifested itself. So far, it was "covered" by the overzealous AFDKO logic that unvoluntarily set the Greek flag. But of course with FontLab 4.6, the users did not explicitly set the Greek flag, since logically, this does not make sense. But indeed, the fonts without that flag tend to show up in the non-Western section...

Of course setting flags for codepages that are not truly supported in the font is a bad idea. This was a bad idea in AFDKO, it was bad that most Adobe OpenType fonts have this flag set.

So the thing is: a superflous Greek codepage flag makes some applications (Word, IE etc.) think that the font supports full Greek. But this manifests itself only to people using Greek, which is a minority. The absence of the Greek codepage flag makes other applications (InDesign, various OS X apps) put the font into the non-Western section. This clearly affects many more users, namely all Roman script users in West, Central and East Europe, in North America and all around the world.

Setting the Greek flag is a hack. Yet, I believe this is "less worse" than not using it. After Apple and Adobe have fixed their applications, the font developers can update their fonts and remove the superflous Greek flag.

"It's Greek to me" truly gets a new meaning here...

Regards,
Adam

Thank you very much for the explanation, Adam. This really clears up a lot of the mystery surrounding this issue.

I would tend to agree with your prescription of using the hack until the problem is fixed to minimize the affect on users. I suppose an even better solution would be to really add support for Greek. Hmm. Something to ponder.

(Incidentally, I notice that the Adobe OTF Pro fonts installed on my system all seem to have the Greek codepage included, whether or not they have full support for Greek.)

Pondering this a bit more, I think I was right, in a way, to suspect FontLab. If I understand correctly, the problem is the result of FontLab doing the right thing. Unfortunately, doing the right thing exposes some fairly nasty bugs in this case.

Good to know. I wasn't that interested in pig farming anyway.

I don't think using the hack is a good idea. I've been arguing for our changing the FDK code in this area, because I think the FDK behavior is basically a bug. Replicating a bug by hand seems goofy to me.

If I may move this into a broader realm of font dev philosophy for a moment....

I understand that this is frustrating, but this is another one of the frequent cases in font development when we have a choice between doing something the right way, or making a font deliberately defective to deal with a temporary limitation.

Fonts tend to stick around for 5, 10, even 20 years. They're not like other software in that regard. Whatever hacks you put in your released font, you may have to live with for a very long time indeed.

Of course, if it will have limited/controlled distribution, or you have direct access to all the customers, that's a bit different. In such a case you may be able to roll out an upgrade whenever you want and reach all (or almost all) your customers. If you're lucky enough to be in that position, you can better afford to do such things.

Regards,

T

Thomas, I appreciate your reasons for recommending against a hack like this, but I'm tempted to use it because the alternative is that my fonts will be virtually useless to many who might buy them. Telling customers, "well they'll work fine as soon as Apple and Adobe fix the bug so just be patient," I suspect won't cut it.

As I mentioned above, perhaps the right thing to do would be to actually add support for Greek. I'm already covering the rest of Europe, so, what the hey.

It's your typeface, and your call. I was just sharing. Sometimes I over-share, I know.

But why would your fonts be "virtually useless" just because they show up at the bottom of the menu? Or am I missing something?

Side note: Greek caps are easy for us English-speakers, but Greek lowercase can be tough to do well, at least at first.

Cheers,

T

Well, with certain applications, TexEdit (not to be confused with TextEdit) was the one I noticed, the fonts displayed in Geneva. In something else (I can't remember now what--I was trying lots of things very quickly) only some of the fonts in the family were listed in the menu. Granted, some of these problems may have been transient, having something to do with caches or whatever, although I did my best to delete all the caches every time I made the slightest change before reinstalling and testing the fonts again.

I might add that this is a very big family, 21 fonts, and it will double when I get to the italics. That factor may contribute to some of the problems I've been having, but it doesn't seem so.

The thing that's troubling me now is that Quark doesn't recognize the fonts at all, regardless of whether I use the hack or not.

Okay, this is weird. Quark (6.5) recognizes the fonts if I install them manually by dragging them to ~/Library/Fonts/, but not if I used FontBook, unless I quit Quark and restart it.

Never mind.

Well, my head hurts.
I'm able to make "bottom menu" fonts show normally
in text apps like TextEdit and TextWrangler but not Word.

The application I couldn't remember (above) was Excel. I know now why it wasn't displaying all the fonts in the family: Some of the names are too long. 29 characters seems to be the limit. I'm sure I've read about this somewhere before (FontLab manual?). Word has the same problem.

Eric, how do your "bottom menu" fonts appear in Word?

The name thing I remember from the FontLab manual referred to the "Menu Name" which has a 32 character limit, and that's not the problem here (19 is the longest in the fonts I'm working on).

It's either (or both) the "Full Name" or "Mac Name" I think that Word and Excel are choking on.

My "bottom menu" fonts appear at the bottom in Word.
They're fine, just at the bottom.

I'm sure there is a perfectly logical reason for the TextEdit
and TextWrangler menu performance. Likely to do with something
sharing the name of a warm chocolate drink.

>Likely to do with something
sharing the name of a warm chocolate drink.

Cocoa. Yes, I've noticed that too.

I've noticed another oddity with OpenType fonts: In Flash, if you "bold" a font (assuming you've set up R/I/B/BI for a family), it stretches the bold font slightly. The solution is to choose the bold font directly and not use the "bold" style button. This seems to happen with any OT font, not just mine.

running fonts through Adobe’s FileTyper seems to remedy this. Can anyone confirm this?

BTW, now that it’s shipping, I can say that the Adobe CS2 applications all do quite a bit better in this regard.

Regards,

T