Summary: | [GTK] Complex text rendering does not render custom fonts | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Gustavo Noronha (kov) <gustavo> | ||||||||
Component: | Text | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | abucur, krit, mrobinson, xan.lopez | ||||||||
Priority: | P2 | Keywords: | Cairo, Gtk | ||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | PC | ||||||||||
OS: | OS X 10.5 | ||||||||||
URL: | http://www.scribd.com/documents/30964170/Scribd-in-HTML5 | ||||||||||
Attachments: |
|
Description
Gustavo Noronha (kov)
2010-06-23 11:55:09 PDT
Additional information: @font-face works in general. You can see they working here, for instance: http://www.opentype.info/demo/webfontdemo.html There is something about the way scribd uses web fonts that is causing them to not work, and I could not find out what. Created attachment 60794 [details]
test case
I was finally able to reduce this! I feel dumb for not trying this earlier. The problem seems to be setting a size for the font. In the HTML I am attaching, provided that you have WebKitGTK+ trunk you will notice that the font is actually downloaded, but you get a standard non-serif font rendered. If you comment out/remove the font-size line in the style definition, then you get the custom font face. The size you use doesn't seem to matter.
Maybe we will need to open a new bug but there is a problem with the patch submitted at https://bugs.webkit.org/show_bug.cgi?id=38758. There is a special case where the web fonts are not loaded properly (I will soon attach an example). Imagine there is a @font-face rule like this one: @font-face { font-family: "Test Font"; src: local(X), url(Y); } with X invalid and Y valid. When trying to use the font with a rule like this: body { font-family: "Test Font", sans; font-size: 50 }. The result is that the font used is not the one specified at Y, which is wrong. The problem is the patch looks at the font description structure and sees that the font has a type different from NoFamily so it asks fontconfig to retrieve a font that matches X and fontconfig always returns something non null. I believe you might be mistaken. The original patch (https://bugs.webkit.org/attachment.cgi?id=57542&action=review) was intended to solve precisely the problem you are describing. It does no matching, it uses FcFontList so that it won't return a positive if X is invalid. I wrote that patch because Scribd was using the pattern you describe: they had a @font-face { font-family: "Blah"; src: local(â), url(http://scribd.com/somefont.ttf); }, and our cache always said 'here it is' for "â". After landing the patch that makes the listing less strict I tried scribd and made sure â was not getting a hit, and the web fonts were still being downloaded. Let's see that test case, though, because it may help us figure out what is broken with scribd, or if I'm the one who's mistaken =) Created attachment 66877 [details] File testing @font-face fallback mechanism The text should be rendered using the custom font "Lobster" (http://code.google.com/webfonts/family?family=Lobster#code). Instead it's rendered using monopace. As I said, the problem is with this code snippet in FontCache: fontDescription.genericFamily() != FontDescription::NoFamily In the test case I specify the generic family "monospace" so FontDescription.genericFamily() will not return FontDescription::NoFamily. If someone could explain what's the use of the generic family field in that structure it would be great. I can see that WebKit already injects artificial families called "-webkit-X" (with X monospace, sans etc.) that can be used by the fallback mechanism. Why should we care about what fontDescription.genericFamily() returns? This issue seems to be that the complex text path does not render custom fonts at all. Created attachment 69283 [details]
Work around for this issue
I've uploaded a work-around for this issue. It's not a true fix as we need to support custom fonts on the complex text code path, but it corrects the Scribd rendering. A real fix, as I see it, will fall into one of two categories: 1. Share the HarfBuzz complex text code with Chromium Linux. 2. Subclass enough of the Pango machinary that we can have it use custom fonts. it's unclear to me right now which of those is better, but according to Behdad, we should be using HarfBuzz directly when it is ready. Comment on attachment 69283 [details] Work around for this issue View in context: https://bugs.webkit.org/attachment.cgi?id=69283&action=review Guess that does it for now, thanks for investigating! > LayoutTests/platform/gtk/fonts/font-face-with-complex-text.html:17 > +<p>This text should be appear as a series of blocks:</p> > +<p style="font-family: webkit-ahem;">A B C D E F G H I J K L M N O P Q R S T U V X Y Z</p> Should be appear -> Should appear Committed r69117: <http://trac.webkit.org/changeset/69117> |