Description of problem: A wine dependency is wine-courier-fonts and it puts font files in the system font area /usr/share/fonts/wine-courier-fonts/. From there it can (and does) override fonts used by other programs. For example, I have a PHP program that uses Courier and Firefox is selecting: /usr/share/fonts/wine-courier-fonts/coue1255.fon which produces inappropriate glyhps in many non-wine settings. For instance, in the PHP PDF Firefox thing I'm doing, it's showing me Euro currency symbols in place of spaces. >fc-match courier coue1255.fon: "Courier" "Regular" Version-Release number of selected component (if applicable): wine-courier-fonts-1.7.5-1.fc19.noarch How reproducible: always Steps to Reproduce: 1. Have a PHP script produce PDF output with Courier as the font 2. View that PDF in Firefox on a system with wine-courier-fonts installed 3. (I can probably whip up a public URL example if required) Actual results: Euro symbol instead of a space Expected results: Characters are rendered normally. Additional info: Seems to be the same bug as prematurely auto-closed: bug #665598
Since this bug is not observable outside Firefox's pdf.js viewer, it's likely that it's a result of codepage-mapping problems. In theory, this will affect all files system-wide because the Fedora packaging for Wine puts all the wine-specific fonts into the system-wide font path. Debian (et al.) packaging puts the Wine-specific fonts into /usr/share/wine/fonts instead of /usr/share/fonts/wine, ensuring that they don't get accidentally matched and pulled into other apps expecting Unicode-compatible font rendering. This would appear to be an oversight in the Fedora packaging of wine; you don't generally want codepage-specific .FON files overriding the system fonts, particularly since an app using the fc-match mechanism has no way to specify the DOS codepage. One could theoretically view this as a "bug" in the new[1] font management subsystem - i.e. the lack of intelligent behaviour when faced with multiple font files that all match the same base name - but I'm inclined to see it as a packaging bug, since otherwise the problem will never get fixed and it is a fairly simple fix on the Wine end of things. I also note that the Wine source distribution puts fonts in a private directory, NOT in the system font path. This would appear to be a Fedora-specific "feature" that is now 100% fully compliant with the Law of Undesirable Side-Effects.
(In reply to Adam Thompson from comment #1) > Since this bug is not observable outside Firefox's pdf.js viewer, it's > likely that it's a result of codepage-mapping problems. Correction: HAS NOT YET been observed outside Firefox's pdf.js viewer. I have no reason to believe that's the only affected application. Likely any application that blindly requests "Courier" without having a more specific name (e.g. Courier New) or fontspec hardcoded, would be affected. (Ditto for the other fonts in there... I just haven't looked up their names yet.)
(In reply to Adam Thompson from comment #1) > This would appear to be an oversight in the Fedora packaging of wine; you > don't generally want codepage-specific .FON files overriding the system > fonts, particularly since an app using the fc-match mechanism has no way to > specify the DOS codepage. > > One could theoretically view this as a "bug" in the new[1] font management > subsystem - i.e. the lack of intelligent behaviour when faced with multiple > font files that all match the same base name - but I'm inclined to see it as > a packaging bug, since otherwise the problem will never get fixed and it is > a fairly simple fix on the Wine end of things. > > I also note that the Wine source distribution puts fonts in a private > directory, NOT in the system font path. This would appear to be a > Fedora-specific "feature" that is now 100% fully compliant with the Law of > Undesirable Side-Effects. Wine is packaged this way due to the Fedora font packaging guidelines. See bug 693180 (particularly comment 35) for discussion on this issue.
After (In reply to Michael Cronenworth from comment #3) > Wine is packaged this way due to the Fedora font packaging guidelines. See > bug 693180 (particularly comment 35) for discussion on this issue. After carefully reading that entire thread, I still think this is a packaging bug because coue1255.fon does not _behave_ as other fonts do. If it were a TTF, PostScript, or OTF font, then yes, it should go into /usr/share/fonts per the Fedora packaging guidelines. However, it's a non-scalable, non-unicode, non-anitaliasable, bitmap font, which cannot be relied upon under X11. That's akin to installing TeX fonts under /usr/share/fonts and expecting magic to happen. Do the packaging guidelines really call for dumping fonts of any and all *formats* under /usr/share/fonts? Alternatively, I suppose one could consider this a bug in fontconfig (or whatever the package is called), as it should give lower precedence to .FON fonts kind of like it does with .PCF fonts where there are both bitmap and scalable versions of a traditional X11 font.
(In reply to Michael Cronenworth from comment #3) > Wine is packaged this way due to the Fedora font packaging guidelines. See > bug 693180 (particularly comment 35) for discussion on this issue. Since bug #693180 got a fix, notwithstanding comment #35 and the guidelines, does not this bug deserve a similar fix? It seems to me a separate rpm and -system.rpm for Courier, and likely all wine fonts, could not be disallowed now that the precedent has been set in #693180. Further, this bug's symptom is more egregious than #693180 because it results in incorrect glyphs displaying rather than a simple, subjective "fonts look bad". Surely the same solution could be applied here with minimal effort, if more thorough thought as to the "real" or "proper" solution is undesirable. (PS Taken to the extreme, could not incorrect glyphs showing in firefox be construed as a security hole?)
This also seems to apply to the arial font which makes things in Firefox look weird as well.
(In reply to Arun Raghavan from comment #6) > This also seems to apply to the arial font which makes things in Firefox > look weird as well. I am seeing this same issue with Arial. The fonts look terrible in both Firefox and Google Chrome. I think this happened during the last Wine update.
(In reply to Steven Rosenberg from comment #7) > (In reply to Arun Raghavan from comment #6) > > This also seems to apply to the arial font which makes things in Firefox > > look weird as well. > > I am seeing this same issue with Arial. The fonts look terrible in both > Firefox and Google Chrome. I think this happened during the last Wine update. I would like to add that this is in Fedora 20. Should this be opened as its own bug, or can it be incorporated into this report?
(In reply to Steven Rosenberg from comment #7) > I am seeing this same issue with Arial. The fonts look terrible in both > Firefox and Google Chrome. I think this happened during the last Wine update. Indeed, wine-fonts-arial was first included in 1.7.22-2, pulled in automatically by wine-fonts. http://pkgs.fedoraproject.org/cgit/wine.git/commit/?h=f20&id=a401ea3e98ebe63b2654e2680e2a166b80aefc9a. I know there's disagreement about whether Wine fonts should be made available as system fonts, but, irrespective of that, this affects the existing user experience, so ideally shouldn't have been included in a stable update.
The Font SIG has allowed us to remove Wine fonts from the system path. I'll be pushing a 1.7.24 update shortly to address this. https://lists.fedoraproject.org/pipermail/fonts/2014-August/001736.html
wine-1.7.24-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/wine-1.7.24-1.fc20
wine-1.7.24-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/wine-1.7.24-1.fc19
Package wine-1.7.24-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing wine-1.7.24-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-9533/wine-1.7.24-1.fc20 then log in and leave karma (feedback).
wine-1.7.24-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This update solved my problem with Wine fonts looking bad in Web browsers. Thanks for the update and another great experience with bug-reporting in Fedora.
wine-1.7.24-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Hmmm, I think this needs to be made dependent on the font, or -system subpackages provided (as was done for Tahoma): * for Arial and Courier, installing them only for WINE is definitely the right thing to do! We have font substitutions providing better fonts. (For Arial, we have the original Liberation Fonts ("Liberation 1") with manually tuned hinting information, WINE forked "Liberation 2", which is a fork of Google's CrosCore fonts, which are the same vector fonts, but without tuned hinting information. For Courier, this bug points out that WINE's Courier is not even a vector font, we have a vector Courier from the URW fonts.) * for other fonts like Wingdings, the WINE fonts are very useful! They are TTF fonts, and I don't think we have another implementation of Wingdings anywhere in Fedora. So those are important to be able to read documents and websites from users of that inferior OS.
I'll add a system package for wingdings in 1.7.28.