libfontconfig from Gnome3 staging PPA breaks CSS webfonts in firefox

Bug #1177995 reported by Merlin Schumacher
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fontconfig
Invalid
Medium
Ubuntu GNOME
Fix Released
Low
Unassigned
fontconfig (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

When i install he Gnome3 staging PPA the webfont support in Firefox breaks. I only see fallback fonts, but not the correct webfonts downloaded from the server. this happens everywhere.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: libpango1.0-0 1.33.9-0ubuntu1~raring0 [origin: LP-PPA-gnome3-team-gnome3-staging]
ProcVersionSignature: Ubuntu 3.8.0-19.29-generic 3.8.8
Uname: Linux 3.8.0-19-generic x86_64
ApportVersion: 2.9.2-0ubuntu8
Architecture: amd64
Date: Wed May 8 23:50:37 2013
InstallationDate: Installed on 2013-02-01 (96 days ago)
InstallationMedia: Kubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.1)
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: pango1.0
UpgradeStatus: Upgraded to raring on 2013-04-22 (15 days ago)

Related branches

Revision history for this message
In , Akiro (akiro) wrote :

firefox is calling FcFreeTypeQueryFace for webfonts like this:

        pattern =
            (*sQueryFacePtr)(mFace, gfxFontconfigUtils::ToFcChar8(""), 0, NULL);

This fails now because we require the valid filename to generate hash value and if not, simply fails because the matcher behaves wrong if some objects are available or unavailable in the cache.

One idea to support this case is to define constant value and add an invalid hash to the cache?

FWIW FcPatternDel should warn if one is going to delete objects which is in the matcher perhaps.

Revision history for this message
In , Freedesktop (freedesktop) wrote :

(In reply to comment #0)
> firefox is calling FcFreeTypeQueryFace for webfonts like this:
>
> pattern =
> (*sQueryFacePtr)(mFace, gfxFontconfigUtils::ToFcChar8(""), 0,
> NULL);
>
> This fails now because we require the valid filename to generate hash value
> and if not, simply fails because the matcher behaves wrong if some objects
> are available or unavailable in the cache.

In FcFreeTypeQueryFace (as opposed to FcFreeTypeQuery) we should use FT_Load_Sfnt_Table() to get the font data and hash that.

> One idea to support this case is to define constant value and add an invalid
> hash to the cache?
>
> FWIW FcPatternDel should warn if one is going to delete objects which is in
> the matcher perhaps.

Humm. Not sure about that.

The matcher should not fail if something is missing. It should simply not match.

Revision history for this message
In , Akiro (akiro) wrote :

(In reply to comment #1)
> Humm. Not sure about that.
>
> The matcher should not fail if something is missing. It should simply not
> match.

Well, it actually doesn't match. but the problem is, it affects a score differently. if something is missing, the score of that object is 1e99. but if it's there but just not matching, the score of that object is 1000 + n. given that first matched object is lower than that, it won't be selected as the best font due to that "1e99" score.

If a warning is annoying, when the built-in objects are missing, we should take care of it as "not matching" which gives 1000 + n score.

Revision history for this message
In , Freedesktop (freedesktop) wrote :

Yeah, fixing the matching sounds reasonable to me.

Revision history for this message
In , Akiro (akiro) wrote :

Hmm, I'm a bit getting confused now. score are reflected for objects in the matcher only. after the change being suggested in comment#2, we don't see 1e99 score in any objects then. is it really what we are expecting here?

I have to test it carefully to not miss any regressions on this change anyway.

Revision history for this message
In , Akiro (akiro) wrote :

(In reply to comment #1)
> In FcFreeTypeQueryFace (as opposed to FcFreeTypeQuery) we should use
> FT_Load_Sfnt_Table() to get the font data and hash that.

Ah, should I complete freetype related operation in fcfreetype.c? so I may need to create a function to load the font data into the memory then.

Revision history for this message
In , Freedesktop (freedesktop) wrote :

(In reply to comment #5)
> (In reply to comment #1)
> > In FcFreeTypeQueryFace (as opposed to FcFreeTypeQuery) we should use
> > FT_Load_Sfnt_Table() to get the font data and hash that.
>
> Ah, should I complete freetype related operation in fcfreetype.c? so I may
> need to create a function to load the font data into the memory then.

I'm not sure I understand your question.

Revision history for this message
In , Akiro (akiro) wrote :

I mean I did update FcHashGetSHA256DigestFromFile() to FcHashGetSHA256DigestFromFace() with FT_Face and read the font data with FT_Load_Sfnt_Table in it. since it has FT_Face in an argument, fcint.h was required to include freetype headers.

I guess you expected to do it in fcfreetype.c and give the font data to something like FcHashGetSHA256DigestFromMemory() right?

Revision history for this message
In , Akiro (akiro) wrote :

Done in git for FT_Load_Sfnt_Table(). but not yet for score of missing built-in objects.

Revision history for this message
In , Freedesktop (freedesktop) wrote :

(In reply to comment #7)
> I mean I did update FcHashGetSHA256DigestFromFile() to
> FcHashGetSHA256DigestFromFace() with FT_Face and read the font data with
> FT_Load_Sfnt_Table in it. since it has FT_Face in an argument, fcint.h was
> required to include freetype headers.
>
> I guess you expected to do it in fcfreetype.c and give the font data to
> something like FcHashGetSHA256DigestFromMemory() right?

Right. That sounds better.

Revision history for this message
Merlin Schumacher (merlin-schumacher) wrote :
Changed in ubuntu-gnome:
status: New → Invalid
summary: - libpango breaks CSS webfonts in firefox
+ libfontconfig breaks CSS webfonts in firefox
Revision history for this message
Merlin Schumacher (merlin-schumacher) wrote : Re: libfontconfig breaks CSS webfonts in firefox

mixed up pango an fontconfig. sorry.

Changed in ubuntu-gnome:
status: Invalid → New
summary: - libfontconfig breaks CSS webfonts in firefox
+ libfontconfig from Gnome3 staging PPA breaks CSS webfonts in firefox
Revision history for this message
Tim Lunn (darkxst) wrote :

Merlin, Can you attach screenshots demonstrating this issue?

Changed in fontconfig:
importance: Unknown → Medium
status: Unknown → In Progress
Revision history for this message
In , Pacho Ramos (pacho) wrote :
Revision history for this message
In , Dominique-freedesktop-org (dominique-freedesktop-org) wrote :

(In reply to comment #10)
> Fedora is applying this patch to fix this:
> http://pkgs.fedoraproject.org/cgit/fontconfig.git/plain/fontconfig-fix-woff.
> patch

openSUSE copied the Fedora patch for the time-being... and was confirmed to be successful.

Tim Lunn (darkxst)
Changed in ubuntu-gnome:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Jeremy Bícha (jbicha) wrote :

Seb, this is still broken in Saucy. It looks like git_obtain_fonts_via_FT-face.patch isn't listed in debian/patches/series

You can verify whether the fix works or not by visiting a Github page like https://github.com/FreeRDP and checking whether you see weird glyphs like fi next to the repositories in the list.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package fontconfig - 2.10.92-0ubuntu2

---------------
fontconfig (2.10.92-0ubuntu2) saucy; urgency=low

  * debian/patches/series: list the patch from the previous revision...
    (lp: #1177995)
 -- Sebastien Bacher <email address hidden> Fri, 17 May 2013 18:45:26 +0200

Changed in fontconfig (Ubuntu):
status: New → Fix Released
Jeremy Bícha (jbicha)
Changed in ubuntu-gnome:
status: Confirmed → Fix Released
Revision history for this message
Gökçen Eraslan (gkcn) wrote :

After that upgrade I cannot use my terminus fonts anymore. fc-list|grep -i terminus gives nothing. Can someone install xfonts-terminus package and check?

Revision history for this message
In , Nfxjfg (nfxjfg) wrote :

It would be appreciated if a new release with the fix included could be made. In fact, you should have reverted the new feature (which barely anyone needs), and made a fixup release, instead of letting the broken version further spread, making distros patch it, and bother everyone with explaining and tracking down this bug.

Revision history for this message
In , Akiro (akiro) wrote :

Well, the problem being related to web fonts has been already fixed. no need to revert features at all. I'm keeping this open because I want to have a new logic or API for web fonts rather than relying on undocumented/unintentional behavior.

Revision history for this message
In , Freedesktop (freedesktop) wrote :

(In reply to comment #13)
> Well, the problem being related to web fonts has been already fixed. no need
> to revert features at all. I'm keeping this open because I want to have a
> new logic or API for web fonts rather than relying on
> undocumented/unintentional behavior.

What kind of logic do you have in mind? I don't think we need to do anything.

Revision history for this message
In , Akiro (akiro) wrote :

Were you suggesting to use FT_Stream instead? other than that, giving an empty string as a filename to deal with an on-memory font looks not good to me at least though.

Revision history for this message
In , Freedesktop (freedesktop) wrote :

(In reply to comment #15)
> Were you suggesting to use FT_Stream instead? other than that, giving an
> empty string as a filename to deal with an on-memory font looks not good to
> me at least though.

Yes, I think using FT_Stream is more robust than what we have right now.

Revision history for this message
In , Freedesktop (freedesktop) wrote :

Closing. FC_HASH was shortlived. Doesn't exist anymore.

Changed in fontconfig:
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.