https://bugs.winehq.org/show_bug.cgi?id=41639
Bug ID: 41639 Summary: Wine with freetype 2.7 causes font rendering issues Product: Wine Version: unspecified Hardware: x86-64 URL: http://imgur.com/a/dLe7G OS: Mac OS X Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: sdoom4@gmail.com
With the latest XQuartz (2.7.11) that includes Freetype 2.7, Wine no longer has smoothed text. I switched back to XQuartz 2.7.9 and the issue does not appear.
The reason I bring this up is that the XQuartz team says it's not their problem; it's FreeType's problem. I go look on FreeType and discover that Freetype 2.7 is more of a "3.0" than anything else, with a completely new hinting system and defaults. They're not going to budge on that.
This is a bit of an odd report, as I don't really know what/who is the culprit here. But it looks pretty bad if you're affected by it. in the URL field is a link of two screenshots (as I can't attach two files). Top is normal, bottom is with Freetype 2.7.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #1 from sdoom4@gmail.com --- Apologies, looks like the image uploader I use randomly swaps the order of the images. I think it's obvious which one is the "bad" shot, though.
https://bugs.winehq.org/show_bug.cgi?id=41639
Rahim sb56637@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sb56637@gmail.com
--- Comment #2 from Rahim sb56637@gmail.com --- Same problem here on openSUSE Tumbleweed: https://bugzilla.suse.com/show_bug.cgi?id=1004524
https://bugs.winehq.org/show_bug.cgi?id=41639
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- I'm on Arch and have the same issue. I tested it with notepad++, the font in question is tahoma. To test it, create a new wineprefix, run "winetricks tahoma" and get notepad++ 7.2.
Screenshots for comparison: http://imgur.com/a/OIIO6 Especially important is the menu strip with new freetype and tahoma installed, it looks really bad.
https://bugs.winehq.org/show_bug.cgi?id=41639
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42171
https://bugs.winehq.org/show_bug.cgi?id=41639
Hans N hans.nedoma@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans.nedoma@gmail.com
--- Comment #4 from Hans N hans.nedoma@gmail.com --- Having the same issue running the official 2.0-rc6 package on macOS 10.12.2 with FreeType 2.7.0 (as part of XQuartz 2.7.11), downgrading to XQuartz 2.7.9 (with FreeType 2.6.3) fixes it.
https://bugs.winehq.org/show_bug.cgi?id=41639
Lucian Poston lucianposton@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lucianposton@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #5 from Lucian Poston lucianposton@gmail.com --- As a workaround,
export FREETYPE_PROPERTIES="truetype:interpreter-version=35"
before running wine. This uses the renderer from freetype 2.6.
https://bugs.winehq.org/show_bug.cgi?id=41639
t.bussmann@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |t.bussmann@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=41639
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=41639
John Found johnfound@asm32.info changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johnfound@asm32.info
--- Comment #6 from John Found johnfound@asm32.info --- The issue is definitely related to the changes of FreeType algorithms and/or API after v2.6 or maybe v2.7; The problem exists in Linux as well with FreeType v2.8;
On my system it manifest itself by missing sub-pixel antialiasing. Only grayscale works and only on some fonts, possibly larger than some threshold - something like 12px.
I will prefix my finding by +/-:
- The suggested workaround does not work at all.
+ But downgrading to FreeType v2.7 do work; The sub-pixel smoothing works again.
- But WINE stopped respect its own settings in the registry for the font smoothing: HKCU/Control panel/Desktop/FontSmoothing (and FontSmoothingGamma, FontSmoothingOrientation, FontSmoothingType) does not affect the font rendering at all.
+ But the system settings does affect WINE rendering behavior. I can switch smoothing on/off by changing the system settings from XFCE appearance applet.
- WINE seems to not respect the fontconfig settings in /etc/fonts and ~/.config/fontconfig/ - I have a font that need not to be smoothed and have the following file in "~/.config/fontconfig/99-FixedSys.conf":
... <match target="font"> <test name="family" compare="eq" ignore-blanks="true"> <string>Fixedsys Excelsior 3.01</string> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> <edit name="hintstyle" mode="assign"> <const>hintnone</const> </edit> <edit name="rgba" mode="assign"> <const>none</const> </edit> </match> ...
So, WINE applications does not respect this .conf file, but the native Linux applications does.
In general, the native Linux application and the desktop environment are not affected by these changes in FreeType or was adapted better to the changes.
That is all so far. This issue looks and feels like a complete mess. :) I have a feeling that the problem is in the way WINE interacts with FreeType/fontconfig and is not a specific bug/regression but some kind of not proper interfacing to FreeType after the API changes.
https://bugs.winehq.org/show_bug.cgi?id=41639
lilydjwg@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lilydjwg@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=41639
Diver diver@gelios.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |diver@gelios.net
--- Comment #7 from Diver diver@gelios.net --- Downgrading XQuartz 2.7.9 on macOS 10.13.3 with wine 3.0 fixes it.
https://bugs.winehq.org/show_bug.cgi?id=41639
Roman Valls brainstorm@nopcode.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brainstorm@nopcode.org
--- Comment #8 from Roman Valls brainstorm@nopcode.org --- I can also confirm this issue, running on OSX sierra.
Instead of downgrading XQuartz I went for "winetricks settings fontsmooth=rgb", which is not ideal since the fonts look fuzzy (but at least readable) now:
How can this issue be UNCONFIRMED when there are so many confirmations? :-S
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #9 from Roman Valls brainstorm@nopcode.org --- Created attachment 60726 --> https://bugs.winehq.org/attachment.cgi?id=60726 Newest XQuartz (2.7.11) but antialiasing activated
https://bugs.winehq.org/show_bug.cgi?id=41639
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #10 from Fabian Maurer dark.shadow4@web.de --- Still relevant as of wine-3.3.
https://bugs.winehq.org/show_bug.cgi?id=41639
Screwtape thristian@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thristian@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=41639
chupaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chupaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=41639
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=41639
Daniel Bermond danielbermond@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |danielbermond@yahoo.com
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #11 from sdoom4@gmail.com --- I really hate bumping this, but this is back, again. Same issue with Freetype 2.9.1, and XQuartz 2.7.11. I don't need to supply screenshots, for it looks the same as the day I posted the report.
https://bugs.winehq.org/show_bug.cgi?id=41639
taisfmq@live.cn changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |taisfmq@live.cn
--- Comment #12 from taisfmq@live.cn --- +1 for wine-3.6
https://bugs.winehq.org/show_bug.cgi?id=41639
james@toggen.com.au changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |james@toggen.com.au
--- Comment #13 from james@toggen.com.au --- Created attachment 61636 --> https://bugs.winehq.org/attachment.cgi?id=61636 Screen shot of Wine 3.0.1 Chunky Fonts
Seeing chunky fonts in menu items. I have MacOS 10.13.5, XQuartz 2.7.11 and wine-3.0.1 installed via brew.
Have tried running:
winetricks allfonts fontfix fontsmooth-rgb winetricks settings fontsmooth=gray
and changing the DPI to 120 using winecfg but not helping
Is this related to this thread?
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #14 from chupaka@gmail.com --- (In reply to james from comment #13)
Seeing chunky fonts in menu items. I have MacOS 10.13.5, XQuartz 2.7.11 and wine-3.0.1 installed via brew.
Is this related to this thread?
Downgrade to XQuartz 2.7.9 and check if it helps.
https://bugs.winehq.org/show_bug.cgi?id=41639
Logan Rathbone poprocks@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |poprocks@gmail.com
--- Comment #15 from Logan Rathbone poprocks@gmail.com --- I don't have a solution in terms of what, if anything, in WINE should be patched or modified. But here is what I know and can add to this discussion.
For the record, I'm on Slackware-Current running WINE 3.0.1 as packaged on winehq.org by Simone Giustetti (Oh, look at that - it was updated to 3.0.2 yesterday). But I've also noticed the issue on Fedora Core 28 with both wine-staging 3.11 (as packaged in the official Fedora repos) and winehq-stable as provided by winehq.org.
Freetype 2.7 added a new subpixel hinting mode that is different from the previous "subpixel rendering" option that could be activated in freetype by uncommenting "#define FT_CONFIG_OPTION_SUBPIXEL_RENDERING" in include/freetype/config/ftoption.h ("ftoption.h").
Prior to 2.7, most distros left this option commented due to patent issues from Microsoft (NB: these are *different* from the *expired* patents that pertained to the bytecode interpreter issue; that is separate and is not to be confused with these MS patents).
On such distros, subpixel rendering would not have been available *at all*. Enable it all you want, but the rendering will still be monochrome (see, eg, a close-up of your fonts with xmag).
So enter 2.7. Hooray! We don't have to enable this patented code anymore to get subpixel rendering, because we have TT_CONFIG_OPTION_SUBPIXEL_HINTING which gets unpatented subpixel hinting enabled. Three modes are now possible, depending on how freetype was compiled: FREETYPE_PROPERTIES="truetype:interpreter-version=X", where X is 35, 38 or 40.
35 is the classic hinting mode from Freetype 2.6.x and earlier.
38 is Infinality mode, which was never enabled by default, but I believe was available in 2.6.x and below as a well-hidden option.
40 is the new unpatented subpixel hinting mode, and is the default in 2.7.x and later.
So you can set FREETYPE_PROPERTIES="truetype:interpreter-version=35" and run WINE, and get whatever you would have been getting prior to 2.7.
If in 2.7.x and later, you *don't* enable FT_CONFIG_OPTION_SUBPIXEL_RENDERING, *in addition to* setting TT_CONFIG_OPTION_SUBPIXEL_HINTING to your preferred configuration (I've not tried building 2.7+ without enabling TT_CONFIG_OPTION_SUBPIXEL_HINTING at all), your fonts will be un-antialiased at certain sizes no matter what you do, in accordance with their "gasp" tables. Eg, Times New Roman, Arial, etc., all say "don't antialias me between sizes 8 and 12" (or whatever).
But the problem is, under the new subpixel hinting mode, unantialiased fonts look like garbage. So if you force FREETYPE_PROPERTIES="truetype:interpreter-version=35", your fonts will render correctly, but they'll remain unantialiased.
*If*, however, either under pre-2.7 *or* post-2.7 with FT_CONFIG_OPTION_SUBPIXEL_RENDERING *enabled*, WINE will render your fonts correctly, with antialiasing, subpixel rendering, the whole nine yards. They will look very nice, if I may say so myself.
A prerequisite for this is also to have the appropriate FontSmoothing registry entries enabled through your WINE prefix (via winetricks or otherwise).
So it seems that, with certain fonts at certain sizes in accordance with their gasp tables, WINE *needs* the old subpixel rendering mode of Freetype to be enabled; otherwise it will simply not cooperate and will not antialias the fonts.
I think this needs to be reworked a bit, but I've no idea how to do it. WINE should probably just find a way to antialias the fonts and let the system decide how to do it rather than tapping so directly into freetype's old subpixel rendering method, and just failing to antialias at all if that mode is not available. I think WINE could probably get away with just antialiasing everything being "good enough" if FontSmoothing is set to RGB (or whatever) and the old subpixel rendering method is unavailable.
Problem is, if something is not done we're going to be stuck with absolutely unreadable fonts in WINE for quite some time, as most distros are shipping 2.7+ now with the defaults being left alone.
Hope this helps!
https://bugs.winehq.org/show_bug.cgi?id=41639
Mondane mondane.woodworker@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mondane.woodworker@gmail.co | |m
https://bugs.winehq.org/show_bug.cgi?id=41639
Guilherme Silva guih.rox@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |guih.rox@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=41639
Hugo hpessotti@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hpessotti@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #16 from Hugo hpessotti@gmail.com --- Wine 3.18 is out and it includes "Subpixel font rendering with FreeType >= 2.8.1"
XQuartz 2.7.11 uses FreeType 2.7, is there any way to update freetype so we can benefit from Wine 3.18 fixes for FreeType 2.8?
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #17 from Rahim sb56637@gmail.com --- Wow, with Wine 3.18 on openSUSE it looks like this bug is not only resolved, but we now have rather good antialiasing / subpixel rendering too. Well done devs! Should this bug be closed now?
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #18 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Rahim from comment #17)
Wow, with Wine 3.18 on openSUSE it looks like this bug is not only resolved, but we now have rather good antialiasing / subpixel rendering too. Well done devs! Should this bug be closed now?
You sure you're not using freetype 2.8.x? This bug is about 2.7.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #19 from Rahim sb56637@gmail.com --- (In reply to Nikolay Sivov from comment #18)
(In reply to Rahim from comment #17)
Wow, with Wine 3.18 on openSUSE it looks like this bug is not only resolved, but we now have rather good antialiasing / subpixel rendering too. Well done devs! Should this bug be closed now?
You sure you're not using freetype 2.8.x? This bug is about 2.7.
Hmmm yes, you're right, Freetype 2.9.1 actually. So for anybody searching, you can resolve this bug if you upgrade to a distro running Freetype 2.9.x. (At least for me Freetype 2.8.x did not fix this bug.)
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #20 from Roman Valls brainstorm@nopcode.org --- Unfortunately on OSX, even using brew-installed Freetype 2.9.1:
$ brew info freetype freetype: stable 2.9.1 (bottled) Software library to render fonts https://www.freetype.org/ /usr/local/Cellar/freetype/2.9.1 (60 files, 2.6MB) * Poured from bottle on 2018-10-20 at 00:10:40 From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/freetype.rb ==> Dependencies Required: libpng ✔
And Wine 3.18:
$ brew cask info wine-devel wine-devel: 3.18 https://wiki.winehq.org/MacOS /usr/local/Caskroom/wine-devel/3.18 (120.9MB) From: https://github.com/Homebrew/homebrew-cask-versions/blob/master/Casks/wine-de... ==> Name WineHQ-devel ==> Artifacts winehq-devel-3.18.pkg (Pkg) ==> Caveats wine-devel installs support for running 64 bit applications in Wine, which is considered experimental. If you do not want 64 bit support, you should download and install the wine-devel package manually.
Fonts still don't look good at all... I guess that XQuartz is the culprit now since it has not been updated/released since 2016?.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #21 from Roman Valls brainstorm@nopcode.org --- Created attachment 62593 --> https://bugs.winehq.org/attachment.cgi?id=62593 OSX 10.13.6, XQuartz 2.7.11, Wine 3.18
Trying with LTSpice: http://ltspice.analog.com/software/LTspiceXVII.exe
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #22 from Nikolay Sivov bunglehead@gmail.com --- You'll have to make sure you're using correct library, and not XQuartz one.
https://bugs.winehq.org/show_bug.cgi?id=41639
Byeongsik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bsjeon@hanmail.net
--- Comment #23 from Byeongsik Jeon bsjeon@hanmail.net --- Created attachment 62594 --> https://bugs.winehq.org/attachment.cgi?id=62594 tempary patch for the fontconfig fail.
Please test this temperary patch. I cat't test the MacOS.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #24 from Hugo hpessotti@gmail.com --- (In reply to Byeongsik Jeon from comment #23)
Created attachment 62594 [details] tempary patch for the fontconfig fail.
Please test this temperary patch. I cat't test the MacOS.
Just tried to compile wine 3.19 with the suggested patch and it remains the same.
https://bugs.winehq.org/show_bug.cgi?id=41639
Byeongsik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #62594|0 |1 is obsolete| |
--- Comment #25 from Byeongsik Jeon bsjeon@hanmail.net --- Created attachment 62651 --> https://bugs.winehq.org/attachment.cgi?id=62651 tempary patch for the aa_flags trace easyly.
I have attached a simple patch to make the test easier. Please apply it to the latest wine-git.
$ WINEDEBUG=font,xrender wine some_prog.exe &> some_prog.trace.txt
Please upload the test results file and the capture images of the problematic program.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #26 from Hugo hpessotti@gmail.com --- Created attachment 62652 --> https://bugs.winehq.org/attachment.cgi?id=62652 Test results of patch from comment #25
Byeongsik Jeon, here is the requested log resulting from the patch from comment #25 applied to the latest wine-git as of 30-oct-2018.
Here is also a screenshot of the logged application (winecfg): https://imgur.com/a/5oCV3K9
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #27 from Hugo hpessotti@gmail.com --- Created attachment 62653 --> https://bugs.winehq.org/attachment.cgi?id=62653 Test results of patch from comment #25 on a clean wineprefix
Byeongsik Jeon, here is another log, this time with a clean wineprefix.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #28 from Byeongsik Jeon bsjeon@hanmail.net --- (In reply to Hugo from comment #27)
Created attachment 62653 [details] Test results of patch from comment #25 on a clean wineprefix
Byeongsik Jeon, here is another log, this time with a clean wineprefix.
Please test "winetricks fontsmooth=rgb"
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #29 from Byeongsik Jeon bsjeon@hanmail.net --- Created attachment 62654 --> https://bugs.winehq.org/attachment.cgi?id=62654 Update the default fontsmooth paramters.
Or, Please test this patch with the wineprefix cleaning.
https://bugs.winehq.org/show_bug.cgi?id=41639
Hugo hpessotti@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #62652|0 |1 is obsolete| | Attachment #62653|0 |1 is obsolete| |
--- Comment #30 from Hugo hpessotti@gmail.com --- Created attachment 62655 --> https://bugs.winehq.org/attachment.cgi?id=62655 Test results of patch from comment #25 with fontsmooth=rgb
screenshot: https://image.ibb.co/n3jyCf/Captura-de-Tela-2018-10-30-a-s-11-17-38.png
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #31 from Hugo hpessotti@gmail.com --- Created attachment 62656 --> https://bugs.winehq.org/attachment.cgi?id=62656 Test results of patch from comment #29
screenshot: https://image.ibb.co/jAafsf/Captura-de-Tela-2018-10-30-a-s-11-31-26.png
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #32 from Hugo hpessotti@gmail.com --- Created attachment 62657 --> https://bugs.winehq.org/attachment.cgi?id=62657 Test results of patch from comment #25 and truetype:interpreter-version=35
As a side note, running wine with FREETYPE_PROPERTIES="truetype:interpreter-version=35" looks nice
screenshot: https://image.ibb.co/ntTQsf/Captura-de-Tela-2018-10-30-a-s-11-19-13.png
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #33 from Byeongsik Jeon bsjeon@hanmail.net --- (In reply to Hugo from comment #32)
Created attachment 62657 [details] Test results of patch from comment #25 and truetype:interpreter-version=35
As a side note, running wine with FREETYPE_PROPERTIES="truetype:interpreter-version=35" looks nice
screenshot: https://image.ibb.co/ntTQsf/Captura-de-Tela-2018-10-30-a-s-11-19-13.png
Please WINEDEBUG trace logs. - comment #29 patch - wineprefix cleaning - with or without FREETYPE_PROPERTIES
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #34 from Byeongsik Jeon bsjeon@hanmail.net --- OK.
This is the freetype build option problem. You need to build a Freetype library with #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING
Or, the latest Freetype library will solve the problem.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #35 from Hugo hpessotti@gmail.com --- (In reply to Byeongsik Jeon from comment #34)
OK.
This is the freetype build option problem. You need to build a Freetype library with #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING
Or, the latest Freetype library will solve the problem.
Sadly, I cannot change the Freetype version or recompile it because its bundled with XQuartz in MacOS. I could compile the entire xorg-server with the latest freetype but in Mac everyone just downloads the latest XQuartz, so a fix would be really appreciated!
Meanwhile, I am trying to force interpreter-version:35 inside freetype.c, but the following code crashes wine without any meaningful log. If it worked, I was thinking about setting it only if Freetype was 2.7.0.
I am including it after "font_driver = &freetype_funcs;" inside "static BOOL init_freetype(void)":
FT_UInt interpreter_version; FT_Error err;
interpreter_version = 35; err = pFT_Property_Set( library, "truetype", "interpreter-version", interpreter_version ); if (err) { ERR("set interpreter-version: %d\n", err); return FALSE; }
(FT_Property_Set was loaded with LOAD_FUNCPTR after MAKE_FUNCPTR at the beginning of the file)
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #36 from Byeongsik Jeon bsjeon@hanmail.net --- Created attachment 62658 --> https://bugs.winehq.org/attachment.cgi?id=62658 temperary patch disable subpixel rendering check for the XQurtz 2.7.11
Please test this new patch.
Simply, in the dlls/gdi32/freetype.c
case WINE_GGO_VBGR_BITMAP: /* disable subpixel rendering checking */ break;
if (is_subpixel_rendering_enabled()) break; *aa_flags = GGO_GRAY4_BITMAP; TRACE("subpixel rendering disabled. fallback aa_flags = %d\n", *aa_flags); /* fall through */ case GGO_GRAY2_BITMAP: case GGO_GRAY4_BITMAP:
https://bugs.winehq.org/show_bug.cgi?id=41639
Hugo hpessotti@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #62655|0 |1 is obsolete| | Attachment #62656|0 |1 is obsolete| | Attachment #62657|0 |1 is obsolete| |
--- Comment #37 from Hugo hpessotti@gmail.com --- Created attachment 62659 --> https://bugs.winehq.org/attachment.cgi?id=62659 Test results of patch from comment #36 with fontsmooth=rgb
This patch looks better with fontsmooth=rgb (attached trace), but not as sharp as version=35.
Comparison: https://image.ibb.co/bSbLA0/compare.png
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #38 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Byeongsik Jeon from comment #34)
OK.
This is the freetype build option problem. You need to build a Freetype library with #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING
Or, the latest Freetype library will solve the problem.
Why would it matter if using same binary with different engine mode works? And why subpixel mode would matter for b/w bitmaps?
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #39 from Byeongsik Jeon bsjeon@hanmail.net --- (In reply to Nikolay Sivov from comment #38)
(In reply to Byeongsik Jeon from comment #34)
OK.
This is the freetype build option problem. You need to build a Freetype library with #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING
Or, the latest Freetype library will solve the problem.
Why would it matter if using same binary with different engine mode works?
Maybe, this.
(In reply to Hugo from comment #35)
Sadly, I cannot change the Freetype version or recompile it because its bundled with XQuartz in MacOS. I could compile the entire xorg-server with the latest freetype but in Mac everyone just downloads the latest XQuartz, so a fix would be really appreciated!
Meanwhile, I am trying to force interpreter-version:35 inside freetype.c,
And why subpixel mode would matter for b/w bitmaps?
My patch is for analyzing this problem. It's literally a temporary patch.
I wanted to make sure that the Freetype of XQuartz 2.7.11 was something special modification. It doesn't seem like it. Now, this problem can be simulated exactly on my Linux box.
I think the XQuartz update is the right solution. However I think it is registered as a bug because it is not possible for some reason.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #40 from Hugo hpessotti@gmail.com --- (In reply to Byeongsik Jeon from comment #39)
I think the XQuartz update is the right solution. However I think it is registered as a bug because it is not possible for some reason.
Problem is that XQuartz does not receive an update since 2016-10-29 (latest version is 2.7.11) and it is the only binary distribution of xorg that works well with the latest Mac OS X (Apple stopped shipping X11 with OS X 10.7 in 2011).
In fact, XQuartz dev already said that he wont release XQuartz anymore and recommends using macports (a kind of package manager that compiles everything in place) as a way to have the latest xorg-server on MacOSX.
However, macports it very little user-friendly and even Wine recommends using XQuartz because it is ready for installation and works out-of-the-box.
As a workaround, most of us just download XQuartz 2.7.9, which is bundled with freetype 2.6.3.
https://bugs.winehq.org/show_bug.cgi?id=41639
Byeongsik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #62658|0 |1 is obsolete| |
--- Comment #41 from Byeongsik Jeon bsjeon@hanmail.net --- Created attachment 62662 --> https://bugs.winehq.org/attachment.cgi?id=62662 temperary test patch for truetype interpreter version 35.
Please test these temperary patch, and tell me the results of various fonts.
I am curious about the results of fonts that do not turn off gray anti-alias at a small pixel size. 0002-~~~.patch allows you to test this easily.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #42 from Hugo hpessotti@gmail.com --- (In reply to Byeongsik Jeon from comment #41)
Created attachment 62662 [details] temperary test patch for truetype interpreter version 35.
Please test these temperary patch, and tell me the results of various fonts.
I am curious about the results of fonts that do not turn off gray anti-alias at a small pixel size. 0002-~~~.patch allows you to test this easily.
Patch 0001 worked after some modifications, it was complaining about FT_DRIVER_H and TT_INTERPRETER_VERSION_35 errors (see below) so I hardcoded 35 on "const FT_UInt interpreter_version = 35" and it compiled.
error: expected "FILENAME" or <FILENAME> #include FT_DRIVER_H
error: use of undeclared identifier 'TT_INTERPRETER_VERSION_35' const FT_UInt interpreter_version = TT_INTERPRETER_VERSION_35;
About patch 0002 I am not sure how to test, I need to apply it, open notepad, write something and change fonts from 6 to 12pt and see how it goes?
Screenshot of 0001: https://image.ibb.co/n9GDf0/Captura-de-Tela-2018-10-30-a-s-17-09-22.png
This screenshot was taken with only 0001 applied and without fontsmoothing=rgb set (looks great even without it!)
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #43 from Hugo hpessotti@gmail.com --- (In reply to Byeongsik Jeon from comment #41)
I am curious about the results of fonts that do not turn off gray anti-alias at a small pixel size. 0002-~~~.patch allows you to test this easily.
I managed to do some tests with 0001 applied and 0002 on/off, see below:
Screenshot: https://image.ibb.co/gDxB00/compare2.png
(Still hardcoding 35 on const FT_UInt interpreter_version, I could not fix this error...)
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #44 from Byeongsik Jeon bsjeon@hanmail.net --- - Apply 0001, 0002 patch. - Set the size of the notepad font size to 8pt, or 9pt. - Type the this text. ABCDEFGIHJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 1234567890!@#$%^&*() Or, any english text document. - Try the another font.
I can get the same results. I want to hear the feeling of the outcome.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #45 from Hugo hpessotti@gmail.com --- (In reply to Byeongsik Jeon from comment #44)
- Apply 0001, 0002 patch.
- Set the size of the notepad font size to 8pt, or 9pt.
- Type the this text.
ABCDEFGIHJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 1234567890!@#$%^&*() Or, any english text document.
- Try the another font.
I can get the same results. I want to hear the feeling of the outcome.
Screenshot comparing Tahoma/Times 8/9pt with and without 0002:
https://image.ibb.co/e9LLA0/compare3.png
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #46 from Hugo hpessotti@gmail.com --- (In reply to Byeongsik Jeon from comment #44)
- Apply 0001, 0002 patch.
- Set the size of the notepad font size to 8pt, or 9pt.
- Type the this text.
ABCDEFGIHJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 1234567890!@#$%^&*() Or, any english text document.
- Try the another font.
I can get the same results. I want to hear the feeling of the outcome.
I think it is better without 0002, because fonts looks sharper overall. Menus, interface and text, in my opinion looks better without 0002.
I will try with more fonts!
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #47 from Byeongsik Jeon bsjeon@hanmail.net --- (In reply to Hugo from comment #46)
I can get the same results. I want to hear the feeling of the outcome.
I think it is better without 0002, because fonts looks sharper overall. Menus, interface and text, in my opinion looks better without 0002.
I will try with more fonts!
These are enough information. Thank you.
https://bugs.winehq.org/show_bug.cgi?id=41639
Byeongsik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #62662|0 |1 is obsolete| |
--- Comment #48 from Byeongsik Jeon bsjeon@hanmail.net --- Created attachment 62666 --> https://bugs.winehq.org/attachment.cgi?id=62666 draft1_bugs_41639
I have attached a new patch set. Please test.
- truetype interpreter version 35 Support - improved rendering quality in gray antialias mode. It works on 'fontsmooth=rgb' fallback mode.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #49 from Hugo hpessotti@gmail.com --- (In reply to Byeongsik Jeon from comment #48)
Created attachment 62666 [details] draft1_bugs_41639
I have attached a new patch set. Please test.
- truetype interpreter version 35 Support
- improved rendering quality in gray antialias mode. It works on
'fontsmooth=rgb' fallback mode.
Applying both patches yield great results!
Tested with various fonts, only at 6pt it looks blurry. 7pt onwards, most of the fonts were very sharp and readable.
Tahoma 6pt https://image.ibb.co/gViyXf/Captura-de-Tela-2018-10-31-a-s-11-43-25.png
Tahoma 7pt https://image.ibb.co/idOMk0/Captura-de-Tela-2018-10-31-a-s-11-43-35.png
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #50 from Rahim sb56637@gmail.com --- Created attachment 62667 --> https://bugs.winehq.org/attachment.cgi?id=62667 Good rendering | freetype 2.9.1 | wine 3.19
Here's a few examples of the excellent font rendering that I now have on openSUSE Tumbleweed with freetype 2.9.1 and wine 3.19. Thanks to all involved for finally fixing this bug on Linux!
https://bugs.winehq.org/show_bug.cgi?id=41639
Rahim sb56637@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|sb56637@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #51 from Byeongsik Jeon bsjeon@hanmail.net --- While reviewing this bug page and patch as a whole, I realized that this bug was not a problem in XQuartz Freetype only.
In the interpreter version 40, the current Wine GDI is very different from the native Windows in the text layout (glyph metrics).
In my freetype build, TRUETYPE_PROPERTIES="truetype:interpreter-version=35" winecfg TRUETYPE_PROPERTIES="truetype:interpreter-version=38" winecfg TRUETYPE_PROPERTIES="truetype:interpreter-version=40" winecfg
This bug will naturally be solved while solving this problem.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #52 from Byeongsik Jeon bsjeon@hanmail.net --- (In reply to Byeongsik Jeon from comment #51)
While reviewing this bug page and patch as a whole, I realized that this bug was not a problem in XQuartz Freetype only.
In the interpreter version 40, the current Wine GDI is very different from the native Windows in the text layout (glyph metrics).
In my freetype build, TRUETYPE_PROPERTIES="truetype:interpreter-version=35" winecfg TRUETYPE_PROPERTIES="truetype:interpreter-version=38" winecfg TRUETYPE_PROPERTIES="truetype:interpreter-version=40" winecfg
This bug will naturally be solved while solving this problem.
and, with the some fonts(ex. native Tahoma).
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #53 from Byeongsik Jeon bsjeon@hanmail.net --- Created attachment 62695 --> https://bugs.winehq.org/attachment.cgi?id=62695 draft2_bugs_41639
I have attached a second patch set draft.
This is also a problem in Linux. It just seemed to stand out in MacOS(builtin Tahoma) XQuartz2.7.11 Freetype2.7(turned off subpixel).
- v40 legacy font problem(Tahoma, Arial, Courier New, ...). - v35 cleartype supported font problem(Consolas, ...)
To avoid both problems, I use the gasp table version. This idea is inspired by the following documentation.
https://www.freetype.org/freetype2/docs/reference/ft2-properties.html#TT_INT... --- Note that ‘Gray ClearType’ is essentially the same as v1.6's grayscale rendering. However, the GETINFO instruction handles it differently: v1.6 returns bit 12 (hinting for grayscale), while v2.1 returns bits 13 (hinting for ClearType), 18 (symmetrical smoothing), and 19 (Gray ClearType). Also, this mode respects bits 2 and 3 for the version 1 gasp table exclusively (like Color ClearType), while v1.6 only respects the values of version 0 (bits 0 and 1). ---
Please test. You won't feel much different from draft1 without fonts like Consolas. That is the right result.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #54 from Hugo hpessotti@gmail.com --- (In reply to Byeongsik Jeon from comment #53)
Please test. You won't feel much different from draft1 without fonts like Consolas. That is the right result.
Very small fonts were more readable before, for example Tahoma 6pt:
before https://image.ibb.co/gViyXf/Captura-de-Tela-2018-10-31-a-s-11-43-25.png
after https://image.ibb.co/dq1nf0/Captura-de-Tela-2018-11-02-a-s-19-02-17.png
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #55 from Hugo hpessotti@gmail.com --- (In reply to Byeongsik Jeon from comment #53)
Please test. You won't feel much different from draft1 without fonts like Consolas. That is the right result.
Sorry about my last comment, I forgot to apply one of the patches.
This new one looks bette with other fonts, like Calibri.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #56 from Byeongsik Jeon bsjeon@hanmail.net --- (In reply to Hugo from comment #55)
This new one looks bette with other fonts, like Calibri.
OK. Clibri is also a cleartype font. After a little more review, I'll post on the wine-devel.
https://bugs.winehq.org/show_bug.cgi?id=41639
Justin M herb.kornfeld@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |herb.kornfeld@gmail.com
--- Comment #57 from Justin M herb.kornfeld@gmail.com --- Have these patches (draft1_bugs and draft2_bugs) been implemented in the 3.20 binaries? If I need to build Wine on MacOS, should I install a specific version of Xquartz or freetype?
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #58 from Hugo hpessotti@gmail.com --- (In reply to Justin M from comment #57)
Have these patches (draft1_bugs and draft2_bugs) been implemented in the 3.20 binaries? If I need to build Wine on MacOS, should I install a specific version of Xquartz or freetype?
Not yet, you need to install XQuartz 2.7.9 meanwhile.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #59 from Hugo hpessotti@gmail.com --- Any idea when it will be merged in the wine-devel branch?
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #60 from Byeongsik Jeon bsjeon@hanmail.net --- (In reply to Hugo from comment #59)
Any idea when it will be merged in the wine-devel branch?
It's still in progress. The solution I posted above is wrong.
https://bugs.winehq.org/show_bug.cgi?id=41639
--- Comment #61 from Gijs Vermeulen gijsvrm@gmail.com --- For me (on macOS) this was fixed by https://source.winehq.org/git/wine.git/commit/c666a45560c3998e9cf5271d2628eb2b913d0b4f
https://bugs.winehq.org/show_bug.cgi?id=41639
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |c666a45560c3998e9cf5271d262 | |8eb2b913d0b4f
--- Comment #62 from Gijs Vermeulen gijsvrm@gmail.com --- (In reply to Gijs Vermeulen from comment #61)
For me (on macOS) this was fixed by https://source.winehq.org/git/wine.git/commit/ c666a45560c3998e9cf5271d2628eb2b913d0b4f
Since I could reproduce the original issue, it being fixed and there were no further comments, I'm going to mark this FIXED.
Please reopen/comment if you can still reproduce this.
https://bugs.winehq.org/show_bug.cgi?id=41639
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #63 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.0-rc1.
https://bugs.winehq.org/show_bug.cgi?id=41639
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.0.x
https://bugs.winehq.org/show_bug.cgi?id=41639
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.x |---
--- Comment #64 from Michael Stefaniuc mstefani@winehq.org --- Removing the 4.0.x milestone from bug fixes included in 4.0.4.