Bugzilla Bug 56998

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 an attachment (id=35382) [edit]
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.