Closed Bug 504698 Opened 15 years ago Closed 14 years ago

[@font-face] enable ClearType by default on Windows XP

Categories

(Core :: Graphics, defect, P2)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.3a5
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: jtd, Assigned: jtd)

References

(Depends on 1 open bug, )

Details

Attachments

(8 files, 10 obsolete files)

47.96 KB, image/png
Details
19.53 KB, image/png
Details
18.34 KB, image/png
Details
19.83 KB, patch
jfkthame
: review+
Details | Diff | Splinter Review
953 bytes, patch
jfkthame
: review+
Details | Diff | Splinter Review
91.94 KB, image/png
Details
90.99 KB, image/png
Details
20.99 KB, patch
jfkthame
: review+
Details | Diff | Splinter Review
Under Windows XP, ClearType is available but disabled by default.  Platform fonts, which have generally been tuned for the screen, include hinting so that they display well on the screen even at small sizes.  This is not true for fonts available for use as downloadable fonts today, most lack extensive hinting and thus suffer when displayed without ClearType.

Many comments related to the "Potential of Web Typography" article praised the page but were critical of how it displays under Windows XP because of the problem.

IE8 already displays *all* text with ClearType enabled, even under Windows XP, but doing that would really mean a big change for a lot of users.  Just enabling it for downloadable fonts turns it on where it's most needed.  We can also add the option to set it on by default when possible, leaving the option disabled.

The implementation is relatively straightforward, specify the font option CAIRO_ANTIALIAS_SUBPIXEL and use the LOGFONT lfQuality field set to CLEARTYPE_QUALTIY.
Discussion of hinting and ClearType in some of the comments of this Typophile forum posting:

http://typophile.com/node/59489
This enables ClearType rendering based on two prefs:

gfx.downloadable_fonts.use_cleartype (default: true)
gfx.use_cleartype_always (default: false)

The patch is making the assumption that CAIRO_ANTIALIAS_SUBPIXEL implies ClearType but that doesn't seem like such a big deal.  It would be interesting to enable the second setting by default but that needs a lot more consideration.

Probably will tweak this so that it only applies to non-chrome content, that appears to be IE's behavior (i.e. if ClearType is disabled on Windows XP, menus render without ClearType rendering, content renders with).
In each of the two attachments, the non-cleartype rendering is above, the cleartype rendering below.  Especially at smaller sizes, the non-cleartype rendering is hard to, if not impossible, to read.
Is this 1.9.1.x material? If current behaviour is bad enough that people might be hesitant to use @font-face, then we should at least consider it.
Right now https://wiki.mozilla.org/Platform/2009-07-21#GFX_Update says this will be submitted for 1.9.1 and 1.9.2.
It seems like this bug has morphed into not just enabling Cleartype but also discussing some problems with Cleartype. I wanted to point out some further issues on the subject.

While John Doagget points out in comment 5 that small text without cleartype looks unreadable, a reverse situation (albeit less serious) also occurs. Anti-aliasing on larger characters with Cleartype enabled sometimes look much worse. Consider Attachment 389584 [details] on this page:
https://bug504698.bugzilla.mozilla.org/attachment.cgi?id=389584

The blue F and the capital T and P in the “The Potential of Web Typography” look much more jagged with cleartype turned on, even if most of the other letters look a bit better. (Some, like the capital W, look better with Cleartype turned on.)

Also, small text with with @font-face custom fonts may look terrible with Cleartype turned on. I've attached a shot of David Ascher's blog with a custom font and Cleartype turned on.

I don't know if the blame lies solely at Microsoft's feet or if there's something Mozilla can do to improve the display issues. Something should probably be done to address the problem though since Cleartype is on by default and most users wouldn't know how to change it.
Depends on: 517642
Thanks John for your patch :)
I think we could land it into the next release (1.9.2) as an hidden feature (like SMIL) with prefs set to false, so we could test it and decide if enable or not this feature by default.

I have some friends which hate clear type in windows' forms but they like to see smooth fonts on web pages.

What do you think about that?
Priority: -- → P2
What's the status of this? We're having some issues with use of some embedded web fonts on Firefox first-run page. I presume we're not going to be enabling cleartype by default in 3.6?
It would be great to get a status update on this bug.

Firefox on XP seems to be THE major factor that's holding back @font-face at the moment. I'm working on the relaunch of a big news site where we make heavy use of embedded fonts and we were naively ignoring the font smoothing issue because we knew that use of IE6 was almost negligible. - Quite frankly, nobody was used to even thinking about Firefox as a problem for web page display.

Even though we expected the fonts to look worse without antialiasing we were surprised by just how horrifically the chosen font actually rendered. It is also a difficult matter to explain to people who correctly assume that FF is a modern browser that is generally more capable than IE.

We will now have to use some kind of hack like Cufón to make it look acceptable in FF on XP, which will degrade performance significantly.

I just want to provide my team with some kind of perspective for when Cleartype rendering for embedded fonts is scheduled to appear in Firefox. Any information is sincerely appreciated. Thanks!
> we were naively ignoring the font smoothing issue because we knew that use of IE6 was almost negligible.

I wouldn't call ~10% of all web browser usage "almost negligible," but suit yourself.  :)  Admittedly, there are more folks than that running a recent version of Firefox on XP, but based on other stats I'd swag that at  20% of all web browser usage.

In any case, getting better text rendering from Firefox on Windows would be a Good Thing. Enabling GDI ClearType is certainly the easiest thing one could do, and highly preferable to doing nothing.

However, moving to DirectWrite would get one even better rendering, not only for TrueType fonts, but also even more for OpenType CFF fonts (which are not aided one bit by GDI ClearType, still look like crud under any GDI rendering).
Attachment #389093 - Attachment is obsolete: true
Waterfall tests
http://people.mozilla.org/~jdaggett/tests/arialspacing.html
(Uses Arial and C-fonts)

Strange rendering behavior in the 12.5 - 14px for Arial, all four lines are the same width.  Same bug in 3.5/3.6 and also in Chrome 5 but not in IE8.  Argh, more GDI voodoo to figure out...
Only force ClearType rendering under Windows XP, use the system default Cleartype setting on Vista/Win7.

For users who want to tweak this, there are two about:config settings that will affect this behavior under Windows XP:

  gfx.font_rendering.cleartype.always_use_for_content
  gfx.font_rendering.cleartype.use_for_downloadable_fonts

Both default to true.  If 'always_use_for_content' is enabled, Cleartype will be forced on for all fonts.  If it is not, then Cleartype will only be forced on for downloadable fonts if 'use_for_downloadable_fonts' is enabled.  Otherwise the system default settings are used.

This basically mimics IE behavior except that IE allows a user to force Cleartype on for web content but leave it off for other content.  We don't have the ability in all.js to set different prefs for WinXP vs. Vista/Win7 so that's a little more tricky to set up.
Attachment #440133 - Attachment is obsolete: true
Summary: [@font-face] enable ClearType by default for downloaded fonts on Windows → [@font-face] enable ClearType by default on Windows XP
The previous patch used CLEARTYPE_NATURAL_QUALITY for subpixel rendering within Cairo but this leads to goofy results on Windows 7 (font sizes with integer values are rendered GDI-style, with non-integer values differently).

The prefs are the same but they only apply to Windows XP.  We could make a pref for Vista/Win7 users who want to turn off Cleartype system-wide but still use Cleartype for web content but that use case seems far fetched.

There's still a problem related to some strange rendering on XP with ClearType enabled but that problem exists in Firefox 3.6 so I think it's unrelated to the specific changes in this patch.  I'm going to write that up as a separate bug.
Attachment #440158 - Attachment is obsolete: true
WinXP Uniscribe rendering bug now logged under bug 561304.
Try server build with patch v.0.4:
http://bit.ly/a9Mi6R
Comment on attachment 440967 [details] [diff] [review]
patch, v.0.4, revert to default CLEARTYPE_QUALITY

There's still one reftest failure I need to investigate but I think this is ready to land.
Attachment #440967 - Flags: review?(jfkthame)
Comment on attachment 440967 [details] [diff] [review]
patch, v.0.4, revert to default CLEARTYPE_QUALITY

+    // OS version in 16.16 major/minor form
+    enum {
+        kWindowsUnknown = 0,
+        kWindowsXP = 0x50001,
+        kWindowsVista = 0x60000
+    };

The kWindowsXP constant doesn't seem to be used anywhere. I think it'd make sense to either drop it, or if you want to keep it for its documentation value (which I prefer, generally), then extend the set to cover Win2K, Win7, and any others that seem at all relevant (Server 2003?).

+#define GFX_DOWNLOADABLE_FONTS_USE_CLEARTYPE "gfx.font_rendering.cleartype.use_for_downloadable_fonts"
+
+PRBool
+gfxWindowsPlatform::UseClearTypeForDownloadableFonts()
+{
+    static PRBool initialized = PR_FALSE;
+    static PRBool useClearTypeForDownloadableFonts;
+
+    if (initialized == PR_FALSE) {
+        initialized = PR_TRUE;
+        useClearTypeForDownloadableFonts = GetBoolPref(GFX_DOWNLOADABLE_FONTS_USE_CLEARTYPE, PR_TRUE);
+    }
+
+    return useClearTypeForDownloadableFonts;
+}
....And similarly for UseClearTypeAlways().

This looks like the preferences will be read the first time they're needed, and then "stick" until the application is restarted. That seems unfortunate; it would be nice to make them "live-apply".

(This also goes for the downloadable_fonts.enabled pref itself, see bug 507988. IMO, all the gfx.font_rendering.* prefs should be live.)

+enum {
+    kWindowsUnknown = 0,
+    kWindowsXP = 0x50001,
+    kWindowsVista = 0x60000
+};

You've already defined these constants within gfxWindowsPlatform (earlier in the patch).
Attachment #440967 - Flags: review?(jfkthame) → review-
Make the prefs live using a single observer for all font pref (non-font list) related props.
Attachment #440967 - Attachment is obsolete: true
Clean out unneeded code.
Attachment #444364 - Attachment is obsolete: true
Attached patch patch, v.0.5d, make prefs live (obsolete) — Splinter Review
Attachment #444366 - Attachment is obsolete: true
Attachment #444614 - Flags: review?(jfkthame)
What is the reason we're not turning on ClearType on windows just for downloaded fonts?
Comment on attachment 444614 [details] [diff] [review]
patch, v.0.5d, make prefs live

>+    // OS version in 16.16 major/minor form
>+    // based on http://msdn.microsoft.com/en-us/library/ms724834(VS.85).aspx
>+    enum {
>+        kWindowsUnknown = 0,
>+        kWindows2000 = 0x50000,
>+        kWindowsXP = 0x50001,
>+        kWindowsServer2003 = 0x50002,
>+        kWindowsVista = 0x60000,
>+        kWindows7 = 0x60001
>+    };

Could widget/src/windows/nsWindowDefs.h be reused for some of this rather than having to keep two separate lists of Windows version numbers?
Comment on attachment 444614 [details] [diff] [review]
patch, v.0.5d, make prefs live

Looks good, modulo a few nits/suggestions... marking r- for now until these are considered, but that doesn't mean we necessarily have to adopt them all; see what you think, and update or not as appropriate.


+    PRPackedBool  mAllowDownloadableFonts;
+    PRPackedBool  mAllowDownloadableFontsInit;

We've got a number of pairs like this; would it be neater to handle each of them using a single byte field that would be initialized to -1 for "not yet initialized", and set to 0 or 1 once the pref has been read?


+void
+gfxPlatform::FontsPrefsChanged(nsIPrefBranch *aPrefBranch, const char *aPref)
+{
+    if (aPref == nsnull || !strcmp(GFX_DOWNLOADABLE_FONTS_ENABLED, aPref)) {
+        mAllowDownloadableFontsInit = PR_FALSE;
+    }
+}

Can aPref ever be null here? I don't think so, if I understood the observer code right. So maybe just assert that (for debug builds)?


+#define GFX_DOWNLOADABLE_FONTS_USE_CLEARTYPE "gfx.font_rendering.cleartype.use_for_downloadable_fonts"
.....
+#define GFX_USE_CLEARTYPE_ALWAYS "gfx.font_rendering.cleartype.always_use_for_content"

Could we have the #define's together at the beginning of the file, please.

+    if (mUseClearTypeForDownloadableFontsInit == PR_FALSE) {

Prefer "if (!mUseClearTypeForDownloadableFontsInit)".... although I'd really prefer us to move to a pattern using a single variable like

    if (mUserClearTypeForDownloadableFonts == kUninitialized) {
        ....
    }

as suggested above.


+PRUint32
+gfxWindowsPlatform::WindowsOSVersion()
+{
+    static PRBool   initialized = PR_FALSE;
+    static PRUint32 winVersion;

Again, maybe have an "uninitialized" value for winVersion rather than creating an additional variable?


+void
+gfxWindowsPlatform::FontsPrefsChanged(nsIPrefBranch *aPrefBranch, const char *aPref)
+{
+    PRBool clearFontCache = PR_TRUE;
+
+    gfxPlatform::FontsPrefsChanged(aPrefBranch, aPref);
+
+    if (!aPref) {
+        mUseClearTypeForDownloadableFontsInit = PR_FALSE;
+        mUseClearTypeAlwaysInit = PR_FALSE;

I don't think aPref can be null, so this is unnecessary AFAICS.
Attachment #444614 - Flags: review?(jfkthame) → review-
(In reply to comment #27)
> What is the reason we're not turning on ClearType on windows just for
> downloaded fonts?

My initial thought was only to enable this for downloadable fonts on XP but the more I played around with this, the more it seems to make more sense to use Cleartype for all content text on XP.  This is consistent with IE rendering on XP and with the default rendering for all browsers on Vista/Win7.  I left in the pref so that someone who doesn't like Cleartype rendering can disable it for either all fonts or just platform fonts (i.e. not downloadable fonts), since those tend to be well-hinted and render fine with general grayscale anti-aliasing when Cleartype is disabled.

Note that this patch only affects XP rendering behavior, since Cleartype is not enabled by default there (and enabling it system-wide requires a user to know it exists and to download Microsoft's Cleartype Tuner control panel to enable it).
(In reply to comment #30)
> (and enabling it system-wide requires a user to know
> it exists and to download Microsoft's Cleartype Tuner control panel to enable
> it).

The user doesn't need to download anything to enable ClearType (even on XP), though the Tuner is necessary for tuning.
http://www.microsoft.com/typography/cleartypefaq.mspx
Indeed, we should enable ClearType on XP for everything, and have a switch for the people that really hate it.

See also bug 566523, (was discussed in the paper cuts presentation here at Mozilla: http://www.slideshare.net/alexlimi/100-paper-cuts).
(In reply to comment #14)
> > we were naively ignoring the font smoothing issue because we knew that use of IE6 was almost negligible.
> 
> I wouldn't call ~10% of all web browser usage "almost negligible," but suit
> yourself.  :) 

In Germany, for example, the IE6 usage share is below 4%. On many pages even lower. So it is really only Firefox who is blocking @font-face on many websites.
The code now initializes pref bool values to "uninitialized" and sets them based on the pref the first time they are used.

I didn't include the use of constants defined in nsWindowDefs.h, figuring out how those can be shared is a bit tricky.  I'll see if I can figure out something in a follow-on patch.
Attachment #444614 - Attachment is obsolete: true
Attachment #446580 - Flags: review?(jfkthame)
Comment on attachment 446580 [details] [diff] [review]
patch, v.0.6a, updated based on review comments

Please correct spelling of the constant before landing:
s/UNITIALIZED/UNINITIALIZED/g

r=jfkthame with this fixed. :)
Attachment #446580 - Flags: review?(jfkthame) → review+
As a primary XP user, here's my vote for honoring the system setting except for downloadable fonts. I know about the setting, used ClearType for quite a long time (with tweaked settings, mind you) but eventually abandoned it again. It doesn't improve readability with all LCDs, generally needs to be tweaked carefully, and is pretty much unacceptable with CRTs, which might still have a significant share on XP. It's going to trigger bug 363861, too. This bug's focus should be on solving the @font-face problem.
I don't want to speak out to strongly on this because I'm not a regular MS user, but I agree with Dão and Michael Kaplan (comment 9).

XP users don't usually have the Tuner to get ClearType looking its best, and this is overriding a setting for which there is UI without providing UI to let the app follow system settings.

I'm concerned this decision is being made by Mac users.  Anyone who looks at the blurry fonts on Mac all day will find ClearType very tolerable.
This is my feeling too. I've always preferred to have system fonts rendered with ClearType off on my XP system.

But I'll definitely defer to people that have more experience with this sort of thing
The "system setting" for Cleartype on XP is something not enabled by default and it not something users typically are even aware of.  So there's no way to distinguish between "setting never touched" and "user disabled Cleartype because it makes everything fuzzy". 

> I'm concerned this decision is being made by Mac users.  Anyone who
> looks at the blurry fonts on Mac all day will find ClearType very
> tolerable.

This is about rendering on Windows, not other platforms.  By default, IE renders with Cleartype on XP so we're just mimicing that behavior, this is the platform default for rendering web content on XP.  Rendering problems with Cleartype will be the same as those on Vista/Win7 where Cleartype is on by default. 

For those who dislike it, the prefs are there to allow it to be disabled but I think it makes sense to have the default be enabled.  If it's really important to allow this to be disabled, then we should add UI for it to Prefs > Content panel > Fonts & Colors > Advanced...

On Vista/Win7, where Cleartype is enabled by default, the code uses the system defaults.
The default browser on XP is IE6, which most of our users probably migrated from. The chrome / web content distinction introduced by IE7 doesn't make a lot of sense: Apparently MS was unable to consistently decide whether silently enabling ClearType was a clear win. If I had to guess I'd say the general switch came with Vista rather than an XP service pack because the former could assume more modern and consistent hardware.
Pushed to trunk
http://hg.mozilla.org/mozilla-central/rev/cdca90e4e7e7

For those who want to disable Cleartype rendering on XP:

1. Enter 'about:config' in the URL bar
2. In the filter box, type 'gfx.font'

Two Cleartype rendering options are listed.  To disable Cleartype rendering of platform fonts set gfx.font_rendering.cleartype.always_use_for_content to false.  To also disable Cleartype rendering of downloadable fonts, set gfx.font_rendering.cleartype.use_for_downloadable_fonts to false.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
(In reply to comment #41)
> Pushed to trunk
> http://hg.mozilla.org/mozilla-central/rev/cdca90e4e7e7
> 
> For those who want to disable Cleartype rendering on XP:
> 
> 1. Enter 'about:config' in the URL bar
[...]

This might silence nightly testers, but I don't think it's the appropriate response to the concern that silently enabling cleartype could regress usability for lots of ordinary users.
Depends on: 363861
Target Milestone: --- → mozilla1.9.3a5
(In reply to comment #41)
> To disable Cleartype rendering of
> platform fonts set gfx.font_rendering.cleartype.always_use_for_content to
> false.

This seems misleading. I assumed it would refer web content (similar to IE7), while it affects chrome as well.
(14:26:21) cleartypesucksonxp: I really wished you wouldn't enable cleartype on XP, it really sucks on my Sony Trinitron CRT
(14:26:49) cleartypesucksonxp: luckily I manage to find the bug from mozillazine and turn off the crappy cleartype settings
(14:30:01) cleartypesucksonxp: "IE8 already displays *all* text with ClearType enabled" this is false, I turned off Cleartype in IE8 because it looks bad also on the Sony Trintron CRT, please don't make assumptions that you know are not right
Some mixed reactions starting with <http://forums.mozillazine.org/viewtopic.php?p=9422723#p9422723>. Some apparently had it enabled already and didn't notice a difference. You can identify XP users by the UA string at the bottom of each posting.
(In reply to comment #43)
> (In reply to comment #41)
> > To disable Cleartype rendering of
> > platform fonts set gfx.font_rendering.cleartype.always_use_for_content to
> > false.
> 
> This seems misleading. I assumed it would refer web content (similar to IE7),
> while it affects chrome as well.

That's what was intended but the check for chrome/non-chrome is missing, I'll fix that in a follow-on patch tomorrow.
(In reply to comment #42)
> This might silence nightly testers, but I don't think it's the appropriate
> response to the concern that silently enabling cleartype could regress
> usability for lots of ordinary users.

We're trying to improve rendering across the board, that's what DirectWrite support is about, that's what this patch is about.  Using Cleartype is far from perfect but I don't think for most users enabling it means "regressing usability".  As web authors try to use web fonts more and more the one topic that always arises is "wow, looks like crap on XP".  Cleartype can help improve that somewhat.  Cleartype is already enabled by default under Vista/Win7, this change means that we'll hopefully render somewhat consistently across XP/Vista/Win7.

I think it's far better to test the waters by enabling the change for a beta cycle, gauge the reaction and refine how it works.  If too many folks are still using CRTs maybe we should add hardware sniffing for that and flip the prefs in those cases.
(In reply to comment #47)
> We're trying to improve rendering across the board, that's what DirectWrite
> support is about, that's what this patch is about.  Using Cleartype is far from
> perfect but I don't think for most users enabling it means "regressing
> usability".

Maybe it helps a majority, although as you said platform fonts have been tuned anyway. I don't think we'll get more than lukewarm applause, since nobody asked for the change. On the other hand, there's the concern that we'll annoy or even scare away users; that this would affect a minority isn't really a satisfying argument.

Over time the situation would have improved automatically with the most problematic hardware and XP dying out. There was no need to be aggressive about it.

> As web authors try to use web fonts more and more the one topic
> that always arises is "wow, looks like crap on XP".

Nobody is arguing against gfx.font_rendering.cleartype.use_for_downloadable_fonts = true.
(In reply to comment #47)
> As web authors try to use web fonts more and more the one topic
> that always arises is "wow, looks like crap on XP".  Cleartype can help improve
> that somewhat.

I get the impression that there is a lack of understanding that TrueType fonts will look "like crap on XP" if their hints are "crap".  Making good screen fonts is not simple.
ClearType can workaround poor hints, but hopefully the system fonts are better designed.
(If there a problems with PostScript fonts, ClearType won't help on XP.)
Why default can't be "use system setting"?
(In reply to comment #50)
> Why default can't be "use system setting"?

This is exactly existing behavior, if a user enables Cleartype on XP text is rendered with it.  As described in comment 39, the problem is that the default is disabled by default on XP and many users are unaware of this.
Not sure I am understand you right...
Does it mean on Windows 7 and Linux system settings will be respected?
What with Bug 541319?
(In reply to comment #52)
> Not sure I am understand you right...
> Does it mean on Windows 7 and Linux system settings will be respected?
> What with Bug 541319?

This only affects default behavior on Windows XP, no other OS version or platform is affected by this.
(In reply to comment #51)
> (In reply to comment #50)
> > Why default can't be "use system setting"?
> 
> This is exactly existing behavior, if a user enables Cleartype on XP text is
> rendered with it.  As described in comment 39, the problem is that the default
> is disabled by default on XP and many users are unaware of this.

It's a misconception that this is a problem.
(In reply to comment #54)
> (In reply to comment #51)
> > (In reply to comment #50)
> > > Why default can't be "use system setting"?
> > 
> > This is exactly existing behavior, if a user enables Cleartype on XP text is
> > rendered with it.  As described in comment 39, the problem is that the default
> > is disabled by default on XP and many users are unaware of this.
> 
> It's a misconception that this is a problem.

This is a problem since you cannot use any other fonts than the system fonts because they are not readable.
(In reply to comment #55)
> (In reply to comment #54)
> > (In reply to comment #51)
> > > (In reply to comment #50)
> > > > Why default can't be "use system setting"?
> > > 
> > > This is exactly existing behavior, if a user enables Cleartype on XP text is
> > > rendered with it.  As described in comment 39, the problem is that the default
> > > is disabled by default on XP and many users are unaware of this.
> > 
> > It's a misconception that this is a problem.
> 
> This is a problem since you cannot use any other fonts than the system fonts
> because they are not readable.

No, there's code in place to use cleartype only for downloadable fonts despite the system setting. Problem solved. The patch however goes beyond and forces cleartype on system fonts as well.
http://forums.mozillazine.org/viewtopic.php?p=9425213#p9425213 + http://forums.mozillazine.org/viewtopic.php?p=9425309#p9425309

No angry reaction, apparently no hardware problem, I suspect he might even like cleartype if it came by default. But he clearly is irritated by the change and prefers to revert it, which ordinary users won't be capable of. No matter how you look at it, we're not supporting users here.

In the spirit of comment 37's last paragraph, it would be interesting to know whether those in favor of the change (John, limi, ...?) ever used XP as their primary OS and can recall their experience. It's understandable that rendering sans cleartype or some other platform's equivalent looks gross if you're not used to it, but this is about users who /are/ used to it.
> No angry reaction, apparently no hardware problem, I suspect he might
> even like cleartype if it came by default. But he clearly is irritated
> by the change and prefers to revert it, which ordinary users won't be
> capable of. No matter how you look at it, we're not supporting users
> here.

Can't judge much from that, enabling Cleartype for chrome was not my
intention. 

The attached patch disables the pref to force Cleartype rendering for
system fonts until I can set up a patch to enable it for content only.

Before joining Mozilla, XP was my primary platform for 5 years.  The
only reason I found out about Cleartype was that I was puzzled why IE7
seemed to "look better" compared to Firefox.  It required active
investigation on my part, precisely the sort of thing "ordinary users"
probably won't do!

Rendering all content with Cleartype will mean that for most users text
renders with some form of subpixel anti-aliasing across platforms -
Cleartype on XP, DirectWrite on Vista/Win7, and general subpixel
anti-aliasing on OSX and Linux.
Attachment #447962 - Flags: review?(jfkthame)
Comment on attachment 447962 [details] [diff] [review]
follow-on patch, disable forcing cleartype for system fonts

Yes, I think we should default this to OFF, at least until the chrome/content distinction is handled properly.

Ultimately, shouldn't the decision on default values for these prefs probably be made by the UX team?
Attachment #447962 - Flags: review?(jfkthame) → review+
(In reply to comment #58)
> Created an attachment (id=447962) [details]
> follow-on patch, disable forcing cleartype for system fonts
> 
> > No angry reaction, apparently no hardware problem, I suspect he might
> > even like cleartype if it came by default. But he clearly is irritated
> > by the change and prefers to revert it, which ordinary users won't be
> > capable of. No matter how you look at it, we're not supporting users
> > here.
> 
> Can't judge much from that, enabling Cleartype for chrome was not my
> intention.

Yeah, he explicitly referred to chrome elements, but web content as well.
pushed patch to disable forcing on Cleartype for system fonts (downloadable fonts will still be rendered with Cleartype on XP)
http://hg.mozilla.org/mozilla-central/rev/ae76b1595479
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Huh ?  All I did was CC myself, no idea how it got 'Resolved Fixed'  Re-opening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #61)
> pushed patch to disable forcing on Cleartype for system fonts (downloadable
> fonts will still be rendered with Cleartype on XP)
> http://hg.mozilla.org/mozilla-central/rev/ae76b1595479

The Windows reftests have consistently failed since this landed.
(In reply to comment #63)
> (In reply to comment #61)
> > pushed patch to disable forcing on Cleartype for system fonts (downloadable
> > fonts will still be rendered with Cleartype on XP)
> > http://hg.mozilla.org/mozilla-central/rev/ae76b1595479
> 
> The Windows reftests have consistently failed since this landed.

This happens because the reftests for @font-face { src: local(...) } are comparing the rendering of a system font (hence using non-ClearType rendering) with the same font loaded via @font-face (using ClearType).
Specifically, the 4 reftest failures are:

REFTEST TEST-UNEXPECTED-FAIL | file:///e:/builds/moz2_slave/mozilla-central-win32-opt-unittest-reftest/build/reftest/tests/layout/reftests/font-face/src-list-local-full.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///e:/builds/moz2_slave/mozilla-central-win32-opt-unittest-reftest/build/reftest/tests/layout/reftests/font-face/src-list-local-full-quotes.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///e:/builds/moz2_slave/mozilla-central-win32-opt-unittest-reftest/build/reftest/tests/layout/reftests/font-face/src-list-local-ps.html |
REFTEST TEST-UNEXPECTED-FAIL | file:///e:/builds/moz2_slave/mozilla-central-win32-opt-unittest-reftest/build/reftest/tests/layout/reftests/font-face/local-1.html |

In each case the test page, using @font-face with a src:local() font, renders with ClearType; the reference renders using system settings.

Marked these 4 tests as random on windows for the time being:
http://hg.mozilla.org/mozilla-central/rev/5f85f8f99743
I wouldn't hold the release for this, but we should get it done.
blocking2.0: ? → -
status2.0: --- → wanted
This bug is in a confusing state now, we should either resolve it again or remove [@font-face] from the summary.
Screenshot showing four columns:

a. FF 3.6 rendering (system setting: Cleartype off)
b. Downloadable fonts use cleartype, system fonts don't (system setting: Cleartype off)
c. Cleartype used for all content (system setting: Cleartype off)
d. system setting: Cleartype on (same as FF 3.6)

Note how Gentium renders differently in (a) and (b),(c),(d).  And now system fonts render in (a),(b) vs. (c),(d)
Attached image annotated version of John's screenshot (obsolete) —
This is simply John's screenshot, annotated by me.
(pngcrush makes things smaller!)
Attachment #448552 - Attachment is obsolete: true
Depends on: 569408
Updated with better clearing of font cache and textrun word cache so that config options are truly live (borrowed part of this from harfbuzz patches).  Have left the option to force Cleartype for system fonts off for now.
Attachment #448349 - Attachment is obsolete: true
Attachment #448706 - Flags: review?(jfkthame)
This needs refreshing since the Variation Selectors patch landed.

Aside from that: I tried this in my XP VM, and the "live" config option does not seem to be fully alive yet - it doesn't change until I deliberately force a refresh of the page, e.g. by zooming or reloading. Can we get this fixed so that it forces a refresh immediately when the pref changes?

(In comparison, changing the harfbuzz.level preference - with those patches, obviously - causes an immediate "live" change in any currently-displayed windows.)
BTW, the patch description is confusing - it should be "only...for CONTENT", not Chrome elements!
Refreshed.  Added changes from harfbuzz patch for reflowing pages immediately on gfx.font-rendering.* pref change.
Attachment #448706 - Attachment is obsolete: true
Attachment #449579 - Flags: review?(jfkthame)
Attachment #448706 - Flags: review?(jfkthame)
Attachment #449579 - Flags: review?(jfkthame) → review+
Follow-on patch pushed to trunk.
http://hg.mozilla.org/mozilla-central/rev/d4e6501718f7
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Depends on: 1334860
You need to log in before you can comment on or make changes to this bug.