Closed Bug 627840 Opened 9 years ago Closed 9 years ago
Write: text spacing busted for 12px and 13px Calibri
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
This is what I see with my Tb build.
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.
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.
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.
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.
Assignee: nobody → jfkthame
Attachment #506111 - Flags: review?(masayuki)
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.
Attachment #506111 - Flags: review?(masayuki) → review+
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.
Attachment #506111 - Flags: approval2.0?
Attachment #506111 - Flags: approval2.0? → approval2.0+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.