I recall there was some trouble with Eras a few years ago—an application didn’t recognize a font name only four letters long.

It works fine; it just shows up under the C's instead of the N's in the font menu. I suppose if I took the space out in the name that would force it to be under the N's, but then it would list as NewCuisine. If it's something to do with the word New preceding it then by logic the same thing would happen with fonts starting with Old like Old English. I don't have Old English so I grabbed a font called Old Press (a freebie) just to see if that came up under P instead. It didn't.

I remember other fonts doing this when I worked at American Greetings. I thought it had something to do with the font manager, but I'm not certain now. I'm using the old free version of Font Explorer on my Mac. I recently updated the system software to Snow Leopard, but I don't think that's a problem.

Stephen,

Your Old-New logic only works if omitting the New is logical, which clearly it ain't.

If you're set on the name AND a space between the two words, it looks like you're going to have to spell New another way, like Neu, Nieu, Noo or Nevv. Or not.

I think you're right. I'm not that married to the name yet anyway. Thanks.

Fascinating. I get this exact same result on Windows, InDesign CS4, with a freshly created font.

    Macintosh Roman (English)          Font family : (1) "New Cuisine"
    Macintosh Roman (English)            Subfamily : (2) "Regular"
    Macintosh Roman (English)            Full name : (4) "New Cuisine"
    Macintosh Roman (English)      PostScript name : (6) "NewCuisine-Regular"

I also tried it as a Preferred Family name, but that didn't work either!

I'll have to take a closer look at this. InDesign has a habit of ignoring 'font name prefixes' (and a nasty habit it is, as I feel it's actually inconvenient for browsing through your font list), but so far that only seemed to include foundry names such as Adobe, ITC, and Linotype. There isn't a foundry called "New", is there?

So do German users of InDesign have to search for Neue Haas Grotesk amid the H fonts?

Presumably, this behaviour had fonts like “New Century Schoolbook”, “New Aster”, “New Baskerville”, etc. in mind; However, it seems strange that this would be implemented as a general behaviour (rather than one for specific fonts in the Adobe library) since clearly there are many cases where it is entirely undersirable (New Century Schoolbook appearing alongside Century makes sense; New York appearing alongside York doesn’t).

Unlike Theunis, I actually prefer foundry abbreviations to be ignored for sorting purposes, and have on occasion wished that the OT spec included a separate name field for “Sorting Family Name”. Applications could even include a preference for sorting fonts by either the family name or the sorting name.

André

>wished that the OT spec included a separate name field for “Sorting Family Name”.

Isn't there that possibility in the name table? In FontLab's font info dialogue, there's the 'Additional OpenType Names' which allow you to fiddle the detailed settings, and I seem to recall these may be useful in font menu ordering?

In the displayed font names, there is no entry for 'Menu Name'. Might that solve the problem?

The specs for "Menu Name" (NameID 18):

Compatible Full (Macintosh only); On the Macintosh, the menu name is constructed using the FOND resource. This usually matches the Full Name. If you want the name of the font to appear differently than the Full Name, you can insert the Compatible Full Name in ID 18.

There is nothing in there related to this name mangling.

I didn't test what happens when you use a different Menu Name ('cause I'm on Windows right now), but it's a reasonable assumption that even if you insert a 'different' name here – and InDesign actually uses this –, the result still goes through the "smart sorting" routine.

Yes, InDesign is using its own sorting method, so it won't matter which name field it's getting the name from.

On reflection, I'm starting to rethink my desire for a 'sorting name' field since, unless different vendors adopted very similar conventions, this would probably cause as much problems as it would solve. I have my own personal preferences, but I doubt they match those of others.

André

unless different vendors adopted very similar conventions, this would probably cause as much problems as it would solve

An interesting discussion on the topic: http://typophile.com/node/88327