Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 56998 - CUPS breaks with fonts outside the standard ghostscript path
Summary: CUPS breaks with fonts outside the standard ghostscript path
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Printing Team
Depends on: 65769
  Show dependency tree
Reported: 2004-07-14 02:24 UTC by Georgi Georgiev
Modified: 2004-10-10 13:49 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

ghostscript-7.07.1-r3.patch (patch,2.86 KB, patch)
2004-07-14 02:50 UTC, Georgi Georgiev
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Georgi Georgiev 2004-07-14 02:24:23 UTC
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/"
Comment 1 Georgi Georgiev 2004-07-14 02:50:40 UTC
Created attachment 35382 [details, diff]

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.
Comment 2 Heinrich Wendel (RETIRED) gentoo-dev 2004-08-04 09:33:05 UTC
could you try if it works with -r4, it enables fontconfig support
Comment 3 Heinrich Wendel (RETIRED) gentoo-dev 2004-08-26 02:49:16 UTC
does it work with ghostscript-7.07.1-r4?
Comment 4 Georgi Georgiev 2004-08-27 09:45:29 UTC
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.
Comment 5 Georgi Georgiev 2004-10-01 02:49:12 UTC
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.
Comment 6 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-01 05:47:09 UTC
I'm asking several devs to mark kochi-substitute stable on their arches,
and ppc64 is the only one before I get ghostscript fixed.
Comment 7 Georgi Georgiev 2004-10-01 06:33:38 UTC
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"
Comment 8 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-06 03:54:06 UTC
I updated all the font locations. Does it solve your issue?
Comment 9 Heinrich Wendel (RETIRED) gentoo-dev 2004-10-07 08:09:17 UTC
usata: did you really change anything in the gs ebuilds, i couldn't find a change
Comment 10 Georgi Georgiev 2004-10-07 10:20:50 UTC
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 >

However, running this:


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 >
$ gs 

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).
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.
myconf="${myconf} `use_with truetype fontconfig`"
Comment 11 Donnie Berkholz (RETIRED) gentoo-dev 2004-10-07 10:38:21 UTC
truetype and fontconfig are not the same thing. Shouldn't pretend they are via USE flag.
Comment 12 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-07 10:40:01 UTC
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 
Comment 13 Georgi Georgiev 2004-10-07 19:06:09 UTC
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?

    truetype? ( dev-util/pkgconfig )"

Shouldn't some parameter to configure depend on this flag as well?

Re: Comment #12

Never mind. :)
Comment 14 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-10 09:33:07 UTC
I added a patch based on yours (>=-r4), Gerogi. Please test.
`gs -DPARANOIDSAFER` runs fine here.
Comment 15 Georgi Georgiev 2004-10-10 13:49:31 UTC
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.