I originally reported that bug at cups.org (#1850). As it turned out, there seems to be a problem with the way ghostscript-esp-8.15.2_p20060520 handles the search path. I do not know whether this is a problem specific to my system or a general one. Since I had to edit the ebuild to fix it I wanted to report it here as well. In short (full report at cups.org): my system got _very_ slow when using eps2eps or ps2pdf14 on LaTex generated PostScript. When I ran strace on the process I discovered that gs hang at reading font definitions. I could reproduce that bug with certain eps/ps files but not all of them. I fixed the problem by 1) editing the ebuild (I removed nearly all font paths) and 2) running "unset GS_LIB" as a normal user (GS_LIB was set to "~./fonts/" where fonts resided that crashed the system). My ebuild diff: 101c101 < myconf="${myconf} --with-fontconfig --with-fontpath=/usr/share/fonts:/usr/share/fonts/ttf/zh_TW:/usr/share/fonts/ttf/zh_CN:/usr/share/fonts/arphicfonts:/usr/share/fonts/ttf/korean/baekmuk:/usr/share/fonts/baekmuk-fonts:/usr/X11R6/lib/X11/fonts/truetype:/usr/share/fonts/kochi-substitute" --- > myconf="${myconf} --with-fontconfig --with-fontpath=/usr/share/fonts/default/ghostscript:/usr/share/fonts/default/Type1" At cups.org it was suggested that a fontconfig aware gs should be able to find all fonts anyway without having to have such a long font path. Further reading: http://www.cups.org/str.php?L1850 Any ideas where the source of the problem lies? Cheers, Thomas
The real problem here is the broken font files causing problems for GS. As per your link, CUPS.org suggested removing the broken fonts. That is the preferred solution rather then removing search paths.
