Hide Forgot
Firefox in Fedora 19, webfonts no longer work. https://www.google.com/fonts/ is a good testcase. firefox-19.0.2-2.fc19.x86_64 fontconfig-2.10.92-1.fc19.x86_64 fontconfig-2.10.92-1.fc19.i686 xulrunner-19.0.2-4.fc19.x86_64 gtk2-2.24.17-1.fc19.x86_64 gtk2-2.24.17-1.fc19.i686
This is still a problem with firefox-20.0-1.fc19.x86_64 I downgraded fontconfig to the f18 version using rpm -Uhv --nodeps --oldpackage and it appears that the issue is not present when using f18's fontconfig. So I can confirm the following: Webfonts work with fontconfig equal or lesser than fontconfig-2.10.2-2.fc18 Webfonts do not work with fontconfig fontconfig-2.10.92-2.fc19 or fontconfig-2.10.92-1.fc19.x86_64 Status of versions in between these two and the exact cause of the problem is still unknown. Moving to fontconfig. This bug causes me difficulties in doing my work, since as a web developer web fonts are an important resource and tool.
This seems causing by http://cgit.freedesktop.org/fontconfig/commit/?id=95af7447dba7c54ed162b667c0bb2ea6500e8f32 and now "hash" object has to be available in the cache anyway otherwise the matcher won't works as expected. due to this, FcFreeTypeQueryFace() from firefox is failing because they give "" as a filename and fontconfig requires the valid filename to generate "hash". As they know what they do, it can be worked around in firefox too. FWIW FC_FILE is in the matcher now, removing FC_FILE from the pattern (in gfsDownloadedFcFontEntry::InitPattern at gfx/thebes/gfxPangoFonts.cpp say) may causes unexpected result.
Reported upstream https://bugzilla.mozilla.org/show_bug.cgi?id=857922
quoting from upstream bug, >According to fontconfig docs it doesn't look as though the filename should be required here, if we don't care about it being available as a pattern element. Indeed, with a downloaded font, there *is* no filename - the font data associated with the FT_Face exists only in RAM, it is not stored in a file. > >So this looks to me like a breaking change in the semantics of the fontconfig API. :( Akira, can you please comment about this upstream? What should be the required course of action when the font is not stored in a file?
Well, you were just relying on the undocumented behavior. it didn't even mention whether giving an empty string as file is acceptable or not. that said I'm working on supporting such case in fontconfig now.
moving back to fontconfig for hash issue but you may still see another issue with regard to removing FC_FILE from the pattern.
fontconfig-2.10.92-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/fontconfig-2.10.92-3.fc19
Package fontconfig-2.10.92-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fontconfig-2.10.92-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5401/fontconfig-2.10.92-3.fc19 then log in and leave karma (feedback).
fontconfig-2.10.92-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.