you need these in TTF flavored OpenType fonts, but not in CFF flavored ones.

http://www.microsoft.com/typography/otspec/recom.htm
skip to First Four Glyphs in Fonts

Most apps/systems expect to see the missing glyph at id 0. Some also expect the space at id 3. Some things do actually use CR and .null but in many cases they're just filler so that 'space' ends up at id 3 :-) Most apps don't actually use glyph data stored in CR, but I've seen some that do. I guess this is related to the glyph order thread; in this case I would say it's not a bad idea to follow the recommendation that Paul pointed out; though it's not hard to find fonts that don't follow this recommendation and still function just fine.

Paul, or anyone

I read the link, and was surprised to see what was under the "cmap" and "names" section.

I've always assumed that OT fonts work on both Windows and Macintosh platforms, as indeed they seem to do. What's going on?

It's worth keeping in mind that those are *recommendations*, not necessarily requirements. I'm not sure who or what dreamed up the "first four glyphs" thing; I remember that making its way into the spec some years back but I also remember having made and used many fonts that don't meet that recommendation.

The OpenType specification is fairly conservative; there are many things in there that are well out of date now that Windows 3.1, Mac OS 9, and other systems are officially or effectively dead.

It seems like FontForge isn't even able to generate fonts that comply with the first four glyphs recommendation, at least not as far as I've figured it out and I could be missing something. It won't even allow me to set the name of uni0000 to ".null" and the only encoding that puts ".notdef" at glyph position 0 is Adobe Standard.

I find I have the most predictable results when I encode fonts in Unicode BMP order (which violates said recommendation), but am I setting myself up for some kind of trouble I don't know about?

I’ve always assumed that OT fonts work on both Windows and Macintosh platforms, as indeed they seem to do. What’s going on?

Nothing special :-)

Both 'cmap' and 'name' tables have more than a single data entry. To discern between entries, each one is prefixed with salient details. Platform is important because the default character maps differ significantly between Mac and Windows. Additionally, traditionally, Mac char maps were 8 bits -- so for different languages, it had different mappings (entirely similar to ye olde DOS/Windows code pages). So a font just has loads of mappings, each one prepended with a system and a language code.

Names is sort of the same story. What if you have an accented character in a name string -- say, the designer's name? Should you use Mac standard encoding, Windows standard encoding, or Unicode? The canonical solution was: put it all in. Even though the 21st century solution is to use Unicode for everything, Macs historically expect a Macintosh version.

I deliberately say "historically", because I'm pretty much convinced with OSX it's no longer an issue. Those in the know may correct and/or amend to this, but I think both cmaps and names are chosen purely by 'best fit' (transcending encoding and platform), instead of insisting on a Norwegian style name encoded in a Windows Norwegian 8 bit code page for a Norwegian OS.

So, what's going on? "Better safe than sorry" applies--as well as "Standards are good--let's have lots of them". A not-too-bad-coded font may be useable on any modern system (Win XP, Vista, OSX, or one of the more advanced linux desktops), but a font with all bells and whistles in every table is usable on your old Mac SE.

It won’t even allow me to set the name of uni0000 to “.null”

That's a good thing, actually. ".null" is not a legal glyph name (cannot begin with ".", except for ".notdef"). uni0000 is fine...maybe try "null" if you're really bored.

the only encoding that puts “.notdef” at glyph position 0 is Adobe Standard

Are you sure you're looking at glyph order and not character code order when you view the other encodings? That seems really odd that it would not let you put .notdef as glyph 0 for other encodings.

I'm not entirely sure what's happening. The fonts it generates seem to work, though.

But the recommendation does say:


Glyph ID     Glyph name     Unicode value
0            .notdef        undefined
1            .null          U+0000
2            CR             U+000D
3            space          U+0020

So since the glyph name ".null" isn't allowed, why is it in the recommendation?

You'll have to ask someone who maintains the OpenType spec, or the MS Recommendations, about that. I'm just reporting what I know. The Adobe specs for glyphnames make it pretty clear that ".null" is not a legal name: http://www.adobe.com/devnet/opentype/archives/glyphnamelimits.html (see #4, Length and Character Set Limitations on Names).

But again, there are many, many fonts with glyphs named ".null" which work just fine in many different implementations.

cuttlefish

Indeed, FontForge doesn't allow to set the glyph name to ".null". I think this might be a bug. However there is no reason to do that manually, as FontForge just automatically adds the first 3 glyphs (if they are missing) when outputting a TTF font. Of course, one would normally design the .notdef glyph manually and allow FontForge to create other two.

Thus fonts generated with FontForge perfectly comply the recommendation at this point. You can check this by opening a TTF font file you have just generated and switching the encoding to "Glyph Order".

Thanks Alexy. I figured that's what FF must be doing, but I overlooked it in the documentation, if it's mentioned at all.