https://bugs.documentfoundation.org/show_bug.cgi?id=172818
--- Comment #9 from Jonathan Clark <[email protected]> --- (In reply to Y. Kawara from comment #8) > I mean that even with the fontconfig bug, the first result returned by > fontconfig had never changed. Why is LO picking up 3rd result? This is what > I am the most worried about. fontconfig gives LO an arbitrarily-ordered sequence of FC_FAMILY/FC_FAMILYLANG pairs. We don't know anything else about these strings. They aren't prioritized, and fontconfig offers no guarantees about their order (in practice, they seem to be returned in whatever order fontconfig encountered them when it parsed the font file). We scan this sequence and use the first name that matches both the GUI language and country. If there are none, we use the first name that matches the GUI language. If there are still none, we use the first English name as a fallback. In this case, LO is using the corrupted name either because fontconfig arbitrarily put it first in the list, or because fontconfig reports it as a better match (ja-JP vs ja). I think this is a case of "garbage in, garbage out". I'm not familiar with fontconfig's code, so I don't know why it gets a different result. However, I don't think it's too significant. fontconfig is telling us this corrupted string is just as good or better than any other name for this font, and not giving us any other information we could use to rule it out as a candidate. It seems reasonable that our code ends up picking this name. -- You are receiving this mail because: You are the assignee for the bug.
