[Bug 32947] New: Broken font rendering with many fonts (including Microsoft core fonts) in wine 1.5
http://bugs.winehq.org/show_bug.cgi?id=32947
Bug #: 32947 Summary: Broken font rendering with many fonts (including Microsoft core fonts) in wine 1.5 Product: Wine Version: 1.5.22 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 AssignedTo: wine-bugs@winehq.org ReportedBy: constantine.gavrilov@gmail.com Classification: Unclassified
This is a long standing issue with 1.5 versions. Several bugs have been opened and closed but they usually do not get to the core issue.
One of the issues (that is listed as closed) is 29250.
Here is the beef of the matter.
Many true type fonts including core Microsoft fonts (Arial, Times New Roman, Courier New, Tahoma, Verdana) and all built-in true type fonts shipped with Wine (Tahoma, ms-sans-serif, etc.) will use subpixel rendering only at unrealistically big sizes (>= 16), and event then the quality is awful.
Other fonts (typically from Dejavu or Vera families) will render just fine and will use subpixel rendering at default sizes.
Asking wine to log font decisions shows that wine has decided to disable antialiasing for "problematic" fonts because of the info it got from GASP table.
I would like to stress that this is not a problem of fontconfig settings or fontconfig or wine font substitutions. Nor it is a problem of wrong DPI.
Native linux applications display just fine, and wine will display similar to Linux if Dejavu or Vera fonts are forced.
Additionally, ClientSideGraphics=N (or =Y) has nothing to do with this problem either. Under both settings, the fonts look similar and the decisions based on the GASP table are the same. This setting does not affect the decision to antialias or not, it affects the quality with ClientSideGraphics=N giving better results that are also consistent with the Linux desktop.
This feature (using the GASP tables the way they are used) is actually a misfeature because: * shipped wine fonts are not usable for dialogs and menus * native Windows fonts cannot be used because they will not use subpixel rendering but they are still recommended in documentation.
I understand that someone desired to get a closer picture to Windows, but what we have is unusable now. As far as I can see, Windows will antialias these fonts just fine (at least starting from size 12), and even when ClearType is not used for size 10, the font is still very crisp and readable.
Bottom line, when wine decides to skip antialias for most fonts, the result is very very ugly. I would even say it is not possible to use.
I also would like to claim that fontconfig uses subpixel rendering for these fonts just fine (native Linux applications look great) and I would say the results are better (at least definitely not worse) compared to Windows rendering for cases when it decides to skip antialiasing because the size is small.
Can we have a configuration setting to opt out of GASP table decisions?
http://bugs.winehq.org/show_bug.cgi?id=32947
Constantine Gavrilov constantine.gavrilov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P1 Severity|normal |major
--- Comment #1 from Constantine Gavrilov constantine.gavrilov@gmail.com 2013-02-11 06:04:14 CST --- Increasing priority -- annoying issue that affects usability.
The only way wine can be made usable now is to force "MS Shell Dlg" and "MS Shell Dlg2" to a Dejavu font (I use DejaVu Sans Condensed).
But Microsoft fonts will look awful in applications and forcing their substitution to other fonts will cause compatibility issues.
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #2 from Constantine Gavrilov constantine.gavrilov@gmail.com 2013-02-11 06:30:06 CST --- For information,
Google Droid font also render nicely.
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2013-02-11 06:37:16 CST --- The GASP table doesn't affect subpixel antialiasing. It's only used for grayscale antialiasing.
http://bugs.winehq.org/show_bug.cgi?id=32947
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P2 Component|gdi32 |-unknown Severity|major |minor
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru 2013-02-11 06:39:41 CST --- So much words and not a single screenshot?
And not Major, read http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #5 from Constantine Gavrilov constantine.gavrilov@gmail.com 2013-02-11 08:23:26 CST --- Created attachment 43509 --> http://bugs.winehq.org/attachment.cgi?id=43509 Antialiasing working with menu fonts set to Dejavu
In this screenshot we see that wine uses subpixel font rendering when using Dejavu font.
We see instances of notepad, winecfg and regedit. In regedit, it can be seen that alias for MS Shell Dlg fonts have been set to Dejavu.
Also, we see that notepad will render Dejavu in text are with subpixel.
We also see that notepad will not render Arial at size 10 with subpixel.
It start to render Arial with subpixel at size 14.
One can also see the xmag zoom on notepad rendering.
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #6 from Dmitry Timoshkov dmitry@baikal.ru 2013-02-11 08:37:39 CST --- (In reply to comment #5)
Created attachment 43509 [details] Antialiasing working with menu fonts set to Dejavu
In this screenshot we see that wine uses subpixel font rendering when using Dejavu font.
We see instances of notepad, winecfg and regedit. In regedit, it can be seen that alias for MS Shell Dlg fonts have been set to Dejavu.
Also, we see that notepad will render Dejavu in text are with subpixel.
We also see that notepad will not render Arial at size 10 with subpixel.
It start to render Arial with subpixel at size 14.
One can also see the xmag zoom on notepad rendering.
Personally I don't see any ugliness you are talking about. Also, Wine bugzilla is not really the place to discuss why font designers decided to limit font sizes at which they would like to see antialiasing work, you may try to read some FAQ on that subject.
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2013-02-11 08:39:36 CST --- It's not using subpixel rendering, that's grayscale antialiasing. You'd get better results by enabling subpixel in fontconfig.
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #8 from Constantine Gavrilov constantine.gavrilov@gmail.com 2013-02-11 08:48:39 CST --- Created attachment 43510 --> http://bugs.winehq.org/attachment.cgi?id=43510 Antialiasing not working with default setting (Tahoma)
In this screenshot, you see that antialiasing is not working if the alias from MS Shell Dlg is removed (dafault Tahoma font is used).
So, comparing the two pictures, we see that it is working with Dejavu and is not working with Tahoma.
The same not working results will be observed with other core Microsoft fonts.
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #9 from Constantine Gavrilov constantine.gavrilov@gmail.com 2013-02-11 09:08:45 CST --- Created attachment 43512 --> http://bugs.winehq.org/attachment.cgi?id=43512 Shows thyat subpixel rendering works with native applications
Looking at the previous snapshots, it does appear that wine does grayscale antialiasing.
In the attached screenshot, please see that the registry settings are set to use subpixel rendering in wine.
Additionaly, we see that wine uses grayscale (xmag and xmag2), while native applications (konsole and kwrite) use subpixel.
It is a wine problem.
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #10 from Constantine Gavrilov constantine.gavrilov@gmail.com 2013-02-11 09:24:47 CST --- Created attachment 43513 --> http://bugs.winehq.org/attachment.cgi?id=43513 Trace of wine showing font handling
The wine log of the following command (with no aliases to MS Shl Dlg fonts set):
WINEDEBUG="+font" wine regedit >& wine_log.txt
We see that wine says "is_subpixel_rendering_enabled subpixel rendering is NOT enabled", and the then we hit a lot of
trace:font:freetype_SelectFont font L"System" 16 aa disabled by GASP trace:font:freetype_SelectFont font L"MS Shell Dlg" -11 aa disabled by GASP
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2013-02-11 09:41:25 CST --- Your freetype library doesn't support subpixel rendering. You should fix that.
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #12 from Constantine Gavrilov constantine.gavrilov@gmail.com 2013-02-11 09:56:03 CST --- Please see the screenshot 3 ("Shows that subpixel rendering works with native applications").
It is clearly seen that it does have the required support. This is stock fedora-17 x86_64 installation with all updates applied.
The wine version installed is 32-bit from updates-testing repo (I have initially tried the wine-1.5.18 from updates repo -- both 64-bit and 32-bit and got the same results). The reason I tried the updated package was wine changelog claming these font issues have been fixed.
Now, looking at the code in gdi32/freetype.c, I see the following (version 1.5.23):
188 #ifdef HAVE_FREETYPE_FTLCDFIL_H 189 static FT_Error (*pFT_Library_SetLcdFilter)(FT_Library, FT_LcdFilter); 190 #endif
.... 929 static BOOL is_subpixel_rendering_enabled( void ) 930 { 931 #ifdef HAVE_FREETYPE_FTLCDFIL_H 932 static int enabled = -1; 933 if (enabled == -1) 934 { 935 enabled = (pFT_Library_SetLcdFilter && 936 pFT_Library_SetLcdFilter( NULL, 0 ) != FT_Err_Unimplemented_Feature); 937 TRACE("subpixel rendering is %senabled\n", enabled ? "" : "NOT "); 938 } 939 return enabled; 940 #else 941 return FALSE; 942 #endif 943 }
.............. 3665 #ifdef HAVE_FREETYPE_FTLCDFIL_H 3666 pFT_Library_SetLcdFilter = wine_dlsym(ft_handle, "FT_Library_SetLcdFilter", NULL, 0); 3667 #endif .........
Based on just this code, I do not see that the traces will show what was the problem -- whether FT_Library_SetLcdFilter was not found or whether pFT_Library_SetLcdFilter( NULL, 0 ) returned error.
Any ideas?
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #13 from Constantine Gavrilov constantine.gavrilov@gmail.com 2013-02-11 10:04:53 CST --- The symbol is present in the freetype library and shall be found:
[root@constg ~]# objdump -d /usr/lib/libfreetype.so.6| grep FT_Library_SetLcdFilter 4569b930 <FT_Library_SetLcdFilterWeights>: 4569b940 <FT_Library_SetLcdFilter>: 4569b97a: 74 21 je 4569b99d <FT_Library_SetLcdFilter+0x5d> 4569b985: 74 16 je 4569b99d <FT_Library_SetLcdFilter+0x5d> 4569b993: 74 08 je 4569b99d <FT_Library_SetLcdFilter+0x5d> 4569b997: 74 17 je 4569b9b0 <FT_Library_SetLcdFilter+0x70> 4569b9ba: 74 2a je 4569b9e6 <FT_Library_SetLcdFilter+0xa6> 4569b9db: 74 09 je 4569b9e6 <FT_Library_SetLcdFilter+0xa6> 4569b9e4: eb b7 jmp 4569b99d <FT_Library_SetLcdFilter+0x5d> 4569b9f8: eb a3 jmp 4569b99d <FT_Library_SetLcdFilter+0x5d> 4569ba0f: e8 3c ff ff ff call 4569b950 <FT_Library_SetLcdFilter+0x10> ......
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #14 from Alexandre Julliard julliard@winehq.org 2013-02-11 10:07:24 CST --- The rest of the system is using the 64-bit libfreetype, but Wine is using the 32-bit one. That's the one you need to fix.
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #15 from Constantine Gavrilov constantine.gavrilov@gmail.com 2013-02-11 10:24:06 CST --- Both are the same.
Namely:
From the freetype documentation:
Quote:
FT_Library_SetLcdFilter Defined in FT_LCD_FILTER_H (freetype/ftlcdfil.h).
FT_EXPORT( FT_Error ) FT_Library_SetLcdFilter( FT_Library library, FT_LcdFilter filter );
This function is used to apply color filtering to LCD decimated bitmaps, like the ones used when calling FT_Render_Glyph with FT_RENDER_MODE_LCD or FT_RENDER_MODE_LCD_V.
input
library
A handle to the target library instance. filter
The filter type.
You can use FT_LCD_FILTER_NONE here to disable this feature, or FT_LCD_FILTER_DEFAULT to use a default filter that should work well on most LCD screens. return
FreeType error code. 0 means success. note
This feature is always disabled by default. Clients must make an explicit call to this function with a ‘filter’ value other than FT_LCD_FILTER_NONE in order to enable it.
Due to PATENTS covering subpixel rendering, this function doesn't do anything except returning ‘FT_Err_Unimplemented_Feature’ if the configuration macro FT_CONFIG_OPTION_SUBPIXEL_RENDERING is not defined in your build of the library, which should correspond to all default builds of FreeType.
End of quote
Both 32-bit and 64-bit of freetype library are built with FT_CONFIG_OPTION_SUBPIXEL_RENDERING undefined. This is a standard policy of all distributions that ship freetype library.
This means that FT_Library_SetLcdFilter() will return FT_Err_Unimplemented_Feature. Yet, subpixel rendering works both in KDE and Gnome using freetype and fontconfig.
This has been the situation for years and I do not know what is the trick (either freetype lies about not supporting subpixel or uses partial functionality) but all opensource applications (including wine before 1.5) were able to use the subpixel rendering with these builds.
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #16 from Alexandre Julliard julliard@winehq.org 2013-02-11 10:37:18 CST --- Does it work if you disable that check (by making it always return TRUE)?
http://bugs.winehq.org/show_bug.cgi?id=32947
--- Comment #17 from Constantine Gavrilov constantine.gavrilov@gmail.com 2013-02-11 11:18:31 CST --- I can try that.
At this point I do not know that it is worth the hassle. I have just found that rpmfusion carries freetype-freeworld package which is the same version of freetype as the core distribution but compiled with the "patented" code (apperently the patents have expired).
The lib installs alongside the distribution library and overrides it with ld.so.conf.d.
After new lib was installed, wine started to use sub-pixel rendering independent of font size.
I will continue testing and will possibly try the work-around you suggested.
http://bugs.winehq.org/show_bug.cgi?id=32947
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |UPSTREAM
--- Comment #18 from Alexandre Julliard julliard@winehq.org 2013-02-14 03:15:48 CST --- Not a Wine bug.
https://bugs.winehq.org/show_bug.cgi?id=32947
taisfmq@live.cn changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |taisfmq@live.cn
--- Comment #19 from taisfmq@live.cn --- Still exist in Wine-3.6, small fonts are ugly and large fonts are OK. Any possible solutions to make it behave similar to Windows?
https://bugs.winehq.org/show_bug.cgi?id=32947
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #20 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=32947
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #21 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.
-
wine-bugs＠winehq.org