Open Bug 782226 Opened 12 years ago Updated 2 years ago

Firefox uses worse OTF/CFF rasterizer than IE9

Categories

(Core :: Graphics: Text, defect)

x86
Windows 7
defect

Tracking

()

People

(Reporter: hsivonen, Unassigned)

References

()

Details

Attachments

(2 files)

Steps to reproduce:
1) Load http://hsivonen.iki.fi/test/libertine/libertine.html in IE9 on Windows 7
2) Look at the paragraph under the heading "URL OTF"
3) Look at the paragraph under the heading "URL TTF"
4) Load http://hsivonen.iki.fi/test/libertine/libertine.html in Firefox on Windows 7
5) Look at the paragraph under the heading "URL OTF"
6) Look at the paragraph under the heading "URL TTF"

Actual results:
The TTF rasterization that looks similar in IE9 and in Firefox. In IE9, the OTF rasterization looks relatively similar to the TTF rasterization. In Firefox, the OTF rasterization looks faint, because there's too much gray in the anti-aliasing. (All rasterizations in Firefox and IE9 on Windows looks worse than Quartz or FreeType rasterizations, of course.)

Expected results:
Expected Firefox to use the same OTF/CFF rasterizer as IE9.
Looks like Firefox is using GDI instead of DWrite (possibly because the GPU driver is blacklisted for some reason).

GDI doesn't use ClearType for CFF outlines and those CFF fonts don't have the hinting instructions of TTF fonts to improve the appearance.

So I think this bug comes down to: should Firefox be using DWrite because IE9 is?
(In reply to Karl Tomlinson (:karlt) from comment #3)
> Looks like Firefox is using GDI instead of DWrite (possibly because the GPU
> driver is blacklisted for some reason).

In this case, the GPU is VirtualBox’s “GPU”, which is blacklisted along other VM “GPU”s.

> GDI doesn't use ClearType for CFF outlines and those CFF fonts don't have
> the hinting instructions of TTF fonts to improve the appearance.

CFF fonts do have declarative hints, though.

> So I think this bug comes down to: should Firefox be using DWrite because
> IE9 is?

Rather, it comes down to: Should Firefox use the best CFF rasterizer the system makes available when the non-best CFF rasterizer is so bad that it practically makes CFF fonts unusable on the Web (in non-headline sizes)? I think the answer should be: “Yes, Firefox should use the best CFF rasterizer provided by the system in order not to make CFF fonts unusable.”

Note: PDFs may easily contain Type 1 outlines, because Adobe’s rasterizer didn’t do a terrible job with them. It would be really sad for PDF.js to end up using the GDI CFF rasterizer for those after PDF.js converts Type 1 to CFF. (I haven’t tested yet.)
(In reply to Henri Sivonen (:hsivonen) from comment #4)
> Rather, it comes down to: Should Firefox use the best CFF rasterizer the
> system makes available when the non-best CFF rasterizer is so bad that it
> practically makes CFF fonts unusable on the Web (in non-headline sizes)? I
> think the answer should be: “Yes, Firefox should use the best CFF rasterizer
> provided by the system in order not to make CFF fonts unusable.”

Makes sense.
So I think this might be better titled "force DirectWrite on even when HW acceleration isn't available".  This was originally the plan but it was derailed by all the squealing about the use of DirectWrite vs. GDI (to get aliased font rendering users would turn off HW acceleration).
(In reply to John Daggett (:jtd) from comment #6)
> So I think this might be better titled "force DirectWrite on even when HW
> acceleration isn't available".

That's probably the solution, yeah. The bug is filed about the symptom. I hope the bug doesn't morph so far the CFF symptoms get forgotten along the way.
(In reply to John Daggett (:jtd) from comment #6)
> So I think this might be better titled "force DirectWrite on even when HW
> acceleration isn't available".

If we do that, bug 842521 should be reopened.
Depends on: 842521
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: