User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 Since I installed Firefox 4 Beta 5 today I noticed that the ugly font rendering, which was present in Beta 4 with activated gfx.font_rendering.directwrite.enabled in about:config, has been replaced with the a new, better looking rendering. But there is a problem with incorrect margins between the chars of a text, sometimes the chars too near each other, sometimes there are big spaces between them. I could think of a problem with this new way of font rendering in Beta 5. I've attached two screenshots with orange markers showing examples for the wrong margins. Reproducible: Always Steps to Reproduce: load a random website Actual Results: described above Expected Results: Good font rendering. For the sake of completeness I have to remark that gfx.font_rendering.directwrite.enabled is actually set to false, but I've webgl.enabled_for_all_sites set to true (despite if it is relevant or not).

Please post your Graphics Info from about:support (at the Bottom).

Adapter Description NVIDIA GeForce GTX 260 Vendor ID 10de Device ID 05e2 Adapter RAM 896 Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Driver Version 8.17.12.5896 Driver Date 7-9-2010 Direct2D Enabled true DirectWrite Enabled true

Same problem here with a GTX 275 in Windows 7 x64. The problem is noticeably worse on some pages. Adapter Description NVIDIA GeForce GTX 275 Vendor ID 10de Device ID 05e6 Adapter RAM 896 Adapter Drivers snvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Driver Version 8.17.12.5896 Driver Date 7-9-2010 Direct2D Enabled true DirectWrite Enabled true

Problem still exists in Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100925 Firefox/4.0b7pre. Adapter Description NVIDIA GeForce GTX 260 Vendor ID 10de Device ID 05e2 Adapter RAM 896 Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Driver Version 8.17.12.5896 Driver Date 7-9-2010 Direct2D Enabled true DirectWrite Enabled true GPU Accelerated Windows 1/1 Direct3D 9

The screenshots look like Cleartype Quality is disabled on the systems that are showing this bug, correct?

Yes, this is correct for mine.

So the cause of this issue is that although we've updated the rendering code to use the lower quality setting for people who have that in their system settings. The glyph placement code is still using high quality settings. Because the low quality rendering setting will force glyphs to be placed on pixel aligned positions, this doesn't work well together. This is a known bug and will be fixed at some point before release.

OK, so can you set the bug to NEW or mark it as a duplicate of the bug you refer to?

Let's keep it as new for now. I'm not sure if a bug was ever created. If someone else knows of one please dupe.

I think that we need Harfbuzz to know that we're rasterizing without AA.

Harfbuzz also affects some letters of the chrome font Segoe UI even with ClearType enabled. The screenshot shows different kerning of the letter "y" with Harfbuzz on/off. D2D/DirectWrite is disabled. Disabling D3D layers does not make any difference. UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101009 Firefox/4.0b8pre Graphics info: Adapter Description: NVIDIA GeForce Go 7400 Vendor ID: 10de Device ID: 01d8 Adapter RAM: 128 Adapter Drivers: nvd3dum,nvd3dumx nvwgf2um,nvwgf2umx Driver Version: 7.15.11.6904 Driver Date: 10-28-2007 Direct2D Enabled: false DirectWrite Enabled: false GPU Accelerated Windows: 1/1 Direct3D 9

Joe Drew: is this bug causing the text in the Firefox button to slightly change on hover? I want to make sure we are tracking that.

The bug tracking that is bug 613696.

This (594889) bug: http://zgf1.e-net24.pl/screensender/img/img_4011596.png http://zgf1.e-net24.pl/screensender/img/img_4117115.png ATI Radeon 4850, Windows 7 64 bit, ClearType - Disabled, D2D - On.

In my testing, this greatly improves the appearance of non-ClearType text. (Note that after changing the system's font smoothing setting to enable or disable ClearType, you need to restart the browser to see the effect.)

When will the patch be generally available? Will it arrive in the nightlies?

There should be a tryserver build available at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jkew@mozilla.com-ee6f7b9e348d in a couple of hours or so. As for any patch, whether/when it will appear in nightlies depends on review, and any further work that we decide is necessary before it goes into the tree.

Comment on attachment 500882 [details] [diff] [review] patch v1 - use hinted widths when ClearType is turned off I can't say all this extra code makes me superhappy! But it looks like it should do the trick to me. Just one comment: +static bool +UsingClearType() +{ + BOOL fontSmoothing; + UINT type; + + return (SystemParametersInfo(SPI_GETFONTSMOOTHING, 0, &fontSmoothing, 0) && + fontSmoothing && + HasClearType() && + SystemParametersInfo(SPI_GETFONTSMOOTHINGTYPE, 0, &type, 0) && + type == FE_FONTSMOOTHINGCLEARTYPE); +} I can live with this, but personally I'd rather see this split out in several conditionals that each do an early return. In optimized builds this will be optimized to the same code anyway, and in debug builds it actually makes debugging issues a little easier. And it looks nicer.

Split up the conditional as requested. Requesting re-review because I have also added an equivalent fix in gfxDWriteShaper, for those scripts that we don't send through harfbuzz. (The effect can also be seen in Latin script by setting gfx.font_rendering.harfbuzz.level = 0.) By using "GDI compatible" placement when ClearType is turned off, we get much better glyph spacing through that path as well.

Still is not ok: http://zgf1.e-net24.pl/screensender/img/img_18742786.png http://zgf1.e-net24.pl/screensender/img/img_18581949.png http://zgf1.e-net24.pl/screensender/img/img_19017613.png Screens from WWW: http://www.devilpage.pl/ http://forum.pclab.pl/ 4.0b9pre (2011-01-05)

The patch as done something and definitely fixed most of it. Not perfect but way better. The image is made with size 8 Tahoma font. Top line is today build, second et yesterday bottom is GDI render There is some issues on the overall spacing, but to be honest, it’s better than having letters touching each-others Additionally I can confirm that there is no more decimal placing of the letter (for testing, on the about:home page resize windows horizontally on look at the text in the centre, before patch; spacing between letter were changing, and now it’s only between words) For zgf1 case there is something strange about the first example, it looks like it’s because of justify in such a small space.

Big problems with the font: 4.0b9pre (2011-01-05): http://zgf1.e-net24.pl/screensender/img/img_4081469.png Internet Explorer 8: http://zgf1.e-net24.pl/screensender/img/img_4108442.png Look at the words: spRZedam, dreamER, booMBo, wgRAne, geMIni... Spacing issues.

The issue with letter spacing occurs mostly after the letter 'm' (low caps) Firefox4 ct off, d2d on: http://zgf1.e-net24.pl/screensender/img/img_25752785.png Firefox4 ct off, d2d off: http://zgf1.e-net24.pl/screensender/img/img_25798368.png WWW: http://sport.onet.pl/boks/adamek-o-walce-z-kliczka-tak-robia-prawdziwi-wojow,1,4099489,wiadomosc.html

I was going to reopen this bug on the basis of the screenshots still showing poor spacing, but I see you've filed a new bug 623974, so we'll follow up there.