FF4 anti-aliases bitmap font, while Chrome presents it correctly
Hi, I use the @font-face declaration to provide inline base64-encoded fonts on a Blogger site. One font in particular is a bitmap style font that is meant to remain aliased. Chrome 9 & 10 present it correctly, while FF4 does not.
A visual example of the difference can be seen at http://imgur.com/7Kbc0. The site itself is at www.almostblue.org.
Do you have any idea how I might get FF4 to stop antialiasing that one font (Mazinga8it)?
My CSS for the font right now is:
@font-face { font-family: 'Mazinga8it'; src: url('http://lucite.org/almostblue/css/Mazinga8it/Mazinga8it.eot'); src: local('☺'), url(data:font/truetype;charset=utf-8;base64, [base64 encoded data goes here] format('truetype'), url('Mazinga8it.svg#almostblue') format('svg'); font-weight: normal; font-style: normal; }
This is from the file 'http://lucite.org/almostblue/css/Mazinga8it.css
If necessary, I can generate different font file types or edit the font or its properties. Or, I may just need to tweak the CSS a bit. I'm not sure why, but Chrome renders it correctly.
Thanks & please let me know if I can provide further info.
Upravil uživatel VanHeflin dne
Všechny odpovědi (3)
Conjecture... It may be that Firefox 4's implementation of font-smoothing ignores a TrueType or OpenType font's "GASP" table (Grid-fitting And Scan-conversion Procedure), while Chrome attends to it. This is part of a font's properties: http://www.microsoft.com/typography/otspec/gasp.htm
GASP tables are apparently part of a font's hinting and have entries for various PPM ranges (Pixels Per eM) and whether they should have smoothing applied (S), instructions applied (G), both (SG), or none.
As generated, the example font (an 8-pixel bitmap font) has these settings: 0-8 PPM: S, 9-16 PPM: G, 17-... PPM: SG. I would have intuitively expected 0-8 to have nothing there for this font. I will try an experiment where I regenerate the TTF with an altered GASP table, and convert it into the new filetypes for @font-face, as well as the base64 stream. We'll see if that does anything.
(If anyone out there actually knows something about this stuff, please chime in.)
Elsewhere, I have read that Cleartype automatically anti-aliases everything it gets, sort of a shotgun approach. Firefox uses Cleartype, right? Anyway, it is mysterious how Chrome/Webkit is getting it right. Incidentally, IE9 also anti-aliases the example font.
Upravil uživatel VanHeflin dne
It's not the font properties, after all.
I edited the GASP table of the font to remove smoothing and hinting, and re-encoded it without adding automatic hinting or changing font metrics. The result is the same. Chrome correctly displays it, while FF4 and IE9 still apply font-smoothing.
Stuff I've tried on a demo page:
- In FF4, the font displays correctly on its own on an HTML demo page.
- In FF4, the font displays correctly on its own on an HTML demo page with a transparent PNG background.
Stuff I've tried in context:
- Removing the CSS background color "transparent" from everything doesn't fix it.
- Removing CSS3 shadows doesn't fix it.
- Removing border radii doesn't fix it.
- Referring to it singly (instead of in a font stack) in the CSS doesn't fix it.
- Removing percent-wise style declarations didn't fix it.
- Inspecting the element in Firebug and individually toggling style rules did not reveal any problem.
- If I click and drag one of the styled tab buttons, as though to drag it to the bookmarks, then the ghosted image appears correctly styled. This suggests that it is not likely to be a problem with the CSS.
Here is an example image where a button is ghosted by dragging. The ghosted button is styled as expected, while the regular one is blurry: http://imgur.com/hFkd7
(Image attachments are scaled down by support.mozilla.com--even after enlarging from thumbnail. Please view images at full size to see difference in font-smoothing. Enlarge the image, right-click and choose "View Image" from the context menu. Or view them at imgur.com.)
Upravil uživatel VanHeflin dne
Does the Direct2d/DirectWrite implementation in Firefox 4 disregard a font's inherent smoothing and hinting instructions?
Stuff I have tried re: hardware acceleration:
- Disabling hardware acceleration in FF 4 removes anti-aliasing from all fonts indiscriminately.
- Enabling/disabling hardware acceleration for Chrome 10 yields no perceptible difference: text still appears correctly.
- Disabling hardware acceleration in Internet Explorer 9 yields no perceptible difference, but font is still blurry.
Upravil uživatel VanHeflin dne