| Summary: | CUPS breaks with fonts outside the standard ghostscript path | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Georgi Georgiev <chutz+bugs.gentoo.org> |
| Component: | Current packages | Assignee: | Printing Team <printing> |
| Status: | VERIFIED TEST-REQUEST | ||
| Severity: | normal | CC: | fonts, ppc64 |
| Priority: | High | ||
| Version: | 2004.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 65769 | ||
| Bug Blocks: | |||
| Attachments: | ghostscript-7.07.1-r3.patch | ||
|
Description
Georgi Georgiev
2004-07-14 02:24:23 UTC
Created attachment 35382 [details, diff]
ghostscript-7.07.1-r3.patch
Here is the proper solution:
1. Modify the fontpath to search, and get rid of the weird default path that
includes locations like /usr/openwin, etc.
2. Modify the resources (patch the patch) to not include absolute paths.
Tested and working.
could you try if it works with -r4, it enables fontconfig support does it work with ghostscript-7.07.1-r4? I don't have the oportunity to make complete tests right now, but it seemed that it doesn't work. I'll try to confirm for sure, but at least the output of "gs -help" still shows unreasonable search paths for fonts and other resources. Did the test. Tried to use the 7.07.1-r6 ebuild. It doesn't work. A few notes: /usr/share/ghostscript/7.07/lib/CIDFnmap.Koc contains a line "/Kochi-Mincho (/usr/X11R6/lib/X11/fonts/truetype/kochi-mincho.ttf) ;". However: 1. kochi-mincho.ttf is not installed with the latest kochi-substitute package. 2. A kochi-mincho-subst.ttf is installed in a completely different location as per the latest font.eclass. 3. The "/usr/X11R6/lib/X11/fonts" path is deprecated (somebody fix ghostscript, a simple sed would do: find -name CIDFnma* | xargs sed -e 's!/usr/X11R6/lib/X11/fonts/!/usr/share/fonts/!g'). That's just for starters. 4. Even if the file is moved to an appropriate location, ghostscript is still no allowed to access it because: $ gs -help | tail -n 8 Search path: . : /usr/share/ghostscript/7.07/lib : /usr/share/fonts/default/ghostscript/ : /usr/share/fonts/default/ghostscript : /usr/share/fonts/default/Type1 : /usr/share/fonts/default/TrueType : /usr/lib/DPS/outline/base : /usr/openwin/lib/X11/fonts/Type1 : /usr/openwin/lib/X11/fonts/TrueType .... and it is not allowed to read files outside these paths (see the original report why). By using the attached patch it works like a charm. I'm asking several devs to mark kochi-substitute stable on their arches, and ppc64 is the only one before I get ghostscript fixed. I couldn't find the proper bug related to the fontconfig patch, so I am posting here:
configure needs "--with-fontconfig" in order to compile ghostscript with freetype support.
Try it yourselves: ldd /usr/bin/gs | grep free
Still, I am not sure that having a freetype2-enabled ghostscript really helped me.
--- /usr/portage/app-text/ghostscript/ghostscript-7.07.1-r6.ebuild 2004-09-29 19:15:49.000000000 +0900
+++ /usr/portage-chutz/app-text/ghostscript/ghostscript-7.07.1-r6.ebuild 2004-10-01 22:26:15.798523871 +0900
@@ -78,6 +78,8 @@
src_compile() {
local myconf
myconf="--with-ijs --with-omni --without-gimp-print"
+ myconf="${myconf} --with-fontpath=/usr/share/fonts/truetype:/usr/share/fonts/ttf"
+ myconf="${myconf} `use_with truetype fontconfig`"
use X && myconf="${myconf} --with-x" \
|| myconf="${myconf} --without-x"
I updated all the font locations. Does it solve your issue? usata: did you really change anything in the gs ebuilds, i couldn't find a change He did change -- the "cjk" patch is updated. The font paths are now explicit. I don't understand why do it this way, instead of setting the font paths on the configure line. After all, the problem when printing is that ghostscript cannot access files that are outside the path which is set at compilation time.
For the sake of argument I recompiled ghostscript again. Currently I have my kochi- files in /usr/share/fonts/kochi-... and they are found by ghostscript when running it as:
LC_ALL=ja_JP ls -l | a2ps -X euc-jp > out.ps
gs out.ps
However, running this:
gs -DPARANOIDSAFER out.ps
produces an error. The reason, as I stated it earlier is that -DPARANOIDSAFER makes ghostscript only access files in its search path. "gs -help" shows that path at the very bottom.
I tried adding
myconf="${myconf} `use_with truetype fontconfig`"
to the ebuild, and it didn't matter what paths were specified in the "CIDFnmap*" files, because the freetype library was finding the files for ghostscript. I confirmed this by specifying an invalid path in CIDFnmap.Koc, but the program still worked.
However, "gs -DPARANOIDSAFER" still didn't work!
The ebuild needs something like
myconf="${myconf} --with-fontpath=/usr/share/fonts"
if it is to work at all!
Please, please. Before committing a fix, try if it works for yourself. The procedure is here:
$ LC_ALL=ja_JP ls -l | a2ps -X euc-jp > out.ps
$ gs out.ps
$ gs -DPARANOIDSAFER out.ps
To summarize: there are two problems with the ebuild as it is:
1. ghostscript cannot access files outside its search path when run with -DPARANOIDSAFER (which is the situation when printing), and fonts like kochi-subst happen to be outside this path (because nobody cared to specify the search path at compile time).
Solution:
myconf="${myconf} --with-fontpath=/usr/share/fonts"
2. The fontconfig patch is effectively disabled, because it needs the undocumented "--with-fontconfig" parameter to kick in. Currently "configure" disables the fontconfig features.
Solution:
myconf="${myconf} `use_with truetype fontconfig`"
truetype and fontconfig are not the same thing. Shouldn't pretend they are via USE flag. Sorry, I didn't test -DPARANOIDSAFER. I did change the font location I wanted to change when we added font.eclass - I didn't commit the patch to fix your bug - so I asked you to test it. But, well, I should have tested it regarding to your bug by myself. Please forgive my lazyness. Re: Comment #11 Sorry. I thought the conditional dependency on pkgconfig is related to the fontconfig patch. I see it isn't. Well, you guys add "--with-fontconfig" without the condition then. Why is there only one place where the truetype flag is mentioned in the ebuild anyway? DEPEND="${RDEPEND} truetype? ( dev-util/pkgconfig )" Shouldn't some parameter to configure depend on this flag as well? Re: Comment #12 Never mind. :) I added a patch based on yours (>=-r4), Gerogi. Please test. `gs -DPARANOIDSAFER out.ps` runs fine here. You're the man, Komachi. This has been bugging me for a while. Finally it is gone (a page got out of the printer successfully). Regarding all the fontpaths you specified on the command line there: Isn't this one good reason why fonts should not be installed in separate directories in bug #13808. Actually, if I have some good argument besides common sense, I'll just bring it up at the other bug. |
