The mac stores fonts in resources. It use to store resources in resource forks (which have no representation on unix) but now (Mac OS/X) it also stores them in data forks.
Apple (and Adobe) provide some documentation on the mac's formats:
I have not yet found a description of a data fork resource file. I have determined empirically that they look almost the same as resource fork resource files except that the map table begins with 16 bytes of zeros rather than a copy of the first 16 bytes of the file. To date I have only seen sfnt (and FOND) resources in a data fork resource file (often called a .dfont file).
FontForge does not support the old 'fbit' font format for CJK encodings (but then neither does the Mac any more so that's probably not an issue).
When an 'sfnt' resource contains a font with a multibyte encoding (CJK or unicode) then the 'FOND' does not have entries for all the characters. The 'sfnt' will (always?) have a MacRoman encoding as well as the multibyte encoding and the 'FOND' will contain information on just that subset of the font. (I have determined this empirically, I have seen no documentation on the subject)
Currently bitmap fonts for multibyte encodings are stored inside an sfnt (truetype) resource in the 'bloc' and 'bdat' tables. When this happens there are a series of dummy 'NFNT' resources in the resource file, one for each strike. Each resource is 26 bytes long (which means they contain the FontRec structure but no data tables) and are flagged by having rowWords set to 0. (I have determined this empirically, I have seen no documentation on the subject)
When a 'sfnt' resource contains only bitmaps (and no glyph outlines) it is sometimes called an 'sbit'.
The unix filename for the resource fork of the file "foo" is "foo/rsrc". (I was told this and it appears to be correct, I have seen no documentation on the subject)