Bug 1039763 - wine-courier-fonts overrides system courier font with limited .fon file
Summary: wine-courier-fonts overrides system courier font with limited .fon file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: wine
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michael Cronenworth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-09 22:51 UTC by Trevor Cordes
Modified: 2014-10-06 04:26 UTC (History)
9 users (show)

Fixed In Version: wine-1.7.24-1.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-21 09:44:23 UTC


Attachments (Terms of Use)

Description Trevor Cordes 2013-12-09 22:51:42 UTC
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

Comment 1 Adam Thompson 2013-12-09 23:59:54 UTC
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.

Comment 2 Adam Thompson 2013-12-10 00:02:04 UTC
(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.)

Comment 3 Michael Cronenworth 2013-12-10 02:06:43 UTC
(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.

Comment 4 Adam Thompson 2013-12-10 14:53:10 UTC
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.

Comment 5 Trevor Cordes 2013-12-18 10:50:36 UTC
(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?)

Comment 6 Arun Raghavan 2014-08-09 04:24:58 UTC
This also seems to apply to the arial font which makes things in Firefox look weird as well.

Comment 7 Steven Rosenberg 2014-08-13 16:59:55 UTC
(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.

Comment 8 Steven Rosenberg 2014-08-13 17:34:21 UTC
(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?

Comment 9 Peter Oliver 2014-08-13 18:37:23 UTC
(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.

Comment 10 Michael Cronenworth 2014-08-16 03:26:10 UTC
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

Comment 11 Fedora Update System 2014-08-16 19:24:47 UTC
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

Comment 12 Fedora Update System 2014-08-16 20:28:20 UTC
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

Comment 13 Fedora Update System 2014-08-19 07:04:51 UTC
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).

Comment 14 Fedora Update System 2014-08-21 09:44:23 UTC
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.

Comment 15 Steven Rosenberg 2014-08-21 17:18:27 UTC
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.

Comment 16 Fedora Update System 2014-08-27 01:38:28 UTC
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.

Comment 17 Kevin Kofler 2014-08-27 12:24:27 UTC
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.

Comment 18 Michael Cronenworth 2014-10-06 04:26:26 UTC
I'll add a system package for wingdings in 1.7.28.


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