Hello, I'm used to the nice anti-aliased fonts in my system, including web pages. But today I updated my system, which pulled in a package called wine-tahoma-fonts. It contains True Type Tahoma fonts which I understand are important for some Windows applications. Problem is, now every page that sets font as for example "Verdana, Tahoma, Something, sans-serif" looks really bad with those pixelated fonts, esp. if only a few elements on a perfectly smooth page look like this (like http://www.theugc.it/results_ql.php which uses Tahoma for 3 lines of text and they really stand out). Either make those fonts anti-aliased like everything else in the system, or make web browsers (I tested SeaMonkey and Firefox) ignore them somehow. I think making the fonts mandatory for every WINE installation is a very good thing, just make it not interfere with the rest of the system. For now, I just did rpm -e --nodeps and my system is back to normal. I use Wine only to test my cross-compiled program and it still works without this package.
same here, wine-tahoma-fonts.noarch 0:1.3.16-1.fc14 messed up fonts in firefox i think wine fonts should be available in wine applications only at least rename them to "Wine fonts" family, then browser won't use them as normal Tahoma
i tried to update all wine* packages from @updates-testing same problem with wine-tahoma-fonts.noarch 1.3.17-1.fc14
See https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/412195 - it seems ubuntu tried turning off embedding bitmaps but the wine-supplied tahoma still has problems, so in the end they made tahoma a wine-specific font. See http://bugs.winehq.org/show_bug.cgi?id=26037 for another bug that makes wine-tahoma screw up the web.
Created attachment 489793 [details] file blacklisting tahoma, from ~/.fonts.conf.d/ I've found I can work around this for now by blacklisting tahoma, without needing to remove wine - see the attached file. I've put in ~/.fonts.conf.d/ rather than appending the rule to ~/.fonts.conf
First I want to state that this is not really tahoma bug but rather at best a missing feature. If a webpage explicitly requests tahoma and it is installed it will be chosen. I understand that it should look 'nicer'. I will include the fontconfig script mentioned above to turn of embedded bitmaps per default. As pointed out if you don't like tahoma you can turn it of in your font configuration. This will be added to a readme.
From where I'm sitting, it looks like a packaging bug. Websites may ask for tahoma, but isn't that partly because of entrenched microsoft mindshare? If they request it, surely they're expecting MS's tahoma rendered by the MS font stack, not wine's incomplete tahoma copy rendered by freetype. Meanwhile, distributions and desktops have gone to some effort to make the web look good out of the box. The system browser's font rendering shouldn't change as a side-effect of installing wine (though arguably pulling in a hypothetical well-tested liberation-tahoma could be acceptable). Users who really want MS fonts in their web browser have the option available to them - and they definitely have better options than wine's poor copy. Note that it's not readily apparent that wine-tahoma is the cause of the change, only 'yum history' and web searches clued me in. Finally, turning off embedded bitmaps makes things worse - it reveals the bug that bold is indistinguishable from regular.
I wonder how this is a packaging bug. Wine provides the tahoma font. Fonts in fedora are handled via fontconfig. The package deploys the font where it should be located at for fontconfig. Seems like this how a font should be packaged. I cannot follow your reasoning. Go ahead and try to remove the libration/dejavu/... fonts and see how your web rendering will change then. If you do not like the tahoma font disable it. If you think you do not need it at all remove it from you system. Your mileage on windows apps through wine may vary. Embedded bitmaps, however, are always a taste issue and I am willing to turn this of. Aside from the 'bold' bug, which obviously is a bug, this should 'improve' you experience.
# yum remove wine-tahoma-fonts Loaded plugins: presto, refresh-packagekit, security Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package wine-tahoma-fonts.noarch 0:1.3.16-1.fc13 set to be erased --> Processing Dependency: wine-tahoma-fonts = 1.3.16-1.fc13 for package: wine-fonts-1.3.16-1.fc13.noarch --> Running transaction check ---> Package wine-fonts.noarch 0:1.3.16-1.fc13 set to be erased --> Processing Dependency: wine-fonts = 1.3.16-1.fc13 for package: wine-1.3.16-1.fc13.x86_64 --> Running transaction check ---> Package wine.x86_64 0:1.3.16-1.fc13 set to be erased --> Finished Dependency Resolution Dependencies Resolved ===================================================================================================================== Package Arch Version Repository Size ===================================================================================================================== Removing: wine-tahoma-fonts noarch 1.3.16-1.fc13 @updates 203 k Removing for dependencies: wine x86_64 1.3.16-1.fc13 @updates 0.0 wine-fonts noarch 1.3.16-1.fc13 @updates 0.0 Transaction Summary ===================================================================================================================== Remove 3 Package(s) Installed size: 203 k Is this ok [y/N]:
> If you think you do not need it at all remove it from you system. > Your mileage on windows apps through wine may > vary. Give us the possibility to use wine without wine-tahoma-fonts, please. And since this package contains system-wide fonts it is better to call it "tahoma-fonts" then "wine-anything".
wine and wine-fonts are just meta packages, They will not harm how wine will function. You just need to keep track then for changes to the package (new subpackages e.g.).
(In reply to comment #10) > wine and wine-fonts are just meta packages, They will not harm how wine will > function. You just need to keep track then for changes to the package (new > subpackages e.g.). Right. Which is why removing the metapackages is a worse workaround than blacklisting the font by hand. But they're both workarounds and neither are ideal.
(In reply to comment #7) > I wonder how this is a packaging bug. Wine provides the tahoma font. Well, actually it provides an imitation of the Tahoma font. Unfortunately, this imitation is imperfect. Since, at present, it is not a drop-in replacement for the real Tahoma, it is debatable whether it should be dropped-in.
Created attachment 489938 [details] Blacklist only wine-tahoma Fontconfig to blacklist only wine-tahoma-font.
wine-1.3.17-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/wine-1.3.17-2.fc14
wine-1.3.17-2.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/wine-1.3.17-2.fc13
wine-1.3.17-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/wine-1.3.17-2.fc15
Package wine-1.3.17-2.fc13: * should fix your issue, * was pushed to the Fedora 13 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing wine-1.3.17-2.fc13' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/wine-1.3.17-2.fc13 then log in and leave karma (feedback).
(In reply to comment #5) > If a webpage explicitly requests tahoma and it is installed it > will be chosen. All webpages which I checked with Firebug explicitly requested... Verdana. Tahoma was only provided as a backup and I'm convinced their creators never even tried how the page would look with Tahoma (note: Tahoma is wider than Verdana). According to http://www.codestyle.org/servlets/FontStack?stack=Verdana%2CTahoma&generic=sans-serif (first hit in Google), 99,64% Windows users will see such page rendered with Verdana. Probability of seeing Verdana on Linux is interestingly high, but it's exactly 0,00% for Tahoma. In other words, nobody really wants to see their page being rendered in Tahoma, they just copy&paste "best practices", assuming this font will _never_ be used. So from my perspective, to really do what content creators want, you should provide Verdana before you think of adding Tahoma to my web browser.
This update fixes it for me in most cases, but not in all. There still remains some text on web pages whos text is "strange" Tahoma. How exactly is this fixed?
I see now: - disable embedded bitmaps in tahoma (#693180) - provide readme how to disable wine-tahoma in fontconfig (#693180) Well, the problematic texts are numbers (digits). This way we are asking all users of Fedora that are using wine to change fontconfig? If this tahoma would be really Tahoma, I'd have probably nothing against it. But this is not tahoma, right?
If wine is going to mess up with the system fonts, it should not be allowed to package such fonts. There must be a way that wine can make use of such fonts that doesn't affect the rest of the system. Perhaps avoiding fontconfig, or perhaps prefixing with something (e.g. WineTahoma). Also, probably blacklisting doesn't solve anything, because then Wine wouldn't be able to use the fonts, so what's the point of the packages then?
wine-1.3.17-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
wine-1.3.17-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
wine-1.3.17-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
I'm not sure what kind of fix this should bring, but the problem still persists - at least numbers are still replaces with inapropriate tahoma digits from wine. If I disable the wine-tahoma font as per README, what is then purpose of this font? Is it further available to wine or not? If it is not, then I'd like to see wine compiled without a dependency on wine-tahoma at least.
Created attachment 496748 [details] Screenshot showing the problem Proper rendering on the left hand side, with wine-tahoma-fonts installed on the right hand side. The main problem is that wine-tahoma-fonts provides a font which is plainly ugly as compared to the one from msttcorefonts.
If you wish to disable Tahoma from being available to other applications while being usable in Wine, you can move the tahoma*.ttf files from /usr/share/fonts/wine-tahoma-fonts to /usr/share/wine/fonts. It seems like Ubuntu resorted to this after having users complain about this problem.
Doesn't look like anybody is interested in fixing this. WONTFIX?
I just installed wine on Fedora 17 and Facebook rendering is now disgusting. (In reply to comment #27) > If you wish to disable Tahoma from being available to other applications > while being usable in Wine, you can move the tahoma*.ttf files from > /usr/share/fonts/wine-tahoma-fonts to /usr/share/wine/fonts. It seems like > Ubuntu resorted to this after having users complain about this problem. Great comment. Andreas Bierfert, please make all wine fonts install to /usr/share/wine/fonts instead of system-wide font directory and this problem is solved. And it is the proper solution anyway.
Andreas, can you please comment why this is closed as NOTABUG? The font definitely makes webpages look ugly. Why can't we package wine-specific fonts in wine-specific directories? If anyone requested this font to be installed system-wide (I seriously doubt that) we could make a separate package for it (not prefixed with "wine-"). Installing wine currently impairs user experience with Fedora and it does not happen with other distributions like Ubuntu. I remember several persons saying they prefer Ubuntu to Fedora because the fonts are much more readable. Only now I understand that they might have wine installed and that could be the reason. We need to improve the situation here.
While I do not have a rawhide, this bug is now reported against, if the thing still happens, I agree with Karel. When I install wine, I do NOT intentionally install a broken tahoma font, that makes half the pages made for IE look terribly. This can not be fixed with readme.
I changed version to Rawhide because it's not an issue of a specific release, it's a general issue of the package.
Please refer to comment 7. The explanation is still valid and has not changed. If you are interested in changing the wine tahoma font please get involved with upstream wine.
Please show a little sympathy with users affected by this bug. Maybe you don't care, maybe you have a lot of other work on your plate and this is a nuisance for you. But a lot of users are affected by it and unhappy about it. A lot of them might not know how to solve it other than uninstalling wine. A lot of them might not know it is caused by wine and blame Fedora in general. I don't think it deserves to be closed. It *is* a problem - we might argue whether it is a packaging problem, font rendering problem, font itself problem - but it is a problem. Tahoma rendering is ugly. Making the font wine-specific is easy (it's even _called_ wine-tahoma-fonts). It will improve the situation for lots of people. It will hardly harm anyone. We already create /usr/share/wine/fonts, but we don't use it for anything. Why do you object using this approach? That is not explained in comment #7. Please elaborate, thank you.
This is my last comment on the bug as bugzilla is not a discussion platform. Feel free to contact me directly. First let me state this clearly one more time: This is _not_ a bug. It is a matter of taste (as the word ugly points out nicely). The fonts provided and included in wine (an this is not limited to tahoma) were made to provide a good user experience in wine. However, they are ordinary fonts and in every way the same as every other font in fedora. This is why they should and are handled in the same way. I do understand and sympathize that some users may not like the look of wine tahoma and that is perfectly alright. For these users an explanation on how to disable it has been added to the package documentation. It is also easily possible to remove the font from the system: `yum remove wine-tahoma-fonts` This may, however, impact your wine user experience. If you encounter these effects you may want to tweak wine with a replacement font of your liking. /usr/share/wine/fonts has not been used for shipped fonts since wine-1.1.41-2 (~2 years ago) as the fonts have been moved wrt the font packaging guidelines. It is still around for compatibility reasons.
It's not a matter of taste that this font doesn't have bold version. The font itself is not ugly and it's not about users not liking the look of it! But because bold doesn't work on so many web pages, it really breaks the user experience. And your comment #7 confirms it's a bug. And the bug sets this font apart from all the other ordinary fonts in the system, which is good enough reason for other distributions to treat it differently.
Made an interesting discovery in http://bugs.winehq.org/show_bug.cgi?id=26037 - removing tahomabd.ttf from /usr/share/fonts/wine-tahoma-fonts/ (leaving just tahoma.ttf) makes bold work again. Not sure what impact this has with embedded bitmaps re-enabled, I didn't think to investigate this at the time.
I just verified a workaround that will avoid the bad web page results from updates reinstalling wine-tahoma-fonts. I verified by putting tahoma.ttf and tahomabd.ttf from msttcorefonts in ~/.fonts, loading http://fm.no-ip.com/Auth/Font/font-tahoma.html in FF, taking a screenshot, then closing FF. Then I renamed ~/.fonts, did yum install wine-tahoma-fonts, reloaded the page to see the subject poor numerals and lack of bold, took another screenshot, and closed FF again. Last I restored ~/.fonts, restarted FF and reloaded the page. The reload matched the first screenshot of "good" Tahoma fonts.
Tested with embedded bitmaps re-enabled and this time tahomabd.ttf hides bold for all sizes except 9pt. Without tahomabd.ttf, are there any remaining issues with the embedding-disabled version of wine-tahoma? I don't have the msttcorefonts for comparison but I don't see the defects(*) mentioned in comment #38 on http://fm.no-ip.com/Auth/Font/font-tahoma.html when I switch embedded bitmaps back off. * another defect I noticed with embedded bitmaps is 14pt tahoma being darker than 15pt and 16pt sizes.
There has been a discussion about this issue on the devel list [1]. Andreas agreed he would split WineTahoma font into wine-tahoma-fonts and wine-tahoma-fonts-system packages. The first one would be installed to the wine-specific font directory and would be a dependency for the wine package, the second one would be installed into a system-wide font directory and would be optional. The split should be part of 1.5.6 wine update. Reopening so that we can track the resolution. Thanks, Andreas, for being interested in the discussion. [1] http://lists.fedoraproject.org/pipermail/devel/2012-June/168153.html
wine-mono-0.0.4-7.fc17,wine-1.5.8-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/wine-mono-0.0.4-7.fc17,wine-1.5.8-1.fc17
wine-1.5.8-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/wine-1.5.8-1.fc16
Package wine-mono-0.0.4-7.fc17, wine-1.5.8-1.fc17, mingw-wine-gecko-1.6-1.fc17, mingw-crt-2.0.999-0.6.trunk.20120601.fc17, mingw-headers-2.0.999-0.6.trunk.20120601.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing wine-mono-0.0.4-7.fc17 wine-1.5.8-1.fc17 mingw-wine-gecko-1.6-1.fc17 mingw-crt-2.0.999-0.6.trunk.20120601.fc17 mingw-headers-2.0.999-0.6.trunk.20120601.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10358/mingw-wine-gecko-1.6-1.fc17,mingw-crt-2.0.999-0.6.trunk.20120601.fc17,mingw-headers-2.0.999-0.6.trunk.20120601.fc17,wine-mono-0.0.4-7.fc17,wine-1.5.8-1.fc17 then log in and leave karma (feedback).
wine-mono-0.0.4-7.fc17, wine-1.5.8-1.fc17, mingw-wine-gecko-1.6-1.fc17, mingw-crt-2.0.999-0.6.trunk.20120601.fc17, mingw-headers-2.0.999-0.6.trunk.20120601.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
wine-1.5.8-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Can someone please point me to where the "package documentation" explains how to work around this problem? Currently experiencing the same problem with fontname "Courier", as one of Wine's bitmapped fonts is now the system preferred font for Courier, and the bitmapped font is *NOT* happy with Unicode. (See bug# 693180.)
(In reply to Adam Thompson from comment #46) > (See bug# 693180.) Sorry, I meant bug# 1039763.
(In reply to Adam Thompson from comment #46) > Can someone please point me to where the "package documentation" explains > how to work around this problem? > > Currently experiencing the same problem with fontname "Courier", as one of > Wine's bitmapped fonts is now the system preferred font for Courier, and the > bitmapped font is *NOT* happy with Unicode. > > (See bug# 693180.) Not sure there is anything in the documentation, but comment 4 has some workaround. Sadly the only 100% "workaround" is to remove wine completely. See comment 35 form maintainer at that time.
Comment #46 is referring to Andreas Bierfert's comment #35 where he mentions a note in the "package documentation". Not sure what command we can use to see that note. Since the problem in bug #1039763 is similar to this bug, but *worse* because it actually draws incorrect glyhps on the screen (and so is not simply a subjective "cosmetic" issue), could not the solution arrived it for this bug in comment #40 (a separate -system rpm in /usr/share/fonts/wine for the insane, vs a sane rpm in /usr/share/wine/fonts) be applied to bug #1039763? Further discussion should be moved to bug #1039763 I suppose. (All watchers of this bug are welcome to join us there!)