TTF with embedded bitmaps

Mark Simonson's picture

(I've posted a question about this on the FontLab forum, but haven't gotten a response after several days, so I'm trying here.)

I'm building a new version of one of my old fonts, Anonymous. It's a TTF fixed-width font (meant for programmers) and I'd like to include bitmaps for certain PPMs (10, 11, 12, 13). I created the bitmaps with BitFonter and successfully imported them into the FontLab file.

The generated font works great in most OS X apps I've tested (including Terminal, Coda, TextEdit, PhotoShop CS4, Illustrator CS4, Mail) using whatever method is available to disable anti-aliasing. (In some apps, such as Quark 8, it's not possible to disable anti-aliasing, but the font still works.) It also seems to work fine in Windows (XP) in the limited testing I've done there. The font validates in Apple Font Book. I got some errors in MS Font Validator, but I was able to eliminate them.

Nevertheless, this font causes BBEdit, one of the most popular Mac programmers' text editors, to crash, whether antialiasing is enabled or not. The only way the font can be used without crashing BBEdit is to generate it without the bitmaps. I've also found one app, TexEdit, a simple shareware text editor, will not display the font at any of the sizes that have bitmaps--the characters become invisible at those sizes. The app doesn't crash, though. There may be other apps that are affected, but these are the only two I've found so far.

In the old version of the font, which I built years ago with Fontographer, I was only able to include the bitmaps in the Mac version (as a font suitcase). This version works flawlessly with BBEdit, so it's not that BBEdit can't display embedded bitmap fonts at all. Thinking it might be something to do with Mac vs. PC TTF, I tried generating a Mac suitcase-based TrueType file from FontLab, but this, too, causes BBEdit to crash. I tried importing the new version of the font into Fontographer (OS X version) and generated a Mac suitcase-based TrueType font. This doesn't cause BBEdit to crash, but Fontographer would only include the first 256 bitmap characters. I also tried limiting the number of bitmap characters in FontLab, but this still caused BBEdit to crash.

I've been unable to find much information about embedding bitmaps in TTF files (the FontLab manual has very little to say about it). I have assumed that I'm doing something wrong, but I've spent several days trying different things with no success. Has anyone else successfully built TTFs with embedded bitmaps using FontLab? Could this be a FontLab bug? If it's a bug in BBEdit, why would it work if the font is generated by Fontographer, but not if it's generated by FontLab? Any advice or information is welcome.

(I realize I could manually hint the font, optimized for the PPMs in question, using my bitmaps as a guide, but it would be much simpler and faster if I could get the bitmap embedding to work, as I already have all the bitmaps created. The new version of the font has over 600 glyphs x 2 weights x 4 PPMs, so doing manual hinting would add a huge amount of extra work to the project.)

Mark Simonson's picture

Ah ha! I think this might be a bug in FontLab.

When I opened the font in BitFonter, I noticed something weird:

Note how all the metrics values are "0". I didn't think this was necessarily a problem when I first notice this. After all, I put the bitmaps into the font and FontLab should know what to do with them. If it puts in zeros, then it must be okay.

Today, I was looking at the crash reports from BBEdit and they were always the same: a "divide by zero" error, apparently (judging from the function calls in the crash report) when it was calculating the dimensions of the text. This made me suspicious of those zeros.

Just as a test, I opened the TTF in BitFonter and filled in the correct metrics data, and then saved the font (from BitFonter) as a TTF. Bingo: BBEdit does not crash anymore and the font displays the embedded bitmaps as expected.

I would deduce from this that the bitmap metrics data isn't always required by apps, but when it is missing can cause problems in some cases. Since this data is sometimes required, I would count it as a bug FontLab.

(My workaround has led to one bad side effect: When anti-aliasing is disabled, sizes that don't have embedded bitmaps have erratic spacing. I think I can probably fix it, though.)

hrant's picture

Mark, thanks for sharing this.

In terms of assigning blame, it usually takes two to tango. Yes FontLab* might be doing something wrong, but BBEdit's crashing is only its own fault; for one thing other programs apparently handled FontLab's output just fine. Although you've nicely resolved this, it's probably worth pointing both the FontLab and BBEdit folks to this thread.

* In fact as I was reading your first post I was thinking "use BitFonter, not FontLab, for the final font file generation".


BTW, could you do me a huge favor and see if you have success with grayscale bitmaps? Only if you have the time. I was a BitFonter beta tester ages ago, but I've held off getting the release version because the beta didn't embed grayscales properly and I never got a fully comforting answer about the release version managing it.


Mark Simonson's picture

I think the problem may be with Carbon apps on OS X. Carbon allows developers to use the pre-OS X APIs so they wouldn’t need to rewrite their apps from scratch to get them to work on OS X. These are less common now, but they still are around. If it is a Carbon problem, it’s not likely to get fixed since Apple has stopped development on it. Mac OS X still supports Carbon, but it’s essentially frozen.

Mac OS 9 and earlier did not support the .ttf (Windows TrueType) format. To embed bitmaps in a Mac TT (sfnt) font, you just needed to make NFNT font resources with the appropriate name and resource data, and bundle them into the same suitcase file with the sfnt. The bitmaps are separate and associated with the sfnt, but not embedded tables in the sfnt. NFNT bitmaps include their own metrics data. Apparently, this data is not required for .ttf fonts with embedded bitmaps, perhaps because the necessary data already exists elsewhere in the TT tables.

Yet, if I generate a Mac font suitcase from the same FontLab file, the metrics data is also missing (actually, not missing, but zeroed out). This cannot possibly be right, and would explain the behavior of certain apps which appear to expect it to be there. And, predictably, it crashes BBEdit. It may well be that Carbon should be synthesizing the bitmap metrics data if it’s missing for Carbon apps that need it, and that seems to be the likely culprit with regard to .ttf fonts with embedded bitmaps. But FontLab should also be including this data when it generates a Mac suitcase-based TT font, but it’s not. Adding the appropriate bitmap metrics to the .ttf appears to fix the problem without breaking anything else. I’m still testing, but so far, so good.

Incidentally, I managed to fix the spacing problem I mentioned at the end of my previous post. Not sure how exactly because I was changing too many variables simultaneously, but I now have a repeatable recipe that (seems to) work.

I haven't tried embedding grayscale fonts with BitFonter, so I don't know if that works or not.

(This message and my previous one have been cross-posted to the FontLab forum.)

Mark Simonson's picture

Incidentally, Hrant, the regarding "use BitFonter, not FontLab, for the final font file generation", BitFonter (as far as I know) does not touch any of the non-bitmap-related TT tables, just the bitmap-related ones. Most of the tables are built by FontLab, and BitFonter is only modifying the bitmap-related ones when I add the metrics data (as far as I can tell).

Also, I tried embedding the bitmaps using BitFonter, but I couldn't get that to work at all. Maybe I was doing it wrong.

Thomas Phinney's picture


Carbon apps may be "less common," but they include a lot of major apps people care about. Microsoft Office. Adobe Creative Suite. etcetera.



Mark Simonson's picture

Exactly. Which is why I was concerned. Although, CS apps seem not to be affected. In fact, one of the apps that is affected by the missing metrics data is MS Word (Mac). It doesn't crash, but the text disappears.

Syndicate content Syndicate content