Bug 112

Summary: Unavailable foundry prefers fonts without any foundry value
Product: fontconfig Reporter: Keith Packard <keithp>
Component: libraryAssignee: Keith Packard <keithp>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high    
Version: 2.2   
Hardware: x86 (IA32)   
OS: Linux (All)   
i915 platform: i915 features:

Description Keith Packard 2003-09-07 12:58:06 UTC
A pattern including a foundry which isn't present in the configuration ends up
preferring fonts which have no known foundry set rather than a font which
otherwise matches the pattern.

$ fc-match courier:foundry=adobe
FreeMono.ttf: "FreeMono" "Medium"
$ fc-match courier
cour.pfa: "Courier" "Regular"

(the last font has foundry "ibm" on my machine)
This seems wrong to me; but of course 'courier' is a special case as many 
foundries supply a font with that family name.

The question boils down to the precedence among the matching values, we 
placed FC_FOUNDRY ahead of FC_FAMILY before the weak/strong value 
distinction was created.

Can anyone think of a scenario where the foundry name would be more 
important than the family name?  Moving the foundry below the weak family 
binding solves this problem nicely.
Comment 1 Keith Packard 2004-12-04 09:10:07 UTC
Current CVS assigns foundry "unknown" when fontconfig can't figure out what else
to use.  This makes all foundry matches (or mis-matches, in this case), equal
and thus falls back on the family name to select the target font.

However, when I do courier:foundry=adobe, I get Utopia as that does come from
Adobe.  When I do courier:foundry=xyzzy, I get the IBM version of courier.

The reason 'foundry' was added in the first place was for applications needing
to use a specific foundry's font mapping, in which case the foundry is indeed
more important than the family name.

Note that 'courier' is about the only family name which comes from multiple
foundries, and so this particular case is somewhat unusual.

I think this is (now) "NOTABUG"; please reopen with more explanation if you feel

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.