Turn ClearType on (or use Vista/Win7 which have it enabled by default) and visit http://hsivonen.iki.fi/test-html5-parsing/. You'll notice that the text is blurry and hard to read. The page looks fine on Opera 10 (Safari 4 doesn't use the downloaded font for some reason). See attached screenshot.

I do know that Opera 10 doesn't use the t2embed API's (because of bugs I've found) so that may be one source for the difference. Probably best place to start is to compare downloadable font testcase with the same testcase using installed version of the font.

Looking at the screenshot, it's clear that the Opera version is rendered with ClearType, but the Gecko one isn't; it uses grayscale-only antialiasing. I notice that the page in question links to both .otf (presumably CFF?) and .ttf versions of a bunch of fonts; it's possible that Opera and Gecko are choosing different formats, which might account for the difference in rendering, but I haven't yet taken the time to investigate whether this is actually the case.

Safari's failure to use the fonts may be because they're apparently being served in .gz format; perhaps that isn't supported. (Incidentally, the page loaded very slowly for me, and provided an excellent example of how bad the user experience can be if the browser renders nothing while waiting for fonts to download. Our approach of rendering with a fallback font and then updating when the proper font is ready worked *much* better here.)

(In reply to comment #2) > I notice that the page in question links to both .otf (presumably CFF?) and > .ttf versions of a bunch of fonts; it's possible that Opera and Gecko are > choosing different formats, which might account for the difference in > rendering, but I haven't yet taken the time to investigate whether this is > actually the case. That's right. Opera picks the ttf version which is thicker than the otf version, and is correctly subpixel antialiased. The ttf version is also showing "correctly" on Firefox. (In reply to comment #3) > Safari's failure to use the fonts may be because they're apparently being > served in .gz format; perhaps that isn't supported. Seems to be the case. It works with the uncompressed version. The otf version is also lacking subpixel antialiasing, but is rendered thicker than the Firefox version (which makes it more readable IMHO).

Testcase with ttf and otf fonts: http://www.spasche.net/files/testcase-bug503150.tar.gz (was too large to attach here). The screenshot shows the testcase rendered with Safari 4, Firefox trunk and Opera 10.

(In reply to comment #4) > (In reply to comment #2) > > I notice that the page in question links to both .otf (presumably CFF?) and > > .ttf versions of a bunch of fonts; it's possible that Opera and Gecko are > > choosing different formats, which might account for the difference in > > rendering, but I haven't yet taken the time to investigate whether this is > > actually the case. > > That's right. Opera picks the ttf version which is thicker than the otf > version, and is correctly subpixel antialiased. > > The ttf version is also showing "correctly" on Firefox. I believe ClearType doesn't apply to CFF fonts (unless the app is using WPF rather than GDI). Because of this, perhaps it would make sense to prefer TrueType fonts if both are offered, as Opera appears to be doing. Unfortunately, this would conflict with the CSS Fonts spec, which says that "When a font is needed the user agent iterates over the set of references listed, using the first one it can successfully activate." This allows the author to specify font resources in order of preference, but it doesn't allow for the UA to prefer one type of resource over another that it can also use but with inferior results. > > (In reply to comment #3) > > Safari's failure to use the fonts may be because they're apparently being > > served in .gz format; perhaps that isn't supported. > > Seems to be the case. It works with the uncompressed version. The otf version > is also lacking subpixel antialiasing, but is rendered thicker than the Firefox > version (which makes it more readable IMHO). I assume Safari is using Apple's own font rasterizer rather than the Windows one, which would account for this difference. That option isn't open to us, of course.

(In reply to comment #6) > I believe ClearType doesn't apply to CFF fonts (unless the app is using WPF > rather than GDI). hmm, that's unfortunate. > Because of this, perhaps it would make sense to prefer TrueType fonts if both > are offered, as Opera appears to be doing. Apparently Opera doesn't recognize the CFF font on that page, so they are conformant when picking the TTF one. > I assume Safari is using Apple's own font rasterizer rather than the Windows > one, which would account for this difference. That option isn't open to us, of > course. We could use FreeType (I guess that's the plan for wince). But that's probably not worth it just for having the correct antialiasing for CFF fonts.

I used CFF outlines for two reasons: 1) The fonts are smaller in terms of bytes than the TTF versions 2) This way, I got around the Windows TTF rasterizer(s), which I think suck compared to Quartz or Freetype. OTOH, if you actually prefer the Windows TTF rasterizer(s)... Note that Opera 10 alpha didn't support .otf/CFF outlines, but the latest public Opera 10 preview builds do support .otf.

(In reply to comment #8) > I used CFF outlines for two reasons: > 1) The fonts are smaller in terms of bytes than the TTF versions Does it depend on the font? For the Biolinum_Re, the TTF is actually smaller: du -hs * 4.1M Biolinum_Re-0.4.1.otf.gz 764K Biolinum_Re-0.4.1.ttf.gz > 2) This way, I got around the Windows TTF rasterizer(s), which I think suck > compared to Quartz or Freetype. > > OTOH, if you actually prefer the Windows TTF rasterizer(s)... That's not really a preference, it's more that visually have difficulties in reading the text rendered with the OTF rasterizer and the Biolinum_Re font. Maybe that's because it lacks LCD antialiasing and I'm using a LCD screen. > Note that Opera 10 alpha didn't support .otf/CFF outlines, but the latest > public Opera 10 preview builds do support .otf. Yes, I tried with 10.00 Beta 2, Build 1631 and the rendering matches Firefox on my testcase.

Seems like there's not a bug here, correct? At least nothing specifically related to rendering with/without ClearType.

From the end user point of view, the "bug" is that even with ClearType enabled, the CFF Windows rasterizer doesn't do subpixel antialiasing. The result is blurry font when the stems are 1px thin (see screenshot). What this bug could turn into: 1) Use another rasterizer on Windows if ClearType is active and a CFF font is used. 2) WONTFIX this.

more datapoints http://hsivonen.iki.fi/test-html5-parsing/ on vista enterprise Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20100110 Minefield/3.7a1pre (.NET CLR 3.5.30729) looks bad in FF and in google chrome. seems fine in IE.

(In reply to comment #9) > (In reply to comment #8) > > I used CFF outlines for two reasons: > > 1) The fonts are smaller in terms of bytes than the TTF versions > > Does it depend on the font? For the Biolinum_Re, the TTF is actually smaller: > du -hs * > 4.1M Biolinum_Re-0.4.1.otf.gz > 764K Biolinum_Re-0.4.1.ttf.gz That's because your TTF font contains nearly 7MB (uncompressed) of garbage (showttf shows no font tables after about the first 1.5MB). After loading and saving the fonts in fontforge to clean them up I get: 185K Biolinum_Re-0.4.1.otf.gz 434K Biolinum_Re-0.4.1.ttf.gz