From bug 661471 comment 93: Two more fonts to consider for the fallback list: 1) Microsoft Sans Serif -- This is the default font used for form controls (it's what MS Shell Dlg maps to). Since it is an adaptation of the old MS Sans Serif raster font, a GDI-style rendering is arguably closest to its "intended" appearance. (And it looks better that way, too.) 2) Consolas -- It is somewhat widely used as a code font (developer.mozilla.org's fancy code formatting thing uses it, and so does the MSDN library). The fuzzier appearance of the natural rendering of this font at 10pt (esp. with color) was one of the reasons Microsoft backed down on using natural in VS2010. Also, as a monospace font, the positioning fidelity of natural seems less relevant.

While I have no particular objection to rendering these particular fonts using GDI_CLASSIC, I predict that requests to add more items to this list will never cease. For that reason, I recommend one of two outcomes to this bug: 1. WONTFIX. We just leave the list alone. 2. Apply this patch, but with the proviso that it's the last one we'll take until Firefox 8.

(In reply to comment #1) > While I have no particular objection to rendering these particular fonts > using GDI_CLASSIC, I predict that requests to add more items to this list > will never cease. That would be evidence that we should just switch everything to GDI_CLASSIC as Jonathan and I advocated.

(In reply to comment #2) > (In reply to comment #1) > > While I have no particular objection to rendering these particular fonts > > using GDI_CLASSIC, I predict that requests to add more items to this list > > will never cease. > > That would be evidence that we should just switch everything to GDI_CLASSIC > as Jonathan and I advocated. No, it's evidence that there are two separate and distinct problems and these should be addressed differently. The first is that core web fonts were originally tuned specifically for integer pixel placement. Switching them to render in DirectWrite leads to very tight spacing at low pixel sizes (e.g. 9-14px) which makes text harder to read. The second problem is that the default gamma for rendering is effectively different for GDI Classic and the DirectWrite rendering modes, which leads to "lighter" rasterization of outlines in DirectWrite for small font sizes. The force_gdi_classic_for_families should be used to address the first problem, explicitly bumping/overriding the contrast or text gamma would be more appropriate for the second. I don't think Consolas belongs on the list, nor does Segoe UI (which was added in one of the many follow-on patches in bug 661471. Not sure about MS Sans Serif.

Segoe was added in bug 661869, and that's the only that's been added so far. And I think Kai's argument in bug 661869 comment #0 is completely reasonable: we should render the system UI font the same way it's rendered elsewhere in the system UI, which is GDI Classic.

If we end up resolving this bug by tweaking gamma, that's fine with me.

I am not convinced that adjusting the contrast is sufficient. I had toyed with various contrast levels, and yes, it does solve the problem of text looking "lighter", but "darkening" the text does not solve everything. In the case of Segoe UI specifically, the text does not look as "crisp" (for lack of a better way to describe it); it looks "dirtier" (again, I apologize for the lack of more precise wording) because the edges are not as smooth and polished. For example, with GDI classic, the character "a" in Segoe UI 9pt is hinted such that it's narrower and slightly straighter, and with natural, it's slightly rounder and wider, which results in extra, faint pixels on the left and right edges of the glyph. While this is more accurate, these faint pixels look a lot more like rendering artifacts: stray bits dangling off of the glyph, and the GDI classic rendering, in contrast, looks "cleaner" with sharper edges. This is the kind of inherent trade-off that no amount of contrast fiddling will ever change. Nor are Microsoft's new ClearType-enhanced fonts (the C-series and Segoe) immune to this: this isn't about spacing, but the appearance of the glyphs themselves. Personally, Segoe UI stands out the most because of its widespread use as the UI font, because it is usually displayed at a fairly small size (by default, 9pt in NT6+), and because the artifacts of natural rendering are made much more apparent when there is so much classically-rendered Segoe around the system readily available for comparison. In any case, I wonder if there is there some mechanism by which we can get user feedback about this? And I don't mean the kind of feedback that angry users motivated to affect a change gives, but a more representative sampling.

(In reply to comment #6) > For example, with GDI classic, the character "a" in Segoe UI 9pt is hinted > such that it's narrower and slightly straighter, and with natural, it's > slightly rounder and wider, which results in extra, faint pixels on the left > and right edges of the glyph. While this is more accurate, these faint > pixels look a lot more like rendering artifacts: stray bits dangling off of > the glyph, and the GDI classic rendering, in contrast, looks "cleaner" with > sharper edges. This is the kind of inherent trade-off that no amount of > contrast fiddling will ever change. Nor are Microsoft's new > ClearType-enhanced fonts (the C-series and Segoe) immune to this: this isn't > about spacing, but the appearance of the glyphs themselves. > > Personally, Segoe UI stands out the most because of its widespread use as > the UI font, because it is usually displayed at a fairly small size (by > default, 9pt in NT6+), and because the artifacts of natural rendering are > made much more apparent when there is so much classically-rendered Segoe > around the system readily available for comparison. I can confirm this as far as the Firefox UI is concerned. For us the accuracy doesn't seem to pay at all. Tweaking the contrast and gamma may mitigate things but still wouldn't make natural rendering a better choice.

Comment on attachment 539079 [details] [diff] [review] add Microsoft Sans Serif and Consolas to force_gdi_classic_for_families I don't suppose we're ever going to get complete unanimity on the particular list of fonts here (which is one reason I wasn't keen on this approach). I'm going to r+ this patch, though, as I think Kai Liu makes a reasonable case and I don't see any strong reason to reject it, aside from the churn involved.

(In reply to comment #8) > I don't suppose we're ever going to get complete unanimity on the particular > list of fonts here (which is one reason I wasn't keen on this approach). FWIW, I also preferred a wholesale switch to GDI classic (with a size cutoff, since that part does make a lot of sense). The rationale for segregating by specific fonts given in comment 3 cites differences in spacing and gamma between different fonts, but IMHO, the most important issue is hinting, specifically the loss of sharpness that results from natural's weak hinting (e.g., Segoe UI's "a" at 9pt). This particular issue is independent of those mentioned in comment 3 and that affects all fonts.

Comment on attachment 539079 [details] [diff] [review] add Microsoft Sans Serif and Consolas to force_gdi_classic_for_families Another follow-up to bug 661471 that we should take at the same time on aurora, to harmonize the channels as much as possible. There's no significant "risk" here, just adjusting default prefs for consistency.

Comment on attachment 539079 [details] [diff] [review] add Microsoft Sans Serif and Consolas to force_gdi_classic_for_families We should a) decide if we're going to land this on m-c, and b) actually do that, before asking for Aurora here.

Well, I would've landed it today but the tree was a colourful mess! If we eventually come up with an alternative solution using gamma, contrast, or whatever that provides satisfactory results - which is an open question at this point; see the comments here - then we might reconsider this. But for the time being I think Kai makes a reasonable case and we should take the patch, at least until we have a viable alternative to offer. So, pushed to mozilla-inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/bdab292ad9cb

(In reply to comment #9) > (In reply to comment #8) > > I don't suppose we're ever going to get complete unanimity on the particular > > list of fonts here (which is one reason I wasn't keen on this approach). > > FWIW, I also preferred a wholesale switch to GDI classic (with a size > cutoff, since that part does make a lot of sense). The rationale for > segregating by specific fonts given in comment 3 cites differences in > spacing and gamma between different fonts, but IMHO, the most important > issue is hinting, specifically the loss of sharpness that results from > natural's weak hinting (e.g., Segoe UI's "a" at 9pt). This particular issue > is independent of those mentioned in comment 3 and that affects all fonts. I'll say again that I think we should be tackling the two problems of the what to do with fonts that are really hinted with an integer grid in mind (e.g. Arial, Tahoma, Verdana but *not* Segoe UI) from the more general problem that the default Cleartype rendering parameters render all fonts more lightly in DirectWrite-specific rendering modes when compared to GDI modes. Note that it's perfectly possible that Microsoft could update the fonts in question in a way such that the hinting would be tuned differently for GDI vs. DirectWrite-only rendering modes. This would actually be the preferred solution, since this is more of a platform problem than a Gecko problem. I agree that we'll never get unanimity but that's no excuse for steam rolling a one-size-fits-all solution. We should at least have some reasoning behind what we're doing here rather than trying to solve the default contrast difference problem using the solution for fonts designed for integer grid layout. Looking at actual examples of Segoe UI in use I don't see anywhere near the clear cut distinction between rendering with GDI modes vs. DirectWrite-specific modes. It depends a lot on the font size, the specific text involved along with the background and foreground colors used. The idea that a given rendering mode is *universally* "crisper" or "cleaner" I think is hard to back up when comparing actual renderings. A complication here is that there are still elements of the UI that are rendered with grayscale anti-aliasing like tooltips and text in the status overlay that will emphasize the default contrast differences between GDI and DirectWrite-specific rendering modes.

(In reply to comment #13) > Looking at actual examples of Segoe UI in use I > don't see anywhere near the clear cut distinction between rendering with GDI > modes vs. DirectWrite-specific modes. It depends a lot on the font size, > the specific text involved along with the background and foreground colors > used. The idea that a given rendering mode is *universally* "crisper" or > "cleaner" I think is hard to back up when comparing actual renderings. Nobody was using the word "universally" or implying it. But if Natural is sometimes on par with GDI Classic and sometimes worse, it's still a loss. Can you point out an example where Natural has the edge over GDI Classic in the Firefox UI?

From left to right, default (GDI Classic rendering), DirectWrite rendering mode 5 (natural symmetric) and rendering mode 4 (natural)

Same comparison for the history menu

On the default is DirectWrite rendering mode 5 with enhanced contrast set to 100 vs. GDI rendering on the right (using Chrome)

The attached examples are all showing how Segoe UI renders with different rendering modes. In the two UI screenshots, I don't see any reason to assert that GDI classic mode is inherently "better" or more readable. And it appears to me that DirectWrite rendering mode 5 (natural symmetric, *not* the default at these sizes) has better contrast than the GDI classic rendering. The side effect of grouping Segoe UI into the group of fonts for which GDI is used is that any page that uses Segoe UI in the future will have to deal with the fact that GDI gives uneven rendering across a set of small sizes. Look at the screenshot marked "Segoe UI, natural symmetric..." This compares text drawn in Segoe UI with rendering mode 5 and enhanced contrast set to 100 with the same sizes drawn in GDI. Note how the text on the left is looks consistent across a set of sizes. The GDI rendering is much more variable, at 11px it's a mess, the spacing makes it really hard to read even though it's higher contrast than the DirectWrite rendering at the same size. Now look at the 14px version, the contrast is better in the DirectWrite rendering and the spacing is much more even. In this case it's the GDI rendering that's "fuzzy". The last example also illustrates why fixating on GDI rendering is a trap. For a given font at a given size, it's easy to assert "GDI is clearly better" (e.g. 12px Segoe UI) because it happens to rasterize more boldly at that given size. But across a set of sizes GDI rendering is maddeningly inconsistent, at some sizes it's fine, at others a total nightmare. No designer who cares about text would choose the way GDI renders Segoe UI at 11px. With GDI rendering, designers need to be very careful to avoid the pitfalls of these "bad" sizes. They're already accustomed to this with the existing webfonts (e.g. Arial, Verdana) but there's no reason to extend this to fonts that were designed to be laid out on a subpixel grid.

The two UI screenshots were taken on a system with a high DPI and thus a larger effective font size. At larger sizes, the downsides of N/NS are greatly mitigated; the size that matters for most users is 9pt at 96 DPI, which I think is close to the 12px comparison in the third image. As for the third image, you point out that the spacing looks better with NS at 11px, and I agree. But what is the cost of that spacing improvement? Look closely, for example, at the "ll" sequences: two identical letters side-by-side that look different from each other. The "I" in Internet in the first line of text looks okay, but the same "I" in the final line of text has a noticeably fainter stem. While you see inconsistency in spacing in the GC rendering, I see inconsistency in the glyphs themselves in the NS rendering. And yes, designers probably do prefer the better layout consistency and the better fidelity of N/NS, and I suspect this is part of the reason why designers have preferred Apple and its more faithful font rendering. I do not (and never have) disputed these advantages of N/NS. What I argue is that those advantages come at a cost: the crispness of each glyph. The aggressive grid-conforming hinting that Windows' GDI uses distorts size, spacing, shape, and even boldness, but the end result are glyphs that are sharp and crisp. Maybe it's because my primary OS is Windows and I just like what I am most used to, but I have always found this heavy-handed hinting to be attractive, easy on the eyes, and the the primary reason why using OS X or Linux for an extended period of time is maddening (aside: arguably, this is also what enables Windows to use UI fonts that are noticeably thinner and lighter than OS X's). And I suspect that for many users of the Windows version of Firefox, they too are used to and prefer this pragmatic trade-off of correctness in favor of crispness that Windows has traditionally offered.

A more dramatic example of what I mean by the lack of consistency between glyphs could be seen in attachment 504760 [details] of bug 626293. Also, I think that pixel pitch may play a role here as well. I just did a comparison on a larger screen that has a lower native resolution, and the problems with N/NS look even worse. A number of changes around the Vista era seemed to assume that the world would shift towards a high-resolution (and high-DPI) standard: the larger default icon sizes, the space-eating ribbon UI in Office 2007, the inclusion of huge 256px icons, and the first implementation of natural rendering with the Windows Presentation Foundation. Instead, today, we have 1024x600 netbooks and 18.5" monitors with a ghastly 1366x768 resolution. The PC market never got the high DPIs that would effectively result in larger font sizes and the smaller pixels that might better hide the shortcomings of N/NS.

(In reply to comment #21) > A more dramatic example of what I mean by the lack of consistency between > glyphs could be seen in attachment 504760 [details] of bug 626293. What are you pointing at in particular? The url bar is rendered with grayscale anti-aliasing, the result of the layer manager changes landing before all the subpixel antialiasing changes were properly fixed. Note that this issue still exists with tooltips and the status bar overlay thingy.

From left to right, default (GDI Classic), DirectWrite rendering mode 5 with gamma set to 1800, DirectWrite rendering mode with enhanced contrast set to 100

GDI Classic rendering of the history menu on the left, DirectWrite rendering mode 5 with gamma set to 1800 on the right The point of these two screenshots shows that we can effectively reduce the contrast difference between GDI Classic and DirectWrite natural symmetric rendering to where the main difference is that the GDI rasterization is slightly more aliased than the DirectWrite rasterization. Some folks prefer slightly more aliased, just as some folks prefer turning off Cleartype altogether but that comes with a clear penalty, text will end up rendered unevenly across a range of sizes, there will be "sweet sizes" where text magically renders better than at other sizes.