Windows doesn't use bitmaps embedded in .TTF/.OTF (FontForge)

Lar Gactyl

I'm trying to add embedded bitmaps to my outline (vector) font.  It's essentially a 'pixelfont' that is supposed to have a 1:1 "pixel perfect" representation at a size of 12px (which is 9pt, on my 96dpi monitor).  My intention is to force that particular size to render as bitmaps (no anti-aliasing); all other sizes would show as outlines.

I used FontForge to generate bitmaps for the 12-pixel size, and embed them into the TrueType/OpenType files.  This seems to work correctly - when I reopen the .TTF/.OTF in FontForge, it finds the 12px bitmaps and displays them as intended.  However, when the font is installed in Windows, I only see outlines being rendered - even at 9pt (12px), instead of my bitmaps.   (I've verified this by modifying a few bitmap glyphs to make the difference apparent.)

I'm using Windows 7 with ClearType enabled.  Microsoft says: "ClearType antialiasing is disabled [...] if the font has tuned embedded bitmaps, only for those font sizes that contain the embedded bitmaps."  For some reason, this isn't working for me.

Any ideas why I'm not seeing my bitmaps being rendered? Is there some required property that I might be missing, or some way to debug this?

Thomas Phinney

It's been a lot of years since any Windows rasterizer paid any attention to the embedded bitmaps in a TTF.

I wasn't aware it was even possible to embed bitmaps in an OpenType CFF font. I'm pretty sure nothing renders those.

(This is aside from other SFNT containers that store bitmap fonts, such as some of the recent color font solutions.)

Lar Gactyl

Well, I was led to believe that there's a way to make it work - not just by the above-mentioned MS article; I also came across a recent question on StackOverflow, where the discussion suggests that recent Windows rasterizers do render embedded bitmaps (in fact, the poster has the opposite problem, since he's trying to prevent that).

I'm just not sure what the conditions are to make it happen; I'm trying to avoid having to split my font into separate versions (bitmap and outline).  Of course, this whole headache could've been averted if Windows supported a true unicode bitmap font format (such as BDF).

Aaron Bell

Actually, Windows ships several fonts that contain bitmap data. The legacy East Asian fonts, in particular, are places where you can see them still shipped and often times still in use. 

So, assuming that Windows still renders bitmap data, it sounds like your bitmap tables themselves are not really functioning correctly. Maybe look in here?

http://www.microsoft.com/typography/otspec150/otff.htm#otttables

Rob tell me that you also need to set the GASP table correctly:

"Embedded bitmaps only show up if the gasp table has asymmetric rendering on for the desired size. (Change was made in 8.1)"

Lar Gactyl

(I know it's been a while, but I only now found the time to continue wrangling with this.)

Thanks for that info, Aaron.  I had a look at those East Asian TrueType fonts you mention: even with ClearType enabled, Windows 7 and 10 both render the contained bitmap strikes -- which confirms that Windows still supports this.

I opened a few of those fonts in FontForge (Batang and MS Gothic, specifically) to see how they pull it off, but somehow I still can't get this to work in my own font:

• The bitmaps for the desired size (12px) exist, and the bitmap data is embedded in the .ttf (EBDT+EBLC tables).
  
• I set the GASP table as per your tip - this is how those East Asian fonts do it, too.  For size 16px and under, I've got 'Grid Fit', 'No Anti-Alias', 'No Symmetric-Smooth', and 'No Grid Fit w/Sym-Smooth'.
  
• I also ran my font through Microsoft's Font Validator.  My bitmap tables (EBDT, EBLC) check out fine, and there are no rasterization errors. [EDIT:] same goes for the newly-updated Font Validator which I just found out about!
  

Windows still refuses to render the bitmap strikes in my font.  Curiously enough, if I recreate a .ttf in FontForge from one of the aforementioned Asian fonts, the bitmaps work as expected.  I'm forced to assume that there's yet another undocumented requirement - I just can't figure out what that might be...

Any other clues would be appreciated!

Mike Duggan

what version of Windows are you testing on? DirectWrite does not support the use of embedded bitmaps in general, but enables them in the specific case of legacy East Asian fonts.

SiDaniels

I wonder if the supported fonts are hard-coded somewhere. I'll ask around.

Lar Gactyl

I've been testing on both Windows 7 and 10 (have an XP machine too, but that wouldn't help me much).

Mike Duggan said:

DirectWrite does not support the use of embedded bitmaps in general, but enables them in the specific case of legacy East Asian fonts.

That would be unfortunate... though not entirely unexpected.  I haven't been able to find any official info regarding that -- is this documented anywhere?

At any rate: if true, I suppose the question would be what causes DirectWrite to identify a TrueType font as a 'legacy East Asian font', for rendering purposes.  If there's some property I can set without breaking anything else, just to get the bitmaps, I'd happily do that.

SiDaniels said:

I wonder if the supported fonts are hard-coded somewhere. I'll ask around. Si

Thanks.  For what it's worth, when I changed an East Asian font's name in FontForge and exported my own .ttf, the bitmaps still worked; so if there's some hard-coding at work, it's probably not by name.

Thomas Phinney

I'm thinking it might be dependent on either (1) codepoints, or more likely (2) the codepages or Unicode ranges supported by the font.

I'll be curious to hear the report back from Si and Mike. I was pretty sure we couldn't make bitmaps work in arbitrary new fonts on Windows, so any way to make it happen would be interesting news to me.

Dave Crossland

Try comparing the fonts with behdad's fonttools' ttx and meld. On Unix this would be 

mkdir a;
cp yourfont.ttf a/a.ttf;
mkdir b;
cp msfont.ttf b/a.ttf;
ttx -s */a.ttf;
meld a b;

Sami Artur Mandelbaum

You also can use DTL Otmaster 3.7 light (free version).
http://www.dutchtypelibrary.nl/FontMaster_rdrct.html
Open the 2 fonts and use the table comparator (tools -> table comparator)

Lar Gactyl

Well well... I just stumbled across this post, which pointed me towards the solution: http://www.electronicdissonance.com/2010/01/raster-fonts-in-visual-studio-2010.html

Apparently, for modern versions of Windows to display the embedded bitmaps, (1) the "MS Codepages" OS/2 table has to specify at least one East Asian codepage -- that post recommends Traditional Chinese, but 'JIS/Japan' also worked when I tried it; and (2) a few seemingly-random glyphs in the Hiragana range have to actually exist(!).

The first requirement is a bit unfortunate, because it seems to make Windows ignore certain other codepages, even when they're explicitly specified alongside the East Asian one(s).  Which makes it less than ideal for my purpose, but hey, at least it works and we've solved the mystery.

LeMo aka PatternMan aka Frank E Blokland

Just for the record: with OTM embedded bitmaps can be generated, viewed, and edited. One can select the Embedded Bitmap Viewer from the ‘Tools’ menu and this makes viewing and simple editing of the bitmaps possible. In case there are no embedded bitmaps yet, the ‘New Strike…’ option can be used to generate these at preferred sizes, which will include the ‘EBDT’ and the ‘EBLC’ tables.

jackhumbert

Has anyone been able to use these bitmap-embedded fonts via `@font-face` in css? I've found that loading them from the web doesn't display the bitmaps, but if they're installed on the system and referenced (event via `local('font-name')`), they display correctly.

Khaled Hosny

Most likely OTS in Firefox and Chrome is dropping the bitmap tables, you should get something about this in the browser console.

jackhumbert

I'm not seeing anything in the console - do you know how I might trigger that? I've gotten errors in the console before related to opentype table errors. I have a display page is here: https://jackhumbert.github.io/dreluhu/bitmaps.html - it loads the font from the web on the left, and the system font "Dreluhu Future" on the right. The font can be downloded here: https://github.com/jackhumbert/dreluhu/blob/master/future.otf

Khaled Hosny

My mistake. OTS silently drops the tables it does not support, so you want see anything in the console in this case.

jackhumbert

Ah ok - it looks like you added the ability to pass-though the color bitmap tables back in 2014. Would it be desirable to pass-through the EBDT/EBLC tables in the same way the CBDT/CBLC ones are currently? I can move to Github if this is a better conversation to have there.

Khaled Hosny

It is possible to pass through any non-required table, but OTS clients need to do that as the library does not pass through any table by default (so you basically need to convince Chrome and Firefox to do this).

The color tables stuff you refer to is in the test utilities and does not affect the users of the library.