Hi Akira, How is the result parameter of FcFontSetSort or FcFontSort supposed to be used? And what''s the rationale behind a18ca17b [1] anyway? In which you have: + /* There are some implementation that relying on the result of + * "result" to check if the return value of FcFontSetSort + * is valid or not. + * So we should initialize it to the conservative way since + * this function doesn''t return NULL anymore. + */ + if (result) + *result = FcResultNoMatch; So result is initialized to be FcResultNoMatch in the beginning, but it''s never set to FcResultMatch later! The only reference to result is in the FcCompare() call below that, but that wouldn''t change the value to FcResultMatch in any case. As a result we are stucked with FcResultNoMatch. In Qt, we do use that result to tell if the return value of FcFontSort is valid or not. Using fontconfig 2.9.0 (with this commit) makes Qt having no font fallback list at all: http://qt.gitorious.org/qt/qtbase/blobs/master/src/platformsupport/fontdatabases/fontconfig/qfontconfigdatabase.cpp#line644 - Jiang [1] http://cgit.freedesktop.org/fontconfig/commit/?id=a18ca17b6211f62fbd1d893811b94b8c83db4cc0
On Wed, Mar 21, 2012 at 11:05 PM, Jjgod Jiang <gzjjgod at gmail.com> wrote:> So result is initialized to be FcResultNoMatch in the beginning, > but it''s never set to FcResultMatch later! The only reference to > result is in the FcCompare() call below that, but that wouldn''t > change the value to FcResultMatch in any case. As a result we are > stucked with FcResultNoMatch. > > In Qt, we do use that result to tell if the return value of > FcFontSort is valid or not. Using fontconfig 2.9.0 (with this > commit) makes Qt having no font fallback list at all:In oher words, it was not worth having a look at the ''result'' unless FcTypeResultMismatch is raised in FcCompareValueList(). I could set FcResultMatch at the end of FcFont{Sort,Match} and FcFontSet{Sort,Match} if the return value is valid though. For a workaround, you can do similar thing in fc-match.c where your reference points to. Anyway, thanks for catching this up. -- Akira TAGOH
On Wed, Mar 21, 2012 at 3:38 PM, Akira TAGOH <akira at tagoh.org> wrote:> On Wed, Mar 21, 2012 at 11:05 PM, Jjgod Jiang <gzjjgod at gmail.com> wrote: >> So result is initialized to be FcResultNoMatch in the beginning, >> but it''s never set to FcResultMatch later! The only reference to >> result is in the FcCompare() call below that, but that wouldn''t >> change the value to FcResultMatch in any case. As a result we are >> stucked with FcResultNoMatch. >> >> In Qt, we do use that result to tell if the return value of >> FcFontSort is valid or not. Using fontconfig 2.9.0 (with this >> commit) makes Qt having no font fallback list at all: > > In oher words, it was not worth having a look at the ''result'' unless > FcTypeResultMismatch is raised in FcCompareValueList(). I could set > FcResultMatch at the end of FcFont{Sort,Match} and > FcFontSet{Sort,Match} if the return value is valid though.I will change Qt to check for FcTypeResultMismatch then. But I think setting FcResultMatch at the end of FcFontSort is a good idea. FcFontSetMatch already did it. - Jiang
On Thu, Mar 22, 2012 at 2:22 AM, Jjgod Jiang <gzjjgod at gmail.com> wrote:> I will change Qt to check for FcTypeResultMismatch then. But I think > setting FcResultMatch at the end of FcFontSort is a good idea. > FcFontSetMatch already did it. > > - JiangThat should works with the last commit now. please check. Regards, -- Akira TAGOH