Last Comment Bug 503150 - [@font-face] Thin (downloaded) CFF fonts are blurry (even when ClearType is enabled)
: [@font-face] Thin (downloaded) CFF fonts are blurry (even when ClearType is e...
Status: NEW
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: x86 Windows 7
: -- normal with 7 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://hsivonen.iki.fi/test-html5-par...
Depends on: 517642
Blocks: 70132
  Show dependency treegraph
 
Reported: 2009-07-08 12:26 PDT by Sylvain Pasche
Modified: 2012-01-19 05:17 PST (History)
18 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot of Firefox trunk and Opera 10 (111.94 KB, image/png)
2009-07-08 12:26 PDT, Sylvain Pasche
no flags Details
screenshot (206.28 KB, image/png)
2009-07-08 15:10 PDT, Sylvain Pasche
no flags Details
Windows (top) vs Linux (bottom) comparison (12.41 KB, image/png)
2009-07-17 05:01 PDT, Sylvain Pasche
no flags Details

Description Sylvain Pasche 2009-07-08 12:26:52 PDT
Created attachment 387506 [details]
Screenshot of Firefox trunk and Opera 10

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.
Comment 1 John Daggett (:jtd) 2009-07-08 12:35:58 PDT
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.
Comment 2 Jonathan Kew (:jfkthame) 2009-07-08 13:56:14 PDT
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.
Comment 3 Jonathan Kew (:jfkthame) 2009-07-08 14:00:50 PDT
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.)
Comment 4 Sylvain Pasche 2009-07-08 15:04:33 PDT
(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).
Comment 5 Sylvain Pasche 2009-07-08 15:10:43 PDT
Created attachment 387547 [details]
screenshot

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.
Comment 6 Jonathan Kew (:jfkthame) 2009-07-08 15:28:29 PDT
(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.
Comment 7 Sylvain Pasche 2009-07-08 16:09:16 PDT
(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.
Comment 8 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2009-07-14 04:13:33 PDT
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.
Comment 9 Sylvain Pasche 2009-07-14 05:09:49 PDT
(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.
Comment 10 John Daggett (:jtd) 2009-07-16 17:12:04 PDT
Seems like there's not a bug here, correct?  At least nothing specifically related to rendering with/without ClearType.
Comment 11 Sylvain Pasche 2009-07-17 05:01:31 PDT
Created attachment 389103 [details]
Windows (top) vs Linux (bottom) comparison

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.
Comment 12 Wayne Mery (:wsmwk, NI for questions) 2010-02-06 05:13:55 PST
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.
Comment 13 Adrian Johnson 2011-01-13 04:15:25 PST
(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

Note You need to log in before you can comment on or make changes to this bug.