My problem was that I was unable to print documents that contained Japanese fonts. The cause was that the -dPARANOIDSAFER options of ghostscript was causing it to abort when it was trying to read the Japanese .ttf files in /usr/X11R6/... Foomatic (or not sure who) provides the ppd driver file for my printer (lips4v) that says "-dPARANOIDSAFER". Ghostscript, however, has fonts where it can't see them with PARANOIDNOSAFER. Checking the meaning of PARANOIDNOSAFER in History7.htm (part of the ghostscript package) it says: Also adds a -dPARANOIDSAFER command line option that only allows reading files from %stdin, paths specified on LIBPATH, FONTPATH and /GenericResourceDir or /FontResourceDir. Improve security for device related access to the file system and to pipes by allowing the dangerous parameters to be locked (for example, OutputFile). The locking is performed after command line parameters are established. This should address SF bug #474582 and eliminate the need for the RedHat PARANOIDSAFER patch. Several solutions I can think of: 1. Extend the /FontResourceDir location 2. export a FONTPATH to CUPS 3. symlink the required .ttf files where ghostscript can see them (possibly symlink the directories inside the ResourceDir) and do not use absolute paths in ghostscript resources. Comments on each one of these: 1. No idea how to do it 2. The environment is not exported to children it seems 3. It is ugly, though it works. I just symlinked kochi-{mincho,gothic}.ttf from /usr/share/fonts/truetype in /usr/share/ghostscript/fonts (part of the original /FontResourceDir I guess) and I also changed 7.07/lib/CIDFnmap.Koc to not include the paths to these two ttf files. 3a. Another (a little nicer and easy to implement) way to fix this was to fix the lines in CIDFnmap.Koc like this: /Kochi-Mincho (truetype/kochi-mincho.ttf) ; /Kochi-Gothic (truetype/kochi-gothic.ttf) ; and to "ln -s /usr/share/fonts/truetype /usr/share/ghostscript/fonts/"
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.