Bug 107246 - FcFontList "contain" semantics unproductive
Summary: FcFontList "contain" semantics unproductive
Status: RESOLVED MOVED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: fontconfig-bugs
QA Contact: Behdad Esfahbod
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-16 12:04 UTC by Behdad Esfahbod
Modified: 2018-08-20 21:43 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Behdad Esfahbod 2018-07-16 12:04:38 UTC
If I want to list only fonts that have fontformat=TrueType or fontformat=CFF, currently I can't:

behdad:~ 0$ fc-list :fontformat=truetype,cff

Returns empty.

This is because FcFontList interprets that as returning fonts that have both fontformat=truetype AND fontformat=cff.  Code:

/*
 * Font must have a containing value for every value in the pattern
 */
static FcBool
FcListValueListMatchAny (FcValueListPtr patOrig,            /* pattern */
                         FcValueListPtr fntOrig)            /* font */
{
    FcValueListPtr       pat, fnt;

    for (pat = patOrig; pat != NULL; pat = FcValueListNext(pat))
    {
        for (fnt = fntOrig; fnt != NULL; fnt = FcValueListNext(fnt))
        {
            /*
             * make sure the font 'contains' the pattern.
             * (OpListing is OpContains except for strings
             *  where it requires an exact match)
             */
            if (FcConfigCompareValue (&fnt->value,
                                      FC_OP (FcOpListing, FcOpFlagIgnoreBlanks),
                                      &pat->value))
                break;
        }
        if (fnt == NULL)
            return FcFalse;
    }
    return FcTrue;
}

I cannot imagine any scenario that this semantic is useful.  I suggest we flip it from an AND to an OR.
Comment 1 Akira TAGOH 2018-07-18 07:58:12 UTC
What ops is preferred may depends on the context and property. I suppose OR op may be preferred for the unique value in a property like family. but both AND and OR might be for bitwise property like charset/lang. most properties has unique value. in this sense we could change the behavior but obvious syntax would needs to be added for AND.
Comment 2 Behdad Esfahbod 2018-07-23 18:14:47 UTC
(In reply to Akira TAGOH from comment #1)
> What ops is preferred may depends on the context and property. I suppose OR
> op may be preferred for the unique value in a property like family. but both
> AND and OR might be for bitwise property like charset/lang. most properties
> has unique value. in this sense we could change the behavior but obvious
> syntax would needs to be added for AND.

Both charset and lang keep multiple values in same element.  The caller can create a charset/lang and add everything they want into it if AND is needed...  I think just changing the behavior is fine to be honest.
Comment 3 GitLab Migration User 2018-08-20 21:43:19 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/5.


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.