Bug 693180 - wine-tahoma-fonts break webpage rendering
wine-tahoma-fonts break webpage rendering
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: wine (Show other bugs)
rawhide
i686 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Andreas Bierfert
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-03 07:51 EDT by Leszek Matok
Modified: 2014-01-22 04:46 EST (History)
22 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-10 16:53:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
file blacklisting tahoma, from ~/.fonts.conf.d/ (251 bytes, application/xml)
2011-04-04 11:14 EDT, Oliver Henshaw
no flags Details
Blacklist only wine-tahoma (224 bytes, text/plain)
2011-04-05 04:21 EDT, Jaroslav Škarvada
no flags Details
Screenshot showing the problem (17.51 KB, image/png)
2011-05-04 06:19 EDT, Julian Sikorski
no flags Details

  None (edit)
Description Leszek Matok 2011-04-03 07:51:13 EDT
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.
Comment 1 Aleksandra Fedorova 2011-04-03 19:45:39 EDT
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
Comment 2 Aleksandra Fedorova 2011-04-03 20:19:13 EDT
i tried to update all wine* packages from @updates-testing

same problem with wine-tahoma-fonts.noarch  1.3.17-1.fc14
Comment 3 Oliver Henshaw 2011-04-04 10:56:52 EDT
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.
Comment 4 Oliver Henshaw 2011-04-04 11:14:37 EDT
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
Comment 5 Andreas Bierfert 2011-04-04 12:18:51 EDT
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.
Comment 6 Oliver Henshaw 2011-04-04 13:28:00 EDT
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.
Comment 7 Andreas Bierfert 2011-04-04 13:51:27 EDT
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.
Comment 8 Oliver Henshaw 2011-04-04 14:11:41 EDT
# 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]:
Comment 9 Aleksandra Fedorova 2011-04-04 14:45:38 EDT
> 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".
Comment 10 Andreas Bierfert 2011-04-04 16:21:50 EDT
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.).
Comment 11 Oliver Henshaw 2011-04-04 17:58:38 EDT
(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.
Comment 12 Peter Oliver 2011-04-04 20:21:51 EDT
(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.
Comment 13 Jaroslav Škarvada 2011-04-05 04:21:37 EDT
Created attachment 489938 [details]
Blacklist only wine-tahoma

Fontconfig to blacklist only wine-tahoma-font.
Comment 14 Fedora Update System 2011-04-06 11:14:54 EDT
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
Comment 15 Fedora Update System 2011-04-06 11:15:01 EDT
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
Comment 16 Fedora Update System 2011-04-06 11:15:09 EDT
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
Comment 17 Fedora Update System 2011-04-06 18:30:27 EDT
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).
Comment 18 Leszek Matok 2011-04-06 19:43:19 EDT
(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.
Comment 19 Adam Pribyl 2011-04-07 13:46:04 EDT
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?
Comment 20 Adam Pribyl 2011-04-07 13:53:24 EDT
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?
Comment 21 Felipe Contreras 2011-04-10 08:34:15 EDT
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?
Comment 22 Fedora Update System 2011-04-15 16:47:38 EDT
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.
Comment 23 Fedora Update System 2011-04-15 16:48:10 EDT
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.
Comment 24 Fedora Update System 2011-04-15 17:26:16 EDT
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.
Comment 25 Adam Pribyl 2011-04-16 04:34:58 EDT
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.
Comment 26 Julian Sikorski 2011-05-04 06:19:19 EDT
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.
Comment 27 Oleg Andreev 2011-11-11 01:27:42 EST
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.
Comment 28 Felipe Contreras 2012-02-02 14:18:32 EST
Doesn't look like anybody is interested in fixing this. WONTFIX?
Comment 29 Kamil Páral 2012-05-30 12:54:23 EDT
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.
Comment 30 Kamil Páral 2012-05-31 03:25:37 EDT
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.
Comment 31 Adam Pribyl 2012-05-31 07:12:58 EDT
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.
Comment 32 Kamil Páral 2012-05-31 07:21:22 EDT
I changed version to Rawhide because it's not an issue of a specific release, it's a general issue of the package.
Comment 33 Andreas Bierfert 2012-05-31 10:25:38 EDT
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.
Comment 34 Kamil Páral 2012-05-31 11:06:11 EDT
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.
Comment 35 Andreas Bierfert 2012-05-31 11:53:47 EDT
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.
Comment 36 Leszek Matok 2012-05-31 16:36:37 EDT
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.
Comment 37 Oliver Henshaw 2012-05-31 18:16:10 EDT
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.
Comment 38 Felix Miata 2012-06-01 13:58:41 EDT
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.
Comment 39 Oliver Henshaw 2012-06-04 12:38:36 EDT
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.
Comment 40 Kamil Páral 2012-06-12 04:11:14 EDT
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
Comment 41 Fedora Update System 2012-07-05 11:57:49 EDT
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
Comment 42 Fedora Update System 2012-07-05 12:00:09 EDT
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
Comment 43 Fedora Update System 2012-07-06 17:29:46 EDT
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).
Comment 44 Fedora Update System 2012-07-10 16:53:45 EDT
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.
Comment 45 Fedora Update System 2012-07-14 17:59:14 EDT
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.
Comment 46 Adam Thompson 2013-12-09 21:13:28 EST
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.)
Comment 47 Adam Thompson 2013-12-09 21:13:58 EST
(In reply to Adam Thompson from comment #46)
> (See bug# 693180.)

Sorry, I meant bug# 1039763.
Comment 48 Adam Pribyl 2013-12-10 07:13:51 EST
(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 49 Trevor Cordes 2013-12-13 18:55:15 EST
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!)

Note You need to log in before you can comment on or make changes to this bug.