651789 - force_gdi_classic_for_families for "Trebuchet MS" should still have effect at 17px (faded "W"s)

Status: NEW

(Core :: Graphics: Text, defect, P3)

Description

[Ed Hume]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

W's on my display show up with the center inverted-V faded. I'll attach a screenshot.

Reproducible: Always

Steps to Reproduce:
1. Turn on Firefox.
2.
3.
Actual Results:  
Center portion of W's faded.

Expected Results:  
Letters should be solid, as in Firefox 3.6.

Regardless of theme chosen.

Comment 1

[Ed Hume]

Attachment: selection of screenshot that shows faded w's

You may have to enlarge the image to see the full effect.

Comment 2

[j.j.]

Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Can't reproduce on XP

Comment 3

[Tyler Downer [He/Him]]

Likely the font you have selected. Try creating a fresh profile, http://support.mozilla.com/kb/Managing+profiles

Comment 4

[Jonathan Kew [:jfkthame]]

This looks like a result of DirectWrite/D2D antialiasing. You may be able to improve the result by using the ClearType Tuner control panel to customize the behavior for your display.

In bug 642589, we've just added several prefs that can be used to fine-tune the antialiasing behavior under DW/D2D, including the possibility of using "classic" GDI-style hinting and antialiasing (which gives less accurate glyph shapes and metrics, but often a "crisper" appearance) for people who prefer that. This should appear in Nightly builds soon, if you want to experiment with alternative text-rendering options.

Comment 5

[Ed Hume]

Attachment: More weak w's from Mozillazine forums

Totally reamed out a profile - no files.

Still an issue.

Comment 6

[Ed Hume]

Attachment: Same piece of page, this time on Firefox 3.6

Look at the w's here. Same font, but this time on Firefox 3.6.

This was good. The Firefox 4 shot shows weakness. That is a regression.

Comment 7

[j.j.]

Attachment: testcase

How does this work for you?
(No need for screenshots, nobody doubts your words)

Comment 8

[Ed Hume]

In the test case, the w in the large font is fine. The w in the small font has a faded middle.

Comment 9

[j.j.]

Attachment: testcase2

Which font and font-size, besides Trebuchet MS 12px, is affected?

Comment 10

[Jonathan Kew [:jfkthame]]

Attachment: IE9 screenshot showing the poor rendering of "w" in Trebuchet MS

The Trebuchet "w" is particularly bad at 16px, too. The same issue shows up in IE9 (see attached screenshot), as it also makes use of DirectWrite & D2D.

This is not really a Firefox bug, it is simply how the Trebuchet font renders on Windows under DirectWrite/D2D. (I agree it looks terrible, though!)

It looks better in Fx3.6 because that uses the old GDI rendering path, which has a completely different font rasterizer. You'll get that same result if you disable hardware acceleration in Fx4 (but this may greatly degrade performance for some kinds of pages).

In the latest Nightly build, you can go to about:config and set gfx.font_rendering.cleartype_params.rendering_mode to 2 (GDI Classic) or 3 (GDI Natural Widths) to get font rendering that is much more like Fx3.6; this fixes the weak "w" in Trebuchet. Note that the glyph shapes and/or spacing with some fonts may be less precise than under standard DirectWrite rendering, however.

Comment 11

[j.j.]

So what the resolution for this bug, WONTFIX or INVALID?

Comment 12

[Roman]

This problem still happens. It would be nice if Firefox could have an exception for this particular font/size combination and rendered it using GDI. I mean fine, it might be that DirectWrite sucks when rendering this "w", but Firefox is the one who chooses to use that API; maybe it's up to Firefox to work around the flaws in it.

Marking NEW; if such an exception is off the table, please mark WONTFIX.

Comment 13

[j.j.]

Per comment 10 it's not Mozilla's bug.
If it was, "Firefox/General" would be the wrong product/component

Comment 14

[Roman]

Agreed, this is not a Mozilla bug. However, Firefox already implements a preference to work around this bug: "gfx.font_rendering.cleartype_params.force_gdi_classic_for_families"

The problem is, this list is hard-coded to stop working at 16px. That's exactly where the problem occurs. For Trebuchet MS, the switch-over should happen at 17px instead.

I've renamed the bug to clarify what exactly needs to be done. See also bug 661471, which originally introduced this preference.

Comment 15

[Terrell Kelley]

I can confirm that changing gfx.font_rendering.cleartype_params.force_gdi_classic_max_size to 17 fixes this. I have not noticed any regressions in other fonts, so that seems like an easy fix.

Comment 16

[u279076]

I can't see this locally. Does this still reproduce?

Comment 17

[Ed Hume]

I still see the problem -- but now it shows up in the testcase on Trebuchet 16px

Comment 18

[roeme]

Having this problem as well. A body of text with Trebuchet MS with a font-size setting of 15px renders notably worse compared to IE/Chrome. Increasing "gfx.font_rendering.cleartype_params.force_gdi_classic_max_size" has no effect, and according to this quote this is expected: 

> The problem is, this list is hard-coded to stop working at 16px. That's exactly where the problem occurs. For Trebuchet MS, the switch-over should happen at 17px instead.

Comment 19

[Mark Straver]

I was about to file a new bug but saw this was already filed (and a very long time ago at that!).
Just a note then that this is still a problem in the latest nightly as of today (2019-03-06). Trebuchet is e.g. the default font for (probably) the most popular bulletin board software (phpBB) out there, and this occurs on all D2D/Dwrite setups (the majority of Windows systems) so this has a lot of exposure.

I confirmed that setting gfx.font_rendering.cleartype_params.force_gdi_classic_max_size to 17 and restarting the browser completely fixes this issue with no noted drawbacks at all on font rendering otherwise, anywhere.
Considering the GDI font list is specifically listed to be a subset of fonts, i would expect the related parameter to have a value that fixes rendering for all listed fonts there -- unfortunately the default setting of "15" does not.

Suggested fix:
Set gfx.font_rendering.cleartype_params.force_gdi_classic_max_size to 17 by default.

Comment 20

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Throwing this back into the triage queue.

Comment 21

[Lee Salzman [:lsalzman]]

Jonathan, any ideas if there is still something we can do here, or should we just WONTFIX this?

Comment 22

[Jonathan Kew [:jfkthame]]

Well, I can't see us doing a per-font size threshold for this setting, but we could bump the default value for gfx.font_rendering.cleartype_params.force_gdi_classic_max_size to 17 as suggested by Mark in comment 19.

Obviously, this would also affect the rendering of the other fonts in the GDI-classic list. I don't know if anyone would regard that as a regression, or if it's unimportant. I suspect things like Arial, Tahoma and Verdana are often seen at 16px on the web, so it'd be worth having a look to see how they compare.

Comment 23

[Mark Straver]

Attachment: font comparison D2D/GDI

I made a quick test rendering the stated fonts in the previous comment at 16px with the setting at 15 and 17 respectively.
Aside from the very much broken diagonals (V and W specifically) in Trebuchet @ 15, the only real difference I see is that the DWrite versions have a very slightly darker face but also poorer letter spacing and some verticals are not as sharp (compare e.g. Tahoma)

Overall, I personally think the GDI rendered versions at 16px actually look a little sharper across the board and have slightly better legibility.

Comment 24

[Terrell Kelley]

The post I made 6 years ago remains true. I've consistently run Windows Firefox with that setting at 17 instead of 15 and noticed no font regressions. In fact, I had completely forgotten I had made that change.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.