Stop-ship 0.9 problem
There is a serious problem with Wine 0.9 as-is, namely that we now respect Windows antialiasing settings. If you have a patented bytecode hinter enabled FreeType, things look OK: http://plan99.net/~mike/files/hinted-fonts.jpg but if you don't (like 99% of Linux users): http://www.republika.pl/belegdol/temp/wine.png Needless to say we can't ship 0.9 when it'll look like that for most users. The attached patch fixes the issue by providing an override for antialiasing. FreeType AA makes the fonts look good again at small sizes. It also changes the logic on one line - I may be mistaken but it looked wrong to my eye: - if(!get_gasp_flags(physDev, &flags) || flags & GASP_DOGRAY) + if(get_gasp_flags(physDev, &flags) && (flags & GASP_DOGRAY)) We can patch this variable in Crossover (where CW ship a licensed freetype copy) so the correct AA settings are used which (a) looks nicer and (b) makes font metrics correct. A better long term solution suggested by Krzysztof Foltman might be to make bitmapped copies of a hinted Tahoma at small sizes, for instance. thanks -mike Index: dlls/x11drv/xrender.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/xrender.c,v retrieving revision 1.74 diff -u -p -d -r1.74 xrender.c --- dlls/x11drv/xrender.c 23 Sep 2005 10:05:54 -0000 1.74 +++ dlls/x11drv/xrender.c 1 Oct 2005 22:48:10 -0000 @@ -100,6 +100,12 @@ static INT mru = -1; static int antialias = 1; +/* we need this for WineHQ because antialiasing is necessary to cover + * up for deficiencies in the FreeType auto-hinter (a pox upon Apple + * for not releasing the patent royalty free. It expires sometime + * around 2009) */ +static BOOL force_always_antialias = TRUE; + /* some default values just in case */ #ifndef SONAME_LIBX11 #define SONAME_LIBX11 "libX11.so" @@ -442,7 +448,7 @@ static BOOL get_gasp_flags(X11DRV_PDEVIC GetTextMetricsW(physDev->hdc, &tm); ppem = abs(X11DRV_YWStoDS(physDev, tm.tmAscent + tm.tmDescent - tm.tmInternalLeading)); - gasp++; + gasp++; /* skip version field */ num_recs = get_be_word(*gasp); gasp++; while(num_recs--) @@ -474,15 +480,25 @@ static int GetCacheEntry(X11DRV_PDEVICE assert( !entry->format[format] ); } - if(antialias && plfsz->lf.lfQuality != NONANTIALIASED_QUALITY) + if (force_always_antialias) { - if(!get_gasp_flags(physDev, &flags) || flags & GASP_DOGRAY) - entry->aa_default = AA_Grey; + entry->aa_default = AA_Grey; + } + else + { + if ((antialias && plfsz->lf.lfQuality != NONANTIALIASED_QUALITY)) + { + if(get_gasp_flags(physDev, &flags) && (flags & GASP_DOGRAY)) + entry->aa_default = AA_Grey; + else + entry->aa_default = AA_None; + } else + { entry->aa_default = AA_None; + } } - else - entry->aa_default = AA_None; + return ret; }
"Mike Hearn" <mike(a)plan99.net> wrote:
There is a serious problem with Wine 0.9 as-is, namely that we now respect Windows antialiasing settings.
That's not a Wine problem, that's a correct behaviour.
If you have a patented bytecode hinter enabled FreeType, things look OK:
http://plan99.net/~mike/files/hinted-fonts.jpg
but if you don't (like 99% of Linux users):
http://www.republika.pl/belegdol/temp/wine.png
Needless to say we can't ship 0.9 when it'll look like that for most users.
I'd argue that it's not a Wine problem/bug at all, we can do nothing to improve hinting support in FreeType. And crippling Crossover (by making it differ with WineHQ for no good reason) because of that is not a way to go IMO. In any case if a Wine user wants to see correctly displayed TrueType fonts with correct document layout (as it depends on the rendered glyph metrics) he/she has to use patented FreeType. And that's for sure the problem of a Linux distro vendor who must take care of it. -- Dmitry.
Saturday, October 1, 2005, 10:21:21 PM, Dmitry Timoshkov wrote:
I'd argue that it's not a Wine problem/bug at all, we can do nothing to improve hinting support in FreeType. And crippling Crossover (by making it differ with WineHQ for no good reason) because of that is not a way to go IMO. I would strongly disagree. Wine is not a CrossOver Office. We all do appreciate what you guys doing for wine. But this is an open source project and there is no good reasons to brake it so Crossover can use the same piece of code with extra additions. Or having barely readable fonts is not a good enough reason for you?
In any case if a Wine user wants to see correctly displayed TrueType fonts with correct document layout (as it depends on the rendered glyph metrics) he/she has to use patented FreeType. And that's for sure the problem of a Linux distro vendor who must take care of it. That doesn't help either. Just as a test, I copied windows fonts and they were looking same bad. So this _is_ a wine problem and please don't shift the blame around.
Bottom line we have to fix. Users started to complain immediately after 20050930 was out. Even if it's not 100% correct we still cant cripple the Wine with such an ugly fonts. Vitaliy
On Sat, Oct 01, 2005 at 10:42:34PM -0600, Vitaliy Margolen wrote:
Bottom line we have to fix. Users started to complain immediately after 20050930 was out. Even if it's not 100% correct we still cant cripple the Wine with such an ugly fonts.
The only problem I see is with people having a self-compiled FreeType library with hinting enabled. Why cripple their configuration too by default ? Is there no way to detect at compile / run-time what kind of FreeType library we link with ? Or, at the very least, let this be configurable in winecfg (or in the registry) as it does not seem to be the case with Mike's patch. Lionel -- Lionel Ulmer - http://www.bbrox.org/
On Sun, Oct 02, 2005 at 08:19:58AM +0200, Lionel Ulmer wrote:
The only problem I see is with people having a self-compiled FreeType library with hinting enabled. Why cripple their configuration too by default ?
Is there no way to detect at compile / run-time what kind of FreeType library we link with ? Or, at the very least, let this be configurable in winecfg (or in the registry) as it does not seem to be the case with Mike's patch.
Full ACK! Ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.
On Sun, 2 Oct 2005, Lionel Ulmer wrote: [...]
The only problem I see is with people having a self-compiled FreeType library with hinting enabled. Why cripple their configuration too by default ?
Yes, why cripple Wine for people using a real Linux distribution like Debian. ;-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.
On Sun, Oct 02, 2005 at 08:19:58AM +0200, Lionel Ulmer wrote:
The only problem I see is with people having a self-compiled FreeType library with hinting enabled. Why cripple their configuration too by default ?
Is there no way to detect at compile / run-time what kind of FreeType library we link with ? Or, at the very least, let this be configurable in winecfg (or in the registry) as it does not seem to be the case with Mike's patch.
We need to determine this at runtime really. I have come up with a way, but it's a bit of a hack - I've asked on the freetype list for a better solution. Once I have that I'll add a Wine specific bit to the flags returned by GetRasterizerCaps, x11drv can query this and take the appropriate action. Huw.
On Sun, 02 Oct 2005 13:21:21 +0900, Dmitry Timoshkov wrote:
That's not a Wine problem, that's a correct behaviour.
This is a reasonable argument, but for such a user visible and annoying problem I think we have to make this a special case.
I'd argue that it's not a Wine problem/bug at all
I'd argue that it's not a Wine bug, but it's definitely a Wine problem. Many people will judge the last 10 years of effort on the basis of this release - first impressions matter and if it looks unusably ugly out of the box then peoples first impressions will be poor.
We can do nothing to improve hinting support in FreeType.
Hmm, are we sure? Maybe it would be possible to improve the bytecode hinter. But, not in time for 0.9 of course, for which the only reasonable solution is to force antialiasing to be on by default.
And crippling Crossover (by making it differ with WineHQ for no good reason) because of that is not a way to go IMO.
The differential would be a single line, we deal with much more complex differences all the time.
In any case if a Wine user wants to see correctly displayed TrueType fonts with correct document layout (as it depends on the rendered glyph metrics) he/she has to use patented FreeType. And that's for sure the problem of a Linux distro vendor who must take care of it.
As it costs money per unit, and most Linux distros don't, I guess we won't be seeing hinter enabled distros anytime soon. thanks -mike
"Mike Hearn" <mike(a)plan99.net> wrote:
In any case if a Wine user wants to see correctly displayed TrueType fonts with correct document layout (as it depends on the rendered glyph metrics) he/she has to use patented FreeType. And that's for sure the problem of a Linux distro vendor who must take care of it.
As it costs money per unit, and most Linux distros don't, I guess we won't be seeing hinter enabled distros anytime soon.
Just 2 comments to the above quote: 1. As far as I know licensing patented hinting technology from Apple is a 1 time cost, and not huge amount of money at all. 2. Europe has said no software patents, so I see this thread a bit rediculus when most peolple who argues for crippling Wine instead of enabling the hinter live in Europe. Have you asked your Linux vendor to enable/license truetype hinter in FreeType? If not yet, it's time to do so. -- Dmitry.
On Mon, 2005-10-03 at 09:17 +0900, Dmitry Timoshkov wrote:
1. As far as I know licensing patented hinting technology from Apple is a 1 time cost, and not huge amount of money at all.
This makes no difference, as it will not allow others to redistribute the distro, which makes it a non-options for shops like RedHat.
2. Europe has said no software patents, so I see this thread a bit rediculus when most peolple who argues for crippling Wine instead of enabling the hinter live in Europe.
Sorry Dmitry, but to me it seems ridiculous to argue against a fairly well known fact. The AA TrueType fonts has been an ongoing problem for _years_ with no solution in sight, whereas our Wine 0.9 release should be available in a matter of weeks. Given the short time frame, it's not an option to change they way the world works to conform to our liking. It's just not gonna happen. At most we can hope for is to piss a lot of people off and look like we don't have a sense of reality.
Have you asked your Linux vendor to enable/license truetype hinter in FreeType? If not yet, it's time to do so.
This has been brought up many times (at least on RH related lists). It is not an option, and for good reasons. Let's just deal with it, and run like bandits :) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
"Dimi Paun" <dimi(a)lattica.com> wrote:
Sorry Dmitry, but to me it seems ridiculous to argue against a fairly well known fact. The AA TrueType fonts has been an ongoing problem for _years_ with no solution in sight, whereas our Wine 0.9 release should be available in a matter of weeks. Given the short time frame, it's not an option to change they way the world works to conform to our liking.
It's just not gonna happen. At most we can hope for is to piss a lot of people off and look like we don't have a sense of reality.
It looks like FreeType has some bug fixes in that area, at least I've found this one in the changelog: LATEST CHANGES BETWEEN 2.1.10 and 2.1.9 - Another serious bug in handling TrueType hints caused many distortions. It has been introduced in version 2.1.8, and it is highly recommended to upgrade. There are some other fixes in hinting handling including autohinter bug fixes, so it's worth to upgrade to the latest/CVS FreeType and see if it helps Wine as well.
Have you asked your Linux vendor to enable/license truetype hinter in FreeType? If not yet, it's time to do so.
This has been brought up many times (at least on RH related lists). It is not an option, and for good reasons. Let's just deal with it, and run like bandits :)
Could you enlighten me by listing those "good reasons" here? I suspect that the real "problem" with licensing the patented technologies in Linux is a general stance of GPL and Linux crowd regarding software patents making them "non-free". -- Dmitry.
On Mon, 2005-10-03 at 21:46 +0900, Dmitry Timoshkov wrote:
Could you enlighten me by listing those "good reasons" here? I suspect that the real "problem" with licensing the patented technologies in Linux is a general stance of GPL and Linux crowd regarding software patents making them "non-free".
IIRC the reason Red Hat gives is that even if they license the technology, it would mean legal problems for their customers since they will not be able to redistribute the product further (i.e. Fedora Core) Regardless, it doesn't really matter. Personally I would prefer to have the hinter on, believe me, but Red Hat would not budge, and they are a very popular distribution. The release is too close to change anything. Even if every distro decides to buy the license, it still wouldn't change anything, as it would take a while to get that onto people's machines. Let's make sure Wine works well on the majority of boxes, and those don't have the hinter enabled (I used to compile the freetype RPM myself but I gave up since after each yum-update that updated it the system would look crappy). We can have a registry setting for that, if people can recompile freetype, they can tweak wine. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
On Sat, Oct 01, 2005 at 11:53:09PM +0100, Mike Hearn wrote: ...
It also changes the logic on one line - I may be mistaken but it looked wrong to my eye:
- if(!get_gasp_flags(physDev, &flags) || flags & GASP_DOGRAY) + if(get_gasp_flags(physDev, &flags) && (flags & GASP_DOGRAY))
The idea was to enable antialiasing if either the gasp table was missing or if the gasp table tell us to do so. It seems unlikely that a font designer would have gone to the trouble of adding hinting instructions but not the tiny gasp table. Actually I couldn't find a font without a gasp table to test what Windows does in this situation. Huw.
Huw D M Davies wrote:
The idea was to enable antialiasing if either the gasp table was missing or if the gasp table tell us to do so. It seems unlikely that a font designer would have gone to the trouble of adding hinting instructions but not the tiny gasp table. Actually I couldn't find a font without a gasp table to test what Windows does in this situation.
Ah, OK, so the logic was right then. Apologies.
participants (8)
-
Dimi Paun -
Dmitry Timoshkov -
Francois Gouget -
Huw D M Davies -
Joerg Mayer -
Lionel Ulmer -
Mike Hearn -
Vitaliy Margolen