On Wednesday 15 October 2003 20:34, Keith Packard wrote: > Around 10 o'clock on Oct 15, Lars Knoll wrote: > > The biggest problem we encountered is that we have no way of knowing > > about aliases defined in the fonts.conf files. Reason we need them is > > that we do some font matching ourselves, and matching "serif" would > > always fail since we didn't know this is a valid family name in font > > config. > > There aren't 'aliases' per-se in fontconfig; fontconfig provides only a > mechanism for modifying incoming patterns before matching. > > An important reason for this is a trademark issue. With the core fonts, we > had several font foundaries complain about the aliasing mechanism because > font lists would include trademarked font names not actually present on the > machine, a user selecting those trademarked names would see alternative > fonts presented on the screen. I agree that this is not really desirable. > However, there are standard substitution rules which guarantee to provide > reasonable defaults for three of the CSS2 generic names (sans-serif, serif > and monospace). I suggest simply placing those generic names into all of > your font menus, perhaps separate from the 'real' family names. The problem I have with this approach is what happens if you at some point also choose to offer "fantasy" CSS name (actually the user could do it by editing his own fonts.conf). That would require the user to patch and recompile Qt to get it in the font list. > > The other missing feature are having access to the localized family names > > true type offers. This is especially important for asian people. Also > > here I'd be happy with an additional font property FC_LOCALE_FAMILY I can > > pass into FcFontList to have the localized names included in the pattern. > > Yes, I'd really like to offer this as well. I've been thinking about how > this might work and haven't really found the perfect solution. What I can > do is include all of the names in the FC_FAMILY/FC_STYLE entries and then > provide an API that selects one using an RFC 3066 language tag. The > existing listing API could then default to using the current locale. If possible I'd like to get both names with on FcFontList command. The reason is that I'd like to have a mapping between international and localized name. If I understand you correctly this would be the case with your approach. I'd guess that most fonts have at most two family names. An international and a localized one. In this case, the approach using RFC 3066 language tags is maybe overkill. It would suffice to get them both side by side with an easy API. Lars > If this makes sense, I'd like to give it a try and see if it actually > works. > > -keith
