為了改善您的使用體驗,本網站正在進行維護,部分功能暫時無法使用。若本站的文件無法解決您的問題,想要向社群發問的話,請到 Twitter 上的 @FirefoxSupport 或 Reddit 上的 /r/firefox 發問,我們的社群成員將很快會回覆您的疑問。

搜尋 Mozilla 技術支援網站

防止技術支援詐騙。我們絕對不會要求您撥打電話或發送簡訊,或是提供個人資訊。請用「回報濫用」功能回報可疑的行為。

了解更多

FF4 anti-aliases bitmap font, while Chrome presents it correctly

  • 3 回覆
  • 21 有這個問題
  • 5 次檢視
  • 最近回覆由 VanHeflin

more options

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.

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.

由 VanHeflin 於 修改

所有回覆 (3)

more options

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.

由 VanHeflin 於 修改

more options

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.)

由 VanHeflin 於 修改

more options

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.

由 VanHeflin 於 修改