On Fri, 2003-07-11 at 16:54, Keith Packard wrote: > LISTING FONTS > > When listing fonts, contains should have "obvious" semantics, I suggest > that those semantics depend on the type of the value: > > string, number, boolean: > > font has an equal value for every value in the pattern. This means > that using 'times,courier' for the family will result in no fonts > being listed as no font has both times and courier family names. In fact, I > can't see a good use for multiple values here as it would require multiple > values in the fonts; let's see if that is broken. For strings, the change > here is that 'contains' does not mean sub string -- list 'courier' and you > won't see 'courier 10 pitch'. I think strings should be treated as atomic > values in this context; fontconfig doesn't have string operators, which > is at least consistent. What you are saying in this mail generally makes sense, but when I get down to details I get a little confused, especially about the interpretation of multiple values - when a key is referred to as having the value "foo,bar", there are three possible interpretations of that: * A string containing an embedded comma * A pattern with multiple values with the same key * A pattern with a single value with a composite type (LangSet) When reading through your mail, I had some trouble figuring out when each of these interpretations was applicable in what context, and in fact, it's not always clear to me in practice using fontconfig either. If I do: fc-list times,courier I assume that the resulting pattern has to FC_FAMILY elements, one for times, and one for courier. But then I don't see how your proposed changes section: > 1) Use a Contains-alike operator for LISTING which does exact > matching for strings, permit Contains for EDITING to do > substring matching Is going to result in going from the current result: List both fonts with a family of Times and those with a family of Courier to the behavior described above. Regards, Owen
