Join the AMA (Ask Me Anything) with the Firefox leadership team to celebrate Firefox 20th anniversary and discuss Firefox’s future on Mozilla Connect. Mark your calendar on Thursday, November 14, 18:00 - 20:00 UTC!

Sykje yn Support

Mij stipescams. Wy sille jo nea freegje in telefoannûmer te beljen, der in sms nei ta te stjoeren of persoanlike gegevens te dielen. Meld fertochte aktiviteit mei de opsje ‘Misbrûk melde’.

Mear ynfo

Dizze konversaasje is argivearre. Stel in nije fraach as jo help nedich hawwe.

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

  • 3 antwurd
  • 21 hawwe dit probleem
  • 5 werjeftes
  • Lêste antwurd fan 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.

Bewurke troch VanHeflin op

Alle antwurden (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.

Bewurke troch VanHeflin op

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

Bewurke troch VanHeflin op

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.

Bewurke troch VanHeflin op