Around 11 o'clock on Oct 17, Owen Taylor wrote: > I think FC_FAMILY should be restricted to being the ASCII-only name > as currently, and if you want a all-localized-font names, that should > be a separate property. Let's hold that thought; it's difficult to imagine how the current matching semantics can be cleanly extended to do reasonable things with family names split across two properties. > 1) FcPatternGetString (pattern, FC_FAMILY, 0, &s) must return the > programmatic name > > 2) Passing the programmatic name to FcFontSetList as FC_FAMILY > must continue to match that font Both of these would continue to be true if the FC_FAMILY contained all of the names for the font. The first would be true if we carefully placed the 'programmatic' (aka English) name first in the list. The second would be true even if the programmatic name was placed in some random order. > But I think even adding the localized names to FC_FAMILY in some > way that preserves those two invariants is likely to cause > breakage for existing programs. I don't see how this could break existing applications if we take a bit of care. I think the key effect will be on the font listing APIs, and for those, I suggest that the localizable entries be trimmed to include only a single entry. I'd like that entry to be a localized name, but could be convinced that a separate API should be used and that the existing API return only programmatic names. -keith
