On Thu, 2006-03-23 at 14:24 +0900, Kenichi Handa wrote: > Hi, thank you for the response. > > In article <[EMAIL PROTECTED]>, Owen Taylor <[EMAIL PROTECTED]> writes: > > > The problem is fontconfig ... since we ask fontconfig > > to "trim" the results when calling FcFontSort(), only one > > Japanese (say) font will be returned. If there is another > > Japanese font further down the list, it won't be returned > > unless it has new characters that the previous fonts don't > > have. > > Yes, I've noticed that problem and also the other problems. > In short, I think we should avoid using FcFontSort. > > > So, I don't think your patch will work out reliably - > > the font with "APPROXIMATE" or "FALLBACK" coverage may > > keep your "EXACT" font from being found at all. > > > On the other hand, if you don't trim the results you'll get > > every single font in the system in the returned list, which > > would be horrible for performance and memory usage. > > But the method used in FcFontSort has some problems > especially in such a case that we want Hindi fonts (several > are available) but there are a huge number of non-Hindi > fonts. > > (1) It calculates scores of many unnecessary non-Hindi > fonts, and sorts all of them. > > (2) To trim it, it also checks charsets of such unnecessary > fonts. > > (3) The trimming algorithm is to check a charset against the > union of all previous fonts. Thus, if one previous font > supports [a b] and another supports [a c], a new font > supporting [b c] is excluded. But, sometimes, what we > want is a font supporting [b c].
If someone really has very particular font requirements, then they probably should just specify them. A user can specify a font of "Palatino,Kochi Mincho" And get exactly that. The more magic we do on font selection, the less likely that the user will understand what's going on. There's a pretty big advantage to being reasonably consistent with the way fontconfig works in other programs. If we invent our own font sorting algorithms, then we lose that advantage. And I definitely don't want to introduce some Pango specific configuration of language-specific fontsets. > > The right thing to do is probably duplicate the trimming code > > from fontconfig and combine it with our own logic ... if you > > look at how trimming is implemented in fontconfig, it's not > > doing anything that we could do ourselves as efficiently. > > That doesn't solve the problem (1) above. But what's the problem in (1) or (2)? A lot of work has been done to try and make that not a performance bottleneck, and it doesn't generally seem to be one. If it works with 1000 Latin fonts, then it should work with 1000 Latin fonts + 5 Hindi fonts. > The way, I can > think of, to avoid the above problems is this (at least for > non English fonts): > > 1. Get a fontset by FcFontList() by LANG pattern. Perhaps > we must add "generic" fonts (for serif, etc; not that > many) to the resulting list. > > 2. Use FcFontSetSort() on it without trimming. > > 3. Ask shaper to select the best one. > > By the way, regardless of modifying Pango along that line or > not, I think the patch I proposed doesn't make the situation > worse. And, even if it's not that reliable now, there > surely exist a case that the patch works. There's a performance penalty from the patch, right? I'm not crazy about slowing down performance to get an inherently unreliable result. > > The other possibility - which could work Graphite and for > > OpenType, but maybe not as well for you - is to get fontconfig > > to sort the returned fonts based on what tables they contain, > > and thus prefer the fonts with silf or GSUB/GPOS tables. > > Which OTF features are required depends on a > script/language. So, to make that work, we need another > callback function in shaper to provide that kind of > information. The above methods (step 1..3) I proposed > doesn't require such a change. If we need to extend the shaper interface, we need to extend the shaper interface. Regards, Owen _______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list