Bug 41091 – [GTK] Complex text rendering does not render custom fonts

• Component: Text
• Status: RESOLVED FIXED

[Gustavo Noronha (kov)]

Go to http://www.scribd.com/documents/30964170/Scribd-in-HTML5 - you can see that the text looks weird and out of place. Using the web inspector you should be able to confirm that the fonts were downloaded, which implies webkitgtk decided it should use them, but the actual text is not rendered using them for some reason. Early on, there was a second problem that was causing the fonts to not be downloaded at all. This has been fixed in bug 38758 (https://bugs.webkit.org/show_bug.cgi?id=38758).

[Gustavo Noronha (kov)]

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.

[Gustavo Noronha (kov)]

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.

[Andrei Bucur]

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.

[Gustavo Noronha (kov)]

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 =)

[Andrei Bucur]

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.

[Andrei Bucur]

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?

[Martin Robinson]

This issue seems to be that the complex text path does not render custom fonts at all.

[Martin Robinson]

Created attachment 69283 [details]
Work around for this issue

[Martin Robinson]

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.

[Gustavo Noronha (kov)]

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

[Martin Robinson]

Committed r69117: <http://trac.webkit.org/changeset/69117>