| Summary: | app-text/ghostscript-gpl broken with media-libs/fontconfig-infinality due to missing Fonts | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Homer <gentoo> |
| Component: | [OLD] Library | Assignee: | Printing Team <printing> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | dev-zero, fonts, i92guboj, ionic, jackdachef, jrmalaq, krinpaus, peter.gustafson, yngwin |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
I can confirm this. It truly broke my working printing system. My two brother printers were all of a sudden completely unable to print. And the worst part is that there was absolutely no feedback, the jobs were being sent to the printer, and returned success, but nothing was coming out from the printer. Finally, I found this, which put me in the right track: http://www.infinality.net/forum/viewtopic.php?f=2&t=238 You can see how my brain exploded here: https://forums.gentoo.org/viewtopic-p-7502824.html#7502824 I fixed it by using <!-- --> around that little snippet. But that will of course be reverted on the next update. Maybe we should patch this until upstream fixes it in a sane way. I don't think that ban fonts in such an obscure way is a sane behavior. If a given user install X type 1 fonts it's probably because s/he wants to use them. And in any case they don't do any harm. The easiest way to reproduce is: ~ $ gs -c "loadallfonts quit" GPL Ghostscript 9.10 (2013-08-30) Copyright (C) 2013 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Can't find (or can't open) font file hritr.pfa. Can't find (or can't open) font file /usr/share/ghostscript/9.10/Resource/Font/Hershey-Gothic-Italian. Can't find (or can't open) font file Hershey-Gothic-Italian. Querying operating system for font files... Can't find (or can't open) font file hritr.pfa. Can't find (or can't open) font file /usr/share/ghostscript/9.10/Resource/Font/Hershey-Gothic-Italian. Can't find (or can't open) font file Hershey-Gothic-Italian. Didn't find this font on the system! Substituting font Times-Italic for Hershey-Gothic-Italian. Can't find (or can't open) font file /usr/share/ghostscript/9.10/Resource/Font/NimbusRomNo9L-ReguItal. Can't find (or can't open) font file NimbusRomNo9L-ReguItal. Can't find (or can't open) font file /usr/share/ghostscript/9.10/Resource/Font/NimbusRomNo9L-ReguItal. Can't find (or can't open) font file NimbusRomNo9L-ReguItal. Didn't find this font on the system! Substituting font Helvetica-Oblique for NimbusRomNo9L-ReguItal. Can't find (or can't open) font file /usr/share/ghostscript/9.10/Resource/Font/NimbusSanL-ReguItal. Can't find (or can't open) font file NimbusSanL-ReguItal. Can't find (or can't open) font file /usr/share/ghostscript/9.10/Resource/Font/NimbusSanL-ReguItal. Can't find (or can't open) font file NimbusSanL-ReguItal. Didn't find this font on the system! Unable to substitute for font. Error: /invalidfont in /findfont Operand stack: Hershey-Gothic-Italian Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --dict:253/341(G)-- --nostringval-- 128 %dict_continue --nostringval-- 1868 1 3 %oparray_pop Dictionary stack: --dict:1173/1684(ro)(G)-- --dict:0/20(G)-- --dict:77/200(L)-- Current allocation mode is local Last OS error: No such file or directory GPL Ghostscript 9.10: Unrecoverable error, exit code 1 This is a documented feature of Infinality and mentioned in the README.gentoo file. I don't think that just adding a readme in a transversal package that's not directly related in any way is enough to consider this a non-issue. Let's look at the process by looking at my concrete case. First a printer that has always been working since I installed it stopped working. Cups gave no error whatsoever, at first I though it was something about the newer cups stuff or the brother drivers. After a lot of trial and error and after doing a lot of things out of pure instinct without having any track to follow, I ended up trying lots of things like upgrading and downgrading packages, and re-installing many versions of the drivers. After that, I found that the problem seemed to be in ghostscript, but that wasn't the end of the chain. When I got there I was able to track this down to infinality only because of a post in... guess what, the Ubuntu fora!!, shame on me! :P There's no way that any random user is going to relate a "my printer stopped working" error down to infinality, which is aimed mostly at improving how fonts show in your screen. In my opinion, whoever did that largely miscalculated the implications of it, since, installing printing drivers outside the scope of any random package manager is very far from being uncommon in linux. If you truly won't fix, then I suggest some kind ewarn at least in ghostscript AND cups, letting the user know that printing and ghostscript won't work if you use infinality, under many cases, and giving at least a link to a workaround, or this thread. I don't think that's a proper solution, but it'd be much better than the current state of things. Just my 0.2€. Just talked to some ghostscript devs: the point is that ghostscript needs "Type 1" fonts, at least for the core 35 (or so) fonts. They were surprised to hear that we don't provide /usr/share/ghostscript/9.10/Resource/Font since then disabling "Type 1" fonts really breaks ghostscript. To cite it: 17:12 < chrisl> Well, frankly, /usr/share/ghostscript/9.10/Resource/Font should be installed - those are the fonts we ship, and that we test with. What we currently do is that we don't provide the required fonts in the fontpath, so ghostscript always falls back to fontconfig to locate them (at least that's what I understood). To fix this, we can either install /usr/share/ghostscript/9.10/Resource/Font as a symlink to /usr/share/fonts/urw-fonts or export GS_FONTPATH=/usr/share/fonts/urw-fonts in an env.d file to provide ghostscript with the fontpath. This way one can substitute Helvetica et.al. with whatever they like for applications while keeping the proper/correct fonts for postscript/pdf rendering. (In reply to Tiziano Müller from comment #5) > Just talked to some ghostscript devs: the point is that ghostscript needs > "Type 1" fonts, at least for the core 35 (or so) fonts. They were surprised > to hear that we don't provide /usr/share/ghostscript/9.10/Resource/Font > since then disabling "Type 1" fonts really breaks ghostscript. > > To cite it: > > 17:12 < chrisl> Well, frankly, /usr/share/ghostscript/9.10/Resource/Font > should be installed - those are the fonts we ship, and that we test with. > > What we currently do is that we don't provide the required fonts in the > fontpath, so ghostscript always falls back to fontconfig to locate them (at > least that's what I understood). > > To fix this, we can either install /usr/share/ghostscript/9.10/Resource/Font > as a symlink to /usr/share/fonts/urw-fonts or export > GS_FONTPATH=/usr/share/fonts/urw-fonts in an env.d file to provide > ghostscript with the fontpath. > This way one can substitute Helvetica et.al. with whatever they like for > applications while keeping the proper/correct fonts for postscript/pdf > rendering. and there isn't much point in using fontconfig for locating Helvetica/Nimbus, since when trying to load Helvetica, ghostscript seems to first consult it's fontmap which dictates to use Nimbus. So I guess that when providing the fontpath for ghostscript again the only people who would suffer from it are the ones who replaced Nimbus with some other Type 1 font in their fontconfig... FWIW this appears to affect more than Infinality. I have three machines on gentoo, none use Infinality, and I still have issues with all. It took me many hours over several attempts to track it. (Actually months without a few key packages functioning on my prime machine because I initially thought it was isolated to that machine and couldn't find it.) And it causes issues with several(most?) gs related packages. I still don't know how if export GS_FONTPATH=/usr/share/fonts/urw-fonts, as suggested above, has consequences. (I'm not a font person.) I won't pretend to know what is best to do here... but I was surprised when the gs core font ebuild wasn't available (after realizing that was likely an issue.) And I've been using gentoo for about 10 years... newbie would likely have given up. Thanks all, Pete Can't find (or can't open) font file fcyr.gsf. Can't find (or can't open) font file /usr/share/ghostscript/9.10/Resource/Font/Shareware-Cyrillic-Regular. Can't find (or can't open) font file Shareware-Cyrillic-Regular. Can't find (or can't open) font file /usr/share/ghostscript/9.10/Resource/Font/Shareware-Cyrillic-Regular. Can't find (or can't open) font file Shareware-Cyrillic-Regular. Can't find (or can't open) font file /usr/share/ghostscript/9.10/Resource/Font/Shareware-Cyrillic-Regular. Can't find (or can't open) font file Shareware-Cyrillic-Regular. Scanning /usr/share/texmf-dist/tex/latex/ for fonts...Error: /typecheck in /findfont Operand stack: Cyrillic (In reply to Peter Gustafson from comment #7) > FWIW this appears to affect more than Infinality. > > I have three machines on gentoo, none use Infinality, and I still have > issues with all. It took me many hours over several attempts to track it. > (Actually months without a few key packages functioning on my prime machine > because I initially thought it was isolated to that machine and couldn't > find it.) > > And it causes issues with several(most?) gs related packages. I still don't > know how if export GS_FONTPATH=/usr/share/fonts/urw-fonts, as suggested > above, has consequences. (I'm not a font person.) Depends on whether other applications (other than gs) do interprete the GS_FONTPATH variable as well. According to the manpage, gs checks the env var before falling back to fontconfig, which is what we want. Furthermore it would make it possible to override it in an easy and persistent way should someone have to. Could you fix your problem by either creating the symlink or putting doing "export GS_FONTPATH=/usr/share/fonts/urw-fonts"? > I won't pretend to know what is best to do here... but I was surprised when > the gs core font ebuild wasn't available (after realizing that was likely an > issue.) And I've been using gentoo for about 10 years... newbie would > likely have given up. It isn't needed. What gs upstream bundles here is exactly (checked via checksums) the fonts present in the urw-fonts package (and this is also the reason why the gs ebuild depends on them afaik). OK, thanks. Yes, one solution works, that is exporting GS_FONTPATH=/usr/share/fonts/urw-fonts. The other proposed solution (the symlink) didn't work. the solution with the environment variable does not work with systemd and cups since systemd does not pass GS_FONTPATH to cups and gs which is called by the cups filters therefore fails as shown above. ... correction, adding the symlink didn't help, I still see the following errors when printing via cups:
D [07/Jun/2014:09:06:09 +0200] [Job 164] Running cat | /usr/bin/gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.3 -dAutoRotatePages=/None -dAutoFilterColorImages=false -dNOPLATFONTS -dPARANOIDSAFER -dNOINTERPOLATE -sstdout=%stderr -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/printer -dUseCIEColor -dColorConversionStrategy=/LeaveColorUnchanged -dDoNumCopies -r600 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -sOutputFile=- -c <</.HWMargins[0 0 0 0] /Margins[0 0]>>setpagedevice .setpdfwrite -f -
d [07/Jun/2014:09:06:09 +0200] select_timeout: JobHistoryUpdate=0
D [07/Jun/2014:09:06:09 +0200] [Job 164] GPL Ghostscript 9.14:
D [07/Jun/2014:09:06:09 +0200] [Job 164] Use of -dUseCIEColor detected!
D [07/Jun/2014:09:06:09 +0200] [Job 164] Since the release of version 9.11 of Ghostscript we recommend you do not set
D [07/Jun/2014:09:06:09 +0200] [Job 164] -dUseCIEColor with the pdfwrite/ps2write device family.
d [07/Jun/2014:09:06:09 +0200] select_timeout: JobHistoryUpdate=0
D [07/Jun/2014:09:06:09 +0200] [Job 164] Error: /invalidfont in /findfont
If I'd have to guess I'd say that if the symlink is present, the files inside must be named as ghostscript ships it (URWGothicL-Book, ... instead of n019043l.{afm,pfb,pfm} ....) and parsing is only done for paths in GS_FONTPATH.
So, can we please install /usr/share/ghostscript/*/Resource/Font like almost any other distro and be done with it?
*** This bug has been marked as a duplicate of bug 490248 *** |
Infinality blocks Type 1 fonts by default, i.e. in /etc/fonts/infinality/infinality.conf we have: ------ <!-- Ban Type-1 fonts because they render poorly --> <!-- Comment this out to allow all Type 1 fonts --> <selectfont> <rejectfont> <pattern> <patelt name="fontformat" > <string>Type 1</string> </patelt> </pattern> </rejectfont> </selectfont> ------ This prevents Ghostscript from finding substitute fonts using fontconfig, e.g.: ------ gs -sDEVICE=nullpage -dBATCH -c '(Helvetica) findfont' GPL Ghostscript 9.05 (2012-02-08) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Can't find (or can't open) font file /usr/share/ghostscript/9.05/Resource/Font/NimbusSanL-Regu. Can't find (or can't open) font file NimbusSanL-Regu. Can't find (or can't open) font file /usr/share/ghostscript/9.05/Resource/Font/NimbusSanL-Regu. Can't find (or can't open) font file NimbusSanL-Regu. Querying operating system for font files... Can't find (or can't open) font file /usr/share/ghostscript/9.05/Resource/Font/NimbusSanL-Regu. Can't find (or can't open) font file NimbusSanL-Regu. Didn't find this font on the system! Substituting font Courier for NimbusSanL-Regu. Can't find (or can't open) font file /usr/share/ghostscript/9.05/Resource/Font/NimbusMonL-Regu. Can't find (or can't open) font file NimbusMonL-Regu. Can't find (or can't open) font file /usr/share/ghostscript/9.05/Resource/Font/NimbusMonL-Regu. Can't find (or can't open) font file NimbusMonL-Regu. Didn't find this font on the system! Unable to substitute for font. Error: /invalidfont in /findfont Operand stack: Helvetica Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1852 1 3 %oparray_pop Dictionary stack: --dict:1161/1684(ro)(G)-- --dict:0/20(G)-- --dict:77/200(L)-- Current allocation mode is local Last OS error: 2 GPL Ghostscript 9.05: Unrecoverable error, exit code 1 ------ Commenting out the Type 1 section of infinality.conf fixes the error: ------ gs -sDEVICE=nullpage -dBATCH -c '(Helvetica) findfont' GPL Ghostscript 9.05 (2012-02-08) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Can't find (or can't open) font file /usr/share/ghostscript/9.05/Resource/Font/NimbusSanL-Regu. Can't find (or can't open) font file NimbusSanL-Regu. Can't find (or can't open) font file /usr/share/ghostscript/9.05/Resource/Font/NimbusSanL-Regu. Can't find (or can't open) font file NimbusSanL-Regu. Querying operating system for font files... Loading NimbusSanL-Regu font from /usr/share/fonts/urw-fonts/n019003l.pfb... 3562376 2202746 3652200 1792985 1 done. ------ Reproducible: Always Steps to Reproduce: 1. emerge fontconfig-infinality Actual Results: Ghostscript essentially no longer works, due to being unable to substitute fonts. Expected Results: If Type 1 fonts render poorly with Infinality, it should have some way to fall back to the standard rendering method, rather than simply blocking fonts and causing problems for other software. I discovered this bug by trying to emerge sci-visualization/gnuplot, which failed thus: epstopdf eg7.eps Error: /invalidfont in /findfont Operand stack: Symbol-Oblique Symbol Much head scratching later, I found this: http://www.infinality.net/forum/viewtopic.php?f=2&t=238