Keith, > You want me to take a "family" name as provided by the user and attempt to > match it against a full name? I'm not sure that's necessary; these names No. I didn't mean that. I was trying to describe that because in our code we accept both we need to be able to enumerate both so that we can try to match first as a face name and if that fails as a family name. That's application level behaviour (my code). I don't expect, or think it right that fontconfig get into the same predicament of doing this automatically and as you say conflating the two. A clear separation of the two is better. > What I was actually asking was whether you wanted me to permit applications > to supply full names (as an FC_FULLNAME pattern element) and match them > against the full names in the fonts as a separate match from family and > style names. Yes, that's it. FC_FULLNAME is a distinct pattern element -phil. Keith Packard wrote: > Around 22 o'clock on Nov 29, Phil Race wrote: > > >>I have to say yes, since we have succumbed to the same blurring of what >>a name is and are stuck with it. So we have to assume that what ever >>char*/string is given as the name maybe legitimate as one or the other >>and do our best to find it as both before trying anything else. > > > You want me to take a "family" name as provided by the user and attempt to > match it against a full name? I'm not sure that's necessary; these names > come from applications, not users (in general), and I think we need to > expect that application developers can distinguish between the two. > Conflating these in our API seems only to compound an existing problem. > > What I was actually asking was whether you wanted me to permit applications > to supply full names (as an FC_FULLNAME pattern element) and match them > against the full names in the fonts as a separate match from family and > style names. This would allow applications to use full names in place of > family and style names. > > -keith > >
