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.
(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.
(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.
Yeah, fixing the matching sounds reasonable to me.
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.
(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.
(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.
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?
Done in git for FT_Load_Sfnt_Table(). but not yet for score of missing built-in objects.
(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.
Fedora is applying this patch to fix this: http://pkgs.fedoraproject.org/cgit/fontconfig.git/plain/fontconfig-fix-woff.patch
(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.
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.
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.
(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.
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.
(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.
Closing. FC_HASH was shortlived. Doesn't exist anymore.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.