594906 - bitmap or vector .fon fonts are not supported with Hardware Acceleration enabled

Status: NEW

(Core :: Graphics, defect)

Description

[emekaekeledo]

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

Whenever hardware acceleration is enabled in Firefox 4.0 Beta 5 (or any of the Minefield builds from the last several weeks that also feature HW Acceleration), the font of the menus, tabs, and other UI elements completely changes from the default system font to one that is barely readable, as can be seen in this picture: http://www.definehypothesis.com/firefox-font-problem.jpg

Reproducible: Always

Steps to Reproduce:
1. Open up Firefox
2.
3.
Actual Results:  
UI fonts are messed up.

Expected Results:  
Expected UI fonts to be messed up.

See image at http://www.definehypothesis.com/firefox-font-problem.jpg for a better explanation.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Please post your Graphics Info from about:support.

Comment 2

[emekaekeledo]

(In reply to comment #1)
> Please post your Graphics Info from about:support.

Note, right now I am running with HW Acceleration turned off so that I can have normal fonts.

From about:support

Graphics

Adapter Description: ATI Radeon HD 5900 Series      

Vendor ID: 1002      

Device ID: 689c

Adapter RAM: 1024

Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

Driver Version: 8.762.0.0

Driver Date: 8-3-2010

Direct2D Enabled: false

DirectWrite Enabled: false

Comment 3

[Joe Drew (not getting mail)]

What font are you trying to use in Firefox? And do you know what font is being chosen?

Comment 4

[emekaekeledo]

(In reply to comment #3)
> What font are you trying to use in Firefox? And do you know what font is being
> chosen?

The font I am using is called Kroeger 05_55 and it is a system-wide font that is part of a custom Windows theme. I'm not sure what font is actually displayed though when hardware acceleration is enabled, but it is clearly not the Kroeger font. To make sure that this wasn't just a problem with the custom Kroeger font, I used the default Windows Aero theme rather than my custom Windows theme and was still able to replicate the bug, so I don't think it has anything to do with a specific font.

Comment 5

[Scoobidiver (away)]

Can you provide screenshots of the font issue with and without HW acceleration ?

Comment 6

[emekaekeledo]

(In reply to comment #5)
> Can you provide screenshots of the font issue with and without HW acceleration
> ?

I included a screenshot when I first posted this bug on 09/09 in the 'URL' field above. The screenshot is: http://www.definehypothesis.com/firefox-font-problem.jpg

Notice how with HW Acceleration enabled, the tab font, the menu font, the url bar, search bar, 'licensing information' text and generally all elements of the UI render in some weird bolded font, whereas when HW Acceleration is disabled, everything renders in the correct tiny pixel font (which is my system-wide font)

Comment 7

[Scoobidiver (away)]

Can you search in your Windows font directory which font matches the one of Firefox with HW acceleration ?
Then provide a screenshot of Windows font directory with the font you found and the Kroeger 05_55

If you set your default system-wide font to Arial, do you see a difference in the UI font between HW accel enabled and disabled ?

Comment 8

[emekaekeledo]

(In reply to comment #7)
> Can you search in your Windows font directory which font matches the one of
> Firefox with HW acceleration ?
> Then provide a screenshot of Windows font directory with the font you found and
> the Kroeger 05_55
> 
> If you set your default system-wide font to Arial, do you see a difference in
> the UI font between HW accel enabled and disabled ?

Okay, so now this is odd. As of the 09/30 nightly, if I set the system theme to the default Windows 7 Aero theme (which has the default system-wide font of Segoe UI), hardware accleration works perfectly. However, this was not the case at the time when I posted this bug (back on minefield 4.0b5). Hmm, so it might actually be a theme problem now where it wasn't before. I'll look further into this. Thanks

Comment 9

[emekaekeledo]

Okay everyone, I've fixed this on my end and now have hardware acceleration working perfectly with my custom system-wide font. I can't speak for those other people who mentioned that they had this problem ( see e.g.: http://support.mozilla.com/oc/questions/751388 ) but I fixed this by switching from the .fon version of my custom font, to the .ttf truetype version of the font in the Windows theme. I hope this bug didn't waste anyone's time, but I still see that other people are having it -- in the link above for example -- but I'm not sure if they are using a non-default Windows font.

Comment 10

[Jonathan Kew [:jfkthame]]

So I think the real issue here is that .fon (bitmap) fonts don't work with HW acceleration.

From a quick look at the DWrite font code, it seems like it only supports sfnt (TrueType & OpenType) fonts, and will fail to use other font types. In contrast, the GDI font code has an alternate code path that supports non-sfnt fonts (e.g. see GDIFontEntry::TestCharacterMap()). We should probably do something similar under DWrite.

Comment 11

[Jonathan Kew [:jfkthame]]

So the real issue is that DirectWrite simply doesn't support .fon fonts (or "legacy" Postscript fonts in .pfb format, incidentally). See the section on Supported Font Formats at http://blogs.msdn.com/b/text/archive/2009/04/13/directwrite-questions-and-answers.aspx, for example.

Therefore, if you have such fonts installed, and configure your Windows theme to use them, we'll fail to find the font you requested and fall back to some other (probably undesirable) font when drawing UI elements.

Comment 12

[John Daggett (:jtd)]

I think the title here is misleading, TrueType fonts with bitmap tables *do* work with DirectWrite (albiet with some problems).

Comment 13

[Jonathan Kew [:jfkthame]]

If your theme calls for a .fon font, it won't be found in the list of available fonts when HW accel is enabled (and therefore we're using DirectWrite). This will lead to gfxDWriteFontList::GetDefaultFont() returning NULL (which is not really supposed to happen, and triggers an assertion in debug builds); as a last resort to avoid crashing the code in gfxFontGroup::BuildFontList will then just use the first valid font it finds in the list of available font families.

This can be demonstrated by using the Window Color and Appearance dialog to choose Courier (not Courier New!) as the font for all UI text; when HW accel is enabled, Minefield will not draw these elements with Courier but with whatever font it finds - looks like Arial in my case, but this may depend on what's installed. On the other hand, if you choose Courier New everything appears as expected.

Comment 14

[Jonathan Kew [:jfkthame]]

(In reply to comment #12)
> I think the title here is misleading, TrueType fonts with bitmap tables *do*
> work with DirectWrite (albiet with some problems).

TrueType fonts with bitmaps are not ".fon fonts".

Comment 15

[Jonathan Kew [:jfkthame]]

Attachment: patch - use Segoe UI as a last-resort default font

We can't really "fix" this issue, as DWrite simply doesn't support those fonts. So if the user's theme calls for a font that isn't supported, there's no way we can respect that choice.

However, I think we should try to avoid the situation where GetDefaultFont() returns NULL and we end up simply picking the first usable font in the family list. Besides the fact that it may be a completely inappropriate font for the UI elements, it could also change at any time if the user installs or removes fonts, even though they're not making any changes to their theme.

I suggest patching gfxDWriteFontList::GetDefaultFont() so that rather than returning NULL if the default specified by the theme isn't found, we try returning Segoe UI. It's not what the user wanted, but at least it's a reasonable, predictable result and should always be available, I believe.

Comment 16

[Jonathan Kew [:jfkthame]]

Attachment: patch - use Segoe UI as a last-resort default font

Oops, attached a stale version of the patch, sorry. This one should be correct.

Comment 17

[John Daggett (:jtd)]

Comment on attachment 480918 [details] [diff] [review]
patch - use Segoe UI as a last-resort default font

The logic as to why this solves the problem is not completely clear to
me.  I'm assuming that the dwrite font list code simply avoids .fon
fonts and so ResolveFontName will fail to find a family for these fonts. If so, I
think a comment would help here.  It's a bit odd not to find the font
that the OS is declaring is the default font!

Comment 18

[Jonathan Kew [:jfkthame]]

(In reply to comment #17)
> Comment on attachment 480918 [details] [diff] [review]
> patch - use Segoe UI as a last-resort default font
> 
> The logic as to why this solves the problem is not completely clear to
> me.  I'm assuming that the dwrite font list code simply avoids .fon
> fonts and so ResolveFontName will fail to find a family for these fonts. 

Right, they just don't appear at all in the dwrite font collection.

> If so,
> I
> think a comment would help here.  It's a bit odd not to find the font
> that the OS is declaring is the default font!

True. I'll add a comment. It's a result of the fact that dwrite does not support all the same font formats as GDI. But the theme is (presumably) GDI-based. Therefore, the theme may call for any font GDI knows about, but dwrite may not support them.