http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #144 from Aric Stewart aric@codeweavers.com 2012-02-06 19:50:08 CST --- (In reply to comment #142)
@comment 141: Any hardcoded solution may end up being quite annoying for people having their own font preferences.
I'd like to remind you about that gdiplus font rendering bug, that doesn't happen with either native Japanese font, nor the one that codeweavers part of wine dev team uses, but it does with IPAMona, where glyphs get shifted in wine.
Same app fails to pick a decent font (at least in some of the places), if no relevant FontSubstitutes are set up, so automatic solutions don't work all of the time. On the other hand, I don't see wine either using or reimplementing pango (there's enough "fun" with uniscribe).
Microsoft had it just too easy *knowing* which fonts are available.
It is not a hardcoded solution. It is a dynamic solution and the problem is that we have difficulty recognizing the dynamic solution from one hand put in place by the user. Then when we want to regenerate the dynamic solution we end up blowing away anything put in place directly by the user.
I am looking at a middle ground right now. Something where we have the SystemLink that for 99% of the systems will be blank and they we generate our dynamic font links which are added in addition. That should cover all bases.
But, if it is the case that 99% of the user never touch the SystemLink registry and instead having all the configuration being in the font replacements that makes is much easier.