http://bugs.winehq.org/show_bug.cgi?id=10583
Erik Johnson junk1112@new.rr.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |junk1112@new.rr.com
--- Comment #4 from Erik Johnson junk1112@new.rr.com 2008-07-19 23:02:00 --- (In reply to comment #3)
Is this still an issue in current (1.0-rc4 or newer) wine?
(Also commented this on 10342: http://bugs.winehq.org/show_bug.cgi?id=10342)
Yes, subpixel rendering is still not enabled. I looked at the WINE code that manages the font rendering, and grayscale and "no antialiasing" are the only options. Subpixel rendering is listed as a to-do on winehq.org and also here: http://www.winehq.org/site/resources . In a similar but possibly separate issue, I'm not entirely sure, but it appears that WINE does its own "brute force" rendering of fonts, and completely ignores the user's .fonts.conf, or the system's /etc/fonts/conf.d/* files in how it renders the fonts. Perhaps this is somehow required in order to hammer the fonts into the spots where Windows programs expect them... I don't know. At the very least, subpixel rendering would probably solve a lot of users' gripes about WINE and fonts. (Do a search in google on "wine" and "subpixel" or "wine" and "cleartype".)
But IMHO, WINE should just be turning all the font rendering over to the user's system (freetype, xft, etc), under the assumption that the user knows how he/she wants the fonts to look, and has already configured their system thusly. If there is no reason for WINE to override what the user has set on their system, then it shouldn't. This prevents WINE from bearing the brunt of any "legal" issues about subpixel rendering.. it is simply using what the user has set up on the system.