On Fri, 2006-01-13 at 09:57 -0800, Jay Hobson wrote: > I've done some more digging on this, and I think that this code > has some real problems. > > The values contained in nodeps[f]->score[MATCH_LANG_INDEX] > are going to be: > > 0 if it was an exact match for the language > 100 if it was a language match, but possible country missmatch > 200 if it was not a match at all. > > (The values returned from FcCompareLang are indeed 0, 1, or 2, > but these are multiplied by 100 before entered into score) > > This code always does exact matches only up until the number > of languages requested for the set is above 100. (not realistic, > but comparing score to number of languages requested seems > odd anyway) > > The basic problem with the entire loop is that if there are no > exact matches, as would be the case with ja_JP locale, then > all of the fonts are rescored to an equally bad 1000 by this > code, and fonts that don't even support the language are being > set as first priority. Did you look in the CVS history and try to understand why the code is as it is today? I'm reasonably sure it works as it does for a reason, but it certainly isn't obvious to either of us today what precisely that is. I'm afraid I don't have time until February to really examine this issue in the detail that it requires. -- keith.packard@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
