627840 - DirectWrite: text spacing busted for 12px and 13px Calibri

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Rain [:rain1] (inactive)]

Attachment: waterfall demo showing the issue

I've attached a hacked-up waterfall demo to show this. The 12px and 13px versions of Calibri look particularly bad.

I can't reproduce this with the latest Firefox nightly, but can do so with a custom build of Thunderbird built with a rev that's a bit later.

Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8d52e3b68ca6&tochange=64c7b8b4e046

Comment 1

[Rain [:rain1] (inactive)]

Attachment: screenshot

This is what I see with my Tb build.

Comment 2

[Jonathan Kew [:jfkthame]]

Looks like this is caused by bug 574907. I notice that Calibri includes embedded bitmap tables, which means that for the sizes where bitmaps are present, we will prevent the use of subpixel positioning, because this can give bad results with bitmap glyphs that can't actually be rendered using subpixel AA.

In the case of Calibri, there are bitmap strikes for sizes 12, 13, 15, 16, 17 and 19 ppem, so these are the sizes that will be affected. However, DirectWrite does not seem to actually be using the bitmaps, and so you're seeing antialiased outline glyphs rendered with spacing that would suit aliased bitmaps. :(

FWIW, I see similar spacing if I use Calibri in WordPad; e.g. the 9pt size (which would correspond to 12px) looks particularly bad.

I wish we knew how to tell whether DirectWrite is actually going to use the bitmaps that are present in these fonts.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

http://blogs.msdn.com/b/text/archive/2009/08/24/wpf-4-0-text-stack-improvements.aspx

See the East Asian Text section and some comments:

http://blogs.msdn.com/b/text/archive/2009/08/24/wpf-4-0-text-stack-improvements.aspx#9914803
http://blogs.msdn.com/b/text/archive/2009/08/24/wpf-4-0-text-stack-improvements.aspx#9922165
http://blogs.msdn.com/b/text/archive/2009/08/24/wpf-4-0-text-stack-improvements.aspx#9922485

Seems that DW might have hard-coded blacklist but it's not by names.

Comment 4

[Jonathan Kew [:jfkthame]]

Thanks, Masayuki-san; that's an interesting post (although it still doesn't really tell us everything.....)

One idea I had to mitigate this problem is to check whether the font supports the CJK unicode blocks, and/or CJK codepages, and only do the bitmap-check in this case. Then there shouldn't be any negative impact on non-CJK fonts that happen to include bitmaps, such as Calibri.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: patch, only check for bitmaps in CJK fonts

The idea here is to restrict the special handling of fonts with embedded bitmaps to CJK fonts only, by checking the codepage bits in the OS/2 table. This should allow us to keep the improvement in bug 574907 for CJK fonts, without regressing the rendering of Calibri and others like it, as it appears that DirectWrite only uses the embedded bitmaps (sometimes!) for CJK fonts.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

Comment on attachment 506111 [details] [diff] [review]
patch, only check for bitmaps in CJK fonts

This patch doesn't work with "ＪＳゴシック" and "ＪＳＰゴシック" due to the font's code page range is just zero. However, they are hardly used on web pages.

If we need to check whether a font is for CJK or not, we should check some glyphs directly. But I do NOT think that we should do so.

Comment 7

[Jonathan Kew [:jfkthame]]

Comment on attachment 506111 [details] [diff] [review]
patch, only check for bitmaps in CJK fonts

Requesting approval-2.0 (or possibly this should be a soft-blocker, as it causes a visual regression for a fairly common font on Windows). The patch should be safe; it doesn't introduce new behavior - in effect it just limits the application of the patch in bug 574907 to make it more conservative, restoring the previous behavior for non-CJK fonts.

Comment 8

[Jonathan Kew [:jfkthame]]

http://hg.mozilla.org/mozilla-central/rev/c93381b53df3