Around 11 o'clock on Jul 12, Owen Taylor wrote: > 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) and the winner is 2) -- foo,bar represents a pattern with multiple values for the same key. LangSets and Charsets were designed to be a more compact representation of this idea for those specific kinds of values; I think there are some places where the fact that they are stored in a single entry are exposed to the user and I'd like to close those holes. > If I do: > > fc-list times,courier > > I assume that the resulting pattern has two FC_FAMILY elements, one > for times, and one for courier. yes, that's correct -- commas separate multiple values with the same key. > 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 > > (will result in a change ...) to the behavior described above. I think I missed a step -- LISTING will require matches for all values of each key, so $ fc-list times,courier will list only fonts with *both* family times and family courier (i.e. no fonts at all). Yes, this is useless, but I want to make sure the meaning of $ fc-list :lang=en,de means to list only fonts with *both* english and german support. Having different meanings for different keys seems like a really bad idea, worse than defining the behaviour of 'fc-list times,courier' as useless. Thanks for reading through this stuff; I'm hoping to get a chance to write down a specification for the library semantics from this discussion. -keith
