I'm getting a large pile of reftest failures that suggest that the downloadable font mechanism is not working at all for me: REFTEST TEST-UNEXPECTED-FAIL | box-properties/CSS21-t100301.xhtml REFTEST TEST-UNEXPECTED-FAIL | bugs/404149-1.xul REFTEST TEST-UNEXPECTED-FAIL | first-letter/399941-8.html REFTEST TEST-UNEXPECTED-FAIL | font-face/download-2.html REFTEST TEST-UNEXPECTED-FAIL | font-face/name-override-simple-1.html REFTEST TEST-UNEXPECTED-FAIL | font-face/src-list-1.html REFTEST TEST-UNEXPECTED-FAIL | font-face/src-list-2.html REFTEST TEST-UNEXPECTED-FAIL | font-face/src-list-2-big-otf.html REFTEST TEST-UNEXPECTED-FAIL | font-face/src-list-format-1.html REFTEST TEST-UNEXPECTED-FAIL | font-face/src-list-format-2.html REFTEST TEST-UNEXPECTED-FAIL | font-face/src-list-format-3.html REFTEST TEST-UNEXPECTED-FAIL | font-face/src-list-format-4.html REFTEST TEST-UNEXPECTED-FAIL | font-face/src-list-format-5.html REFTEST TEST-UNEXPECTED-FAIL | font-face/src-list-format-6.html REFTEST TEST-UNEXPECTED-FAIL | font-face/src-list-format-7.html REFTEST TEST-UNEXPECTED-FAIL | font-face/multiple-in-family-1.html REFTEST TEST-UNEXPECTED-FAIL | font-face/multiple-in-family-1b.html REFTEST TEST-UNEXPECTED-FAIL | font-face/cross-iframe-1.html REFTEST TEST-UNEXPECTED-FAIL | font-face/sheet-set-base-1.html REFTEST TEST-UNEXPECTED-FAIL | font-face/sheet-set-switch-1.html REFTEST TEST-UNEXPECTED-FAIL | font-face/ahem-metrics-1.html The failures are all like this: in place of one or more characters that should have been taken from a downloadable font, there is the standard Pango fallback symbol (a rectangle with the hexadecimal number of the desired Unicode codepoint inside). This may be related to the changes in bug 478871 but presumably is not a direct consequence (or we'd be seeing failures on the tinderbox). I cannot back that bug out without downgrading GNOME on this computer.

Our code uses PangoFcFontClass::get_glyph from Pango to do character to glyph coversion (for simple characters), but this has changed in Pango-1.24 to use a cache based on file and face index (within the file). Our downloaded fonts don't have a file, so Pango would fail to find a cache entry and give up.

Karl: My pango version (as requested in the other bug) is 1.24.1. I am using Ubuntu Jaunty beta version. So it seems like there's two bugs here: 1) We are doing the wrong thing with Pango 2) When finding the downloaded font fails, we resort to unknown char glyphs rather than the default font. Gerv

(In reply to comment #3) > When finding the downloaded font fails, we resort to unknown char glyphs > rather than the default font. Finding the downloaded font is succeeding, and pango_itemize correctly determines that the font has support for the characters, but pango_shape would fail to find the glyphs for the characters in the font. We override PangoFcFontClass::get_coverage (which is used in determining character support) for downloaded fonts; we should probably override PangoFcFontClass::get_glyph for downloaded fonts (at least) also. (I guess we could try pango_shape with fallback fonts when shaping reports missing glyphs, but this would be inefficient. The two stage process of looking for fonts then shaping, has much more efficient font selection.)

Given we need to have glyph look-up code for downloaded fonts, we might as well use the same code for all fonts, which will work around a problem that FcFreeTypeCharIndex has with some fonts.

The patch eliminates all but one of the reftest failures I'm getting, and the remaining one (first-letter/399941-8.html) does not involve @font-face.

http://hg.mozilla.org/mozilla-central/rev/be51493bb094 This reduced Tp_RSS on talos machines by 1 to 1.5 MB. A saving of about 2 kB per (scaled) PangoFont used (for rendering text) was expected with Pango < 1.24, as the cache is moved from the scaled fonts to their face. (Pango-1.24 has moved the cache similarly.) I guess the talos Tp set uses a large number of PangoFonts.

Blocking, so no approval needed.

I experience bug 490032 with this patch applied.