http://bugs.winehq.org/show_bug.cgi?id=10342
Summary: Implement ClearType also known as SubPixel Rendering Product: Wine Version: unspecified Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-x11driver AssignedTo: wine-bugs@winehq.org ReportedBy: winehacker@gmail.com
Newer FreeType builds have support for this and without it Wine currently looks very bad on LCD displays.
http://en.wikipedia.org/wiki/Subpixel_rendering
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #1 from Steven Edwards winehacker@gmail.com 2007-11-07 11:00:24 --- http://osdir.com/ml/fonts.freetype.user/2006-09/msg00069.html
Information on enabling ClearType in FreeType.
http://bugs.winehq.org/show_bug.cgi?id=10342
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX
--- Comment #2 from Vitaliy Margolen vitaliy@kievinfo.com 2007-11-07 12:12:29 --- That will be a won't fix. This is patented technology and can not be used everywhere.
http://bugs.winehq.org/show_bug.cgi?id=10342
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #3 from Vitaliy Margolen vitaliy@kievinfo.com 2007-11-07 12:13:11 --- You can get the CrossOver Office which has that feature enabled.
http://bugs.winehq.org/show_bug.cgi?id=10342
Steven Edwards winehacker@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|WONTFIX |
--- Comment #4 from Steven Edwards winehacker@gmail.com 2007-11-07 20:46:03 --- CrossOver implements TrueType Anti-Alias Hinting not SubPixel Font rendering. As far as I know the code to do this is also in Winehq, all thats needed is to recompile FreeType with the patented ByteCode interpreter enabled. The same thing would happen with ClearType. We've linked to patented code before such as the S3 texture compression library so that does not seem to be a valid reason to not implement it even if it can't be shipped as enabled by default.
http://bugs.winehq.org/show_bug.cgi?id=10342
Piotr Gawrysiak pgawrysiak@supermedia.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgawrysiak@supermedia.pl
--- Comment #5 from Piotr Gawrysiak pgawrysiak@supermedia.pl 2007-11-16 17:36:33 --- (In reply to comment #3)
You can get the CrossOver Office which has that feature enabled.
This is not true - CrossOver does not implement subpixel renedring, only grayscale. I asked their support about this and the answer was: "ClearType support is not implemented. At this time we have no plans to work on it". This is quite sad, because this technology (ok, perhaps this is too grand a name) signifcantly influences font display on LCD screens.
Note also that patent issues are somewhat controversial, e.g. most Linux distributions have no problems with shipping software able to do subpixel hinting (e.g. Ubuntu, Fedora etc. - this is standard option in Gnome fonts configuration dialogs etc.). If you are really concerned, this should be available as an option (e.g. even if this is a real problem - and I doubt it - it would be completely irrelevant in all European countries, where software patents are "prohibited" by law).
In effect e.g. in Ubuntu all applications (Firefox, Evolution, Nautilus etc.) can use subpixel font rendering. Notable exceptions are wine apps and OpenOffice, which does not rely on fontconfig, but uses own, statically linked version of freetype (and many people - myself included - hoped to use MS Word, or even Windows version of OOo in wine, to get subpixel capable document editor on Linux - but alas...).
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #6 from Austin English austinenglish@gmail.com 2008-06-12 13:17:56 --- Is this still an issue in current (1.0-rc4 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=10342
Erik Johnson junk1112@new.rr.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |junk1112@new.rr.com
--- Comment #7 from Erik Johnson junk1112@new.rr.com 2008-07-19 23:00:08 --- (In reply to comment #6)
Is this still an issue in current (1.0-rc4 or newer) wine?
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.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #8 from Dmitry Timoshkov dmitry@codeweavers.com 2008-07-20 07:24:28 --- Freetype does not support ClearType, you may want to redirect your request to FT developers.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #9 from Steven Edwards winehacker@gmail.com 2008-07-20 09:06:41 --- It DID have support for it but it was disabled and possibly removed due to patent worries. See
http://david.freetype.org/cleartype-patents.html http://www.linux-watch.com/news/NS6944795565.html
There seems to be other methods to do enhance LCD rendering using XFT and Cairo. Even if the code is still enabled in FreeType my understanding from discussions with Huw was that Wine would need some more infrastructure to use it if it was enabled.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #10 from Erik Johnson junk1112@new.rr.com 2008-07-20 09:41:08 --- (In reply to comment #8)
Freetype does not support ClearType, you may want to redirect your request to FT developers.
I believe that the subpixel rendering is actually enabled in the rasterization step, in libXft or in cairo. Subpixel rendering *is* a defacto setting on most major distros, wherever it is enabled (freetype, xft, whatever... not totally sure). Gnome and KDE's font configuration areas each have options for subpixel rendering.
But redirecting my request to any of those (freetype, xft, cairo) developers will not solve the issue with Wine, because Wine does not respect your system's font settings, whatever they may be. I can tell you that right now on my system, I have freetype, xft, and cairo all using subpixel rendering, and Wine refuses to display the fonts with subpixel rendering. Ths issue *is* with Wine, not with anything else. I've looked at the Wine code that handles font rendering, and can verify that.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #11 from Erik Johnson junk1112@new.rr.com 2008-07-20 11:40:03 --- To add to and clarify from my previous posts:
It looks like the relevant code would be in /dlls/winex11.drv/xrender.c. In fact, it even has this enum in it:
typedef enum { AA_None = 0, AA_Grey, AA_RGB, AA_BGR, AA_VRGB, AA_VBGR, AA_MAXVALUE } AA_Type;
Notice the AA_RGB, AA_BGR, etc. This is for subpixel AA rendering. But, the only ones that are used in the code that follows are AA_None and AA_Grey. So, it appears that somebody did have the idea that it would eventually be implemented. This is issue #1.
Issue #2 is that it seems like Wine is doing its own rasterization of the fonts, and at least on my system, it appears like it's doing "brute force" full hinting of all fonts, even though I have many fonts set to "hintslight" in my .fonts.conf. This is a hinting issue that applies to both aliased and antialiased (grey or subpixel) fonts, but should probably be dealt with at the same time as issue #1.
However, I issued this: strace -F wine notepad 2>&1 | grep "fonts.conf"
...and it does appear that wine is at least reading the ~/.fonts.conf; it's just not respecting everything (or anything?) in it.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #12 from Dmitry Timoshkov dmitry@codeweavers.com 2008-07-21 03:38:45 --- (In reply to comment #10)
I believe that the subpixel rendering is actually enabled in the rasterization step, in libXft or in cairo. Subpixel rendering *is* a defacto setting on most major distros, wherever it is enabled (freetype, xft, whatever... not totally sure). Gnome and KDE's font configuration areas each have options for subpixel rendering. But redirecting my request to any of those (freetype, xft, cairo) developers will not solve the issue with Wine, because Wine does not respect your system's font settings, whatever they may be.
Wine doesn't render fonts on its own, it uses Freetype for that task. Subpixel rendering (or ClearType) must be done by the fonr engine, not by a client application. And since subpixel rendering has been disabled in Freetype due to patent reasons this bug is both invalid and wontfix.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2008-07-21 04:29:48 --- (In reply to comment #12)
Wine doesn't render fonts on its own, it uses Freetype for that task. Subpixel rendering (or ClearType) must be done by the fonr engine, not by a client application. And since subpixel rendering has been disabled in Freetype due to patent reasons this bug is both invalid and wontfix.
The bug seems perfectly valid to me. There's no reason that Wine shouldn't be able to take advantage of subpixel rendering where it's supported.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #14 from Erik Johnson junk1112@new.rr.com 2008-07-22 18:41:29 ---
The bug seems perfectly valid to me. There's no reason that Wine shouldn't be able to take advantage of subpixel rendering where it's supported.
Absolutely. Java, Openoffice.org 3, Firefox, Opera, KOffice, and every other GUI application I run on my system take advantage of subpixel rendering when available. Wine is the only one that doesn't; it's the odd one out.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #15 from Erik Johnson junk1112@new.rr.com 2008-11-13 22:57:14 --- I think the most important thing to point out here is that no potentially patent-infringing code needs to be put into Wine to get the option of subpixel rendering into Wine. That part would be handled by freetype, in which the end user has the option of turning it on or off. Wine just needs to put the hooks in to it.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #16 from Dmitry Timoshkov dmitry@codeweavers.com 2008-11-14 23:18:31 --- FreeType doesn't support ClearType: http://www.nabble.com/GETINFO-instruction-and-subpixel-rendering-td17767051.... https://savannah.nongnu.org/bugs/?18374
subpixel rendering != ClearType.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #17 from Erik Johnson junk1112@new.rr.com 2008-11-15 00:21:59 --- (In reply to comment #16)
FreeType doesn't support ClearType: http://www.nabble.com/GETINFO-instruction-and-subpixel-rendering-td17767051.... https://savannah.nongnu.org/bugs/?18374
subpixel rendering != ClearType.
Right... I don't think anyone except the original poster is disagreeing with that. What I am asking for is subpixel rendering, which freetype *does* support. Your average person is going to get that confused with "Cleartype", because they are similar. Cleartype uses subpixel rendering, but it does more than that too. The potentially patent-infringing code has to do with subpixel rendering, not "Cleartype". But, as I mentioned, Wine does not need to implement any patent-infringing code to get a subpixel-rendering option, as that can be set in freetype. Don't get hung up on the "Cleartype" thing... just pretend that this word wasn't even used in the original post, and only "subpixel rendering" was used.
http://bugs.winehq.org/show_bug.cgi?id=10342
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Implement ClearType also |Add support for SubPixel |known as SubPixel Rendering |font rendering
--- Comment #18 from Dmitry Timoshkov dmitry@codeweavers.com 2008-11-15 02:46:01 --- Changing the summary to reflect the logic.
http://bugs.winehq.org/show_bug.cgi?id=10342
Erik Johnson junk1112@new.rr.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #19 from Erik Johnson junk1112@new.rr.com 2008-11-15 21:15:53 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #20 from Steven Edwards winehacker@gmail.com 2008-11-16 18:47:22 --- (In reply to comment #18)
Changing the summary to reflect the logic.
You know I don't want to get bogged down in a semantical argument but...
include/freetype/config/ftoption.h:
/*************************************************************************/ /* */ /* Uncomment the line below if you want to activate sub-pixel rendering */ /* (a.k.a. LCD rendering, or ClearType) in this build of the library. */ /* */
----------------
And from the thread you posted...
by Werner LEMBERG (core developer of the FreeType font rendering library)
Reply | Reply to Author | Print | View Threaded | Show Only this Message
No. FreeType does *not* support ClearType.
I thought that ClearType is approximately equal to subpixel rendering.
Yes, but the description of the additional `modes' and `features' is far too superficial to be of any value.
But how can you propose a way to inform a font that it is displayed with subpixel rendering?
Well, (horizontal) subpixel rendering has an increased horizontal resolution (by a factor 3) -- I think this is the same for ClearType, but this needs confirmation.
------------
My point in saying Sub-Pixel rendering AKA ClearType was to reduce the number of duplicate bug reports. If this is going to be a WONTFIX debating the merits of my title (which I and apparently the FreeType guys, think is perfectly valid) does nothing to address the problem. People are complaining about the lack of SubPixel Rendering which to them coming from Windows means a lack of ClearType.
If rather than fixing the problem, in software if possible or documentation as a can't/won't fix, the issue is just going to ignored, then I won't bother filing quality bug reports any longer.
http://bugs.winehq.org/show_bug.cgi?id=10342
BlackStar BurnSpamAddress@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |BurnSpamAddress@gmail.com
--- Comment #21 from BlackStar BurnSpamAddress@gmail.com 2008-11-25 06:05:44 --- Maybe this will help clean up the confusion on ClearType vs FreeType:
ClearType is a specific set of proprietary font-rendering algorithms that perform antialiasing, hinting and subpixel rendering. FreeType implements a different set of font-rendering algorithms that also perform antialiasing, hinting and subpixel rendering.
The goal of these algorithms is to improve the appearance of text on the screen. Since the algorithms are different, FreeType output does not exactly match ClearType (some, including me, argue that FreeType provides superior rendering to ClearType).
On modern Linux distributions, the user can select exactly which algorithms FreeType will use. None of these algorithms match ClearType exactly and some of these may be patent-encumbered.
The problem here is that Wine *overrides* the user settings when rendering text and forces either monochrome or grayscale rendering. The point of this bug is to fix Wine so that it renders according to user settings. I have tried to create a patch for this, but failed (it seems that there is code which expects glyphs to be 1- or 8bit pixmaps and cannot cope with 24bpp).
Please note that this fix will not encumber Wine with potentially patented code. This code is contained inside FreeType and has to be explicitly enabled by the user (or the Linux distribution). It will merely allow Wine to follow the rest of the user desktop.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #22 from Erik Johnson junk1112@new.rr.com 2008-11-25 07:53:47 --- Blackstar- Is the patch in a condition where you would want to post it? At the very least, it could serve as a starting point to work from and get people thinking about the issues involved in getting this into Wine.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #23 from BlackStar BurnSpamAddress@gmail.com 2008-11-25 08:35:42 --- I no longer have the patch (it never worked, so I deleted it along with the working directory), but I can describe what I tried to do:
In dlls/winex11.drv/xrender.c, there is an enumeration called "AA_type", which contains all available antialiasing values. Out of those, it seems only AA_None and AA_Grey are ever used.
Using AA_type as a starting point, I modified the function UploadGlyph (around line 602) to acknowledge more AA types (switches on line 614 and 690).
That's about the extent of what I tried to do. From my understanding of the code, we will need to add functions in the spirit of SharpGlyphMono/SharpGlyphGray (what do these do?), enable them in X11DRV_XRender_ExtTextOut (line 1314). We will also need to change GetCacheEntry (line 452) to accept the new AA formats.
It's almost certain that there's a lot more work involved than what I outlined here. Unfortunately, I'm not familiar with Xrender or Wine's internals - anyone familiar with Wine's font rendering code care to share his knowledge?
http://bugs.winehq.org/show_bug.cgi?id=10342
Jonatas Miguel wiseallec@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wiseallec@gmail.com
--- Comment #24 from Jonatas Miguel wiseallec@gmail.com 2008-12-01 12:45:37 --- I believe that subpixel rendering would make a great addition to wine considering how the text in the tabs of Dreamweaver CS4 look like in wine... They look terrible... Some if not all of the letters in these tabs have dropped pixels, it looks awful really, and I'm sure that subpixel font rendering would fix this problem.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #25 from ByeongSik Jeon bsjeon@hanmail.net 2008-12-11 08:55:00 --- Created an attachment (id=17832) --> (http://bugs.winehq.org/attachment.cgi?id=17832) add_support_for_subpixel_font_rendering_001.diff
This patch doesn't add any patent infringing code into the Wine source tree. But, we need to rebuild the FreeType2 library with #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING .
Current libcairo, libxft use the different implementation. But these implementation has the potentially patient infringing problem.
See the http://david.freetype.org/cleartype-patents.html .
http://bugs.winehq.org/show_bug.cgi?id=10342
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #26 from Erik Johnson junk1112@new.rr.com 2008-12-11 20:46:52 --- Wow... thank you very much ByeongSik Jeon. That was an unexpected and welcome surprise. What will it take to get this into Wine?
I successfully applied this patch and compiled wine 1.1.10, using freetype with SPR enabled. I am not however seeing any difference. I followed the regedit information in the patch as well:
"FontSmoothing"="2" ; 0=>Off, 2=>On "FontSmoothingType"=dword:00000002 ; 1=>Standard, 2=>Cleartype "FontSmoothingOrientation"=dword:00000001 ; 0=>BGR, 1=>RGB "FontSmoothingGamma"=dword:00000578
Am I missing something? Thank you again for your excellent contribution!
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #27 from Erik Johnson junk1112@new.rr.com 2008-12-21 14:51:33 --- Ok, for anyone else trying to figure this out... I was able to get SPR working using the above patch, but it only worked if freetype was built with SPR and *without* BCI enabled. In the build of freetype I had with both enabled, SPR did not work and just reverted to grayscale.
Also, on an unrelated note, I find that the full autohint hinting that Wine uses by default looks bad. Here is a patch that forces slight hinting for anyone interested. I don't know much about wine code, so no guarantees that this isn't going to break something. (What I would really like to see is a patch that will use fontconfig (local.conf, fonts.conf, etc.) to determine the hinting on a font by font basis, as well as font replacements. A little beyond me at this point though.)
--- dlls/gdi32/freetype.c 2008-12-11 18:43:27.000000000 -0600 +++ dlls/gdi32/freetype.c.new 2008-12-21 11:54:06.000000000 -0600 @@ -4363,7 +4363,7 @@ FT_Error err; INT left, right, top = 0, bottom = 0, adv, lsb, bbx; FT_Angle angle = 0; - FT_Int load_flags = FT_LOAD_DEFAULT | FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH; + FT_Int load_flags = FT_LOAD_TARGET_LIGHT | FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH; double widthRatio = 1.0; FT_Matrix transMat = identityMat; FT_Matrix transMatUnrotated;
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #28 from Austin English austinenglish@gmail.com 2008-12-22 12:33:12 --- http://source.winehq.org/git/wine.git/?a=commitdiff;h=028617b90ba586bdb30723...
Patch was committed. Please retest and close if appropriate.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #29 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-22 19:54:13 --- Created an attachment (id=18132) --> (http://bugs.winehq.org/attachment.cgi?id=18132) wine subpixel font rendering result of today's build.
with SPR, BCI enabled freetype library.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #30 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-22 19:59:21 --- Created an attachment (id=18133) --> (http://bugs.winehq.org/attachment.cgi?id=18133) SPR, BCI enabled FreeType2 library build.
(In reply to comment #27)
Ok, for anyone else trying to figure this out... I was able to get SPR working using the above patch, but it only worked if freetype was built with SPR and *without* BCI enabled. In the build of freetype I had with both enabled, SPR did not work and just reverted to grayscale.
Hi, Could you test with the attached freetype library build?
$ tar xzf libfreetype6-2.3.7_SPR_BCI.tar.gz $ cd libfreetype6-2.3.7_SPR_BCI $ winecfg
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #31 from Erik Johnson junk1112@new.rr.com 2008-12-22 21:17:21 --- Byeongsik Jeon- It does work correctly. I may have been using a build of freetype that I *thought* had SPR enabled, but did not in fact have it. I ended up rebuilding it on my own again, and it works with that as well. I apologize for the incorrect report!
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #32 from Erik Johnson junk1112@new.rr.com 2008-12-22 21:29:56 --- Created an attachment (id=18134) --> (http://bugs.winehq.org/attachment.cgi?id=18134) Notepad png showing the issue
Hopefully not another false report (!)- I notice that on certain letters, like the "a" or "d" in Arial 9-12 point, that there is a red fringe on the right of the glyph that is not visibly present in other packages (libXft, qt and cairo) that have freetype's SPR enabled. It is subtle, but appears to happen with any glyph that has a vertical stem on the right side of it.
If I am the only one experiencing this, I will chalk it up to something I am doing incorrectly on my end. I just wanted to report it as I haven't been able to get around it.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #33 from Erik Johnson junk1112@new.rr.com 2008-12-22 21:31:04 --- Created an attachment (id=18135) --> (http://bugs.winehq.org/attachment.cgi?id=18135) gedit png which does not have the color fringing issue
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #34 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-22 21:50:25 --- Created an attachment (id=18137) --> (http://bugs.winehq.org/attachment.cgi?id=18137) lcdfilter=FT_LCD_FILTER_LEGACY
(In reply to comment #33)
Created an attachment (id=18135)
--> (http://bugs.winehq.org/attachment.cgi?id=18135) [details]
gedit png which does not have the color fringing issue
I attached a patch. The cairo implementation use this equivalent filter.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #35 from Erik Johnson junk1112@new.rr.com 2008-12-22 22:42:09 --- Thank you for the patch. I had already tried using the various filtering methods in freetype by modifying that line, to no avail. When I do a close-up pixel examination between my two screenshots, it appears that they are identical, except that the farthest left subpixel component and the farthest right subpixel component of some glyphs (in the Notepad one) are being truncated. In other words, the LCD_DEFAULT is rendering as you would expect, but somewhere along the line the glyph is being forced into a box that doesn't allow for the edge FIR subpixels to bleed into it. Let's say the glyph is really 10 pixels wide in mono. In FIR filtering, the glyph may need to be 12 (1+10+1) pixels wide, in order to account for the subpixel averaging that can occur on either side. My guess is that is what is happening here, but I'm not sure if that is happening in your patch, or at some other step. Once again, it's possible that it is only affecting my setup (as seems to be the case with a lot of things!)
Thank you again for your efforts on this!
http://bugs.winehq.org/show_bug.cgi?id=10342
Byeongsik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bsjeon@hanmail.net
--- Comment #36 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-22 23:37:54 --- (In reply to comment #35)
Thank you for the patch. I had already tried using the various filtering methods in freetype by modifying that line, to no avail. When I do a close-up pixel examination between my two screenshots, it appears that they are identical, except that the farthest left subpixel component and the farthest right subpixel component of some glyphs (in the Notepad one) are being truncated. In other words, the LCD_DEFAULT is rendering as you would expect, but somewhere along the line the glyph is being forced into a box that doesn't allow for the edge FIR subpixels to bleed into it. Let's say the glyph is really 10 pixels wide in mono. In FIR filtering, the glyph may need to be 12 (1+10+1) pixels wide, in order to account for the subpixel averaging that can occur on either side. My guess is that is what is happening here, but I'm not sure if that is happening in your patch, or at some other step. Once again, it's possible that it is only affecting my setup (as seems to be the case with a lot of things!)
Thank you again for your efforts on this!
Oh!!! Yes. I understand. It's my mistake.
In my another simple&dirty patch with LCD_DEFAULT, this problem fixed. But For more clean patch, I need the time.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #37 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-23 06:54:12 --- Created an attachment (id=18141) --> (http://bugs.winehq.org/attachment.cgi?id=18141) Dont't truncate the added pixel with FT_LCE_FILTER_DEFAULT.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #38 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-23 07:03:04 --- Created an attachment (id=18142) --> (http://bugs.winehq.org/attachment.cgi?id=18142) Arial 11pt "abcdefghijklmnopqrstuvwxyz"
above: non patched text below: patched test.
http://bugs.winehq.org/show_bug.cgi?id=10342
Byeongsik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18141|Dont't truncate the added |Don't truncate the added description|pixel with |pixel with |FT_LCE_FILTER_DEFAULT. |FT_LCD_FILTER_DEFAULT.
http://bugs.winehq.org/show_bug.cgi?id=10342
Byeongsik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18141|0 |1 is obsolete| |
--- Comment #39 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-23 20:06:01 --- Created an attachment (id=18157) --> (http://bugs.winehq.org/attachment.cgi?id=18157) Don't truncate the added pixel with FT_LCD_FILTER_DEFAULT.
reformated patch for today's wine-git.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #40 from Erik Johnson junk1112@new.rr.com 2008-12-23 20:08:55 --- I applied the patch and it renders the glyphs correctly. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #41 from Erik Johnson junk1112@new.rr.com 2008-12-26 11:56:40 --- Created an attachment (id=18205) --> (http://bugs.winehq.org/attachment.cgi?id=18205) png showing artifcats and kerning issues with fake_italic
Ok, I found one more thing! It appears that glyphs that use fake_italic have kerning and artifact issues. Notice the unusual amount of space between aB and Yy, as well as the blotchy artifacts. I'm guessing this is because the transform isn't taking the LCD changes into account?
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #42 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-26 14:08:56 --- Created an attachment (id=18209) --> (http://bugs.winehq.org/attachment.cgi?id=18209) fake italic arifacts fix.
(In reply to comment #41)
Created an attachment (id=18205)
--> (http://bugs.winehq.org/attachment.cgi?id=18205) [details]
png showing artifcats and kerning issues with fake_italic
Ok, I found one more thing! It appears that glyphs that use fake_italic have kerning and artifact issues. Notice the unusual amount of space between aB and Yy, as well as the blotchy artifacts. I'm guessing this is because the transform isn't taking the LCD changes into account?
Thank you!!! I think this patch will fix this problem.
http://bugs.winehq.org/show_bug.cgi?id=10342
Byeongsik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18209|0 |1 is obsolete| |
--- Comment #43 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-26 14:27:17 --- Created an attachment (id=18210) --> (http://bugs.winehq.org/attachment.cgi?id=18210) fake italic arifacts fix #2.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #44 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-26 14:30:00 --- (In reply to comment #43)
Created an attachment (id=18210)
--> (http://bugs.winehq.org/attachment.cgi?id=18210) [details]
fake italic arifacts fix #2.
I'm sorry... This patch is wrong. I need more test.
http://bugs.winehq.org/show_bug.cgi?id=10342
Byeongsik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18210|0 |1 is obsolete| |
--- Comment #45 from Byeongsik Jeon bsjeon@hanmail.net 2008-12-26 21:32:09 --- Created an attachment (id=18226) --> (http://bugs.winehq.org/attachment.cgi?id=18226) Fix the fake_italic kerning and artifacts issue #3.
I attached a patch for this problem.
"kerning issue" seems a kerning problem, but it's not. It's the rendering problem. The bitmap image by FT_Render_Glyph() is trimed image using FT_Outline_Get_CBox() in the FreeType2 library.
Thank you for your report. Please, I hope your test.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #46 from Erik Johnson junk1112@new.rr.com 2008-12-26 22:05:55 --- Yes, the patch works. Thanks again!
http://bugs.winehq.org/show_bug.cgi?id=10342
Jaime Rave jaimerave@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jaimerave@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=10342
Dan C djc+bugs@djc.id.au changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |djc+bugs@djc.id.au
http://bugs.winehq.org/show_bug.cgi?id=10342
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org
--- Comment #47 from Scott Ritchie scott@open-vote.org 2009-05-05 06:27:29 --- So, any updates on the status of these patches in Wine proper?
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #48 from Erik Johnson junk1112@new.rr.com 2009-05-05 20:06:36 --- (In reply to comment #47)
So, any updates on the status of these patches in Wine proper?
They should be in there now, as of a few releases ago, AFAIK.
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #49 from Scott Ritchie scott@open-vote.org 2009-05-06 03:45:28 --- Is this fixed then? Or do we still need to do more (eg use system's subpixel font preferences)
http://bugs.winehq.org/show_bug.cgi?id=10342
--- Comment #50 from Austin English austinenglish@gmail.com 2009-11-19 11:18:00 --- (In reply to comment #49)
Is this fixed then? Or do we still need to do more (eg use system's subpixel font preferences)
I believe that is still the case (support is present, but not enabled by default/detected from system preferences).
http://bugs.winehq.org/show_bug.cgi?id=10342
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #51 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-23 06:45:59 --- (In reply to comment #50)
I believe that is still the case (support is present,
This bug is fixed then.
but not enabled by default/detected from system preferences).
That's the bugs 16729 and 17148.
http://bugs.winehq.org/show_bug.cgi?id=10342
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #52 from Alexandre Julliard julliard@winehq.org 2009-12-04 12:15:17 --- Closing bugs fixed in 1.1.34.
-
wine-bugs＠winehq.org