When trying to print (or even process in ghostscript) PDF files with japanese text ghostscript (or cups) complains about Adobe-Japan1 missing cidToUnicode. For example: Oct 13 20:27:16 hal9k cupsd[8181]: [Job 37] Couldn't find cidToUnicode file for the 'Adobe-Japan1' collection Oct 13 20:27:16 hal9k cupsd[8181]: [Job 37] Unknown character collection 'Adobe-Japan1' Doing some reasarch, I found that for some reason we do not have any files like: Adobe-Japan1.cidToUnicode but most other distributions do. Are we just missing things? Or is there a path problem of some kind? I've tried changing ghostscripts, checking all the fonts, even manually checking the CID file stuff by hand. I can't see anything wrong, beside those missing files, but are they needed? I've tried newer revisions of gnu ghostscript, i've even tried ghostscript-apfl's latest revisions, so it doesn't appear to be an upstream issue. I've even tried viewing the files on my own machine, (with X) and pretty much get the same result. I don't think the PDF is malformed or anything, since it's from an OSX box, which runs cups and uses ghostscript. GPDF seems to read the file, but does not show the japanese text. I also appologise for marking this major, but not being able to print japanese text can be a major show-stopper for some people (at least in the printing department). Reproducible: Always Steps to Reproduce: 1. Attempt to print or process with gs. 2. Wait. 3. Die. Actual Results: The file fails to print or process Expected Results: The file should print or find the font. Portage 2.0.50-r11 (default-x86-1.4, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.4.27)================================================================= System uname: 2.4.27 i686 Pentium II (Deschutes) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium2 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/init.d /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ http://mirrors.tds.net/gentoo http://open-systems.ufl.edu/mirrors/gentoo http://ftp.easynet.nl/mirror/gentoo/ http://gentoo.netnitco.net" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="apm berkdb bitmap-fonts bzlib clamav crypt cups f77 fam foomaticdb gdbm imap libg++ libwww mad maildir ncurses nls nocardbus ntlm oav oss pam perl python readline regexp samba sasl slang slp socks5 spell ssl tcpd usb virus-scan x86 xml xml2 xprint zlib"
Created attachment 41776 [details] An example problem PDF file. This paticular file came off OSX, processed most likely by some GNU related thing. (although the producer field says "Mac OS X 10.2.8 Quartz PDFContext", I don't think this is explicitly OSX related)
Okay, I'm a winner and didn't have my linguas variable set. The problem was Xpdf. It needs to be emerged with LINGUAS="ja" (and possibly zh_CN zh_TW, ko and th) in order to make it download the needed files for cups to have proper CJK support. Apparently the cjk flag isn't enough to satisfy any of this. Maybe a warning next time? Or something? Or have it assume JA/CN etc? Dunnno if anything can/should be done to fix this, myself.
Might have spoken too soon. Despite the files existing, i'm still getting: Dec 28 03:31:25 hal9k cupsd[14770]: [Job 788] 0 %%BeginResource: procset xpdf 2.02pl1 0 Dec 28 03:31:25 hal9k cupsd[14770]: [Job 788] perl: warning: Setting locale failed. Dec 28 03:31:25 hal9k cupsd[14770]: [Job 788] perl: warning: Please check that your locale settings: Dec 28 03:31:25 hal9k cupsd[14770]: [Job 788] LANGUAGE = (unset), Dec 28 03:31:25 hal9k cupsd[14770]: [Job 788] LC_ALL = (unset), Dec 28 03:31:25 hal9k cupsd[14770]: [Job 788] LANG = "en" Dec 28 03:31:25 hal9k cupsd[14770]: [Job 788] are supported and installed on your system. Dec 28 03:31:25 hal9k cupsd[14770]: [Job 788] perl: warning: Falling back to the standard locale ("C"). Dec 28 03:31:25 hal9k cupsd[14770]: [Job 788] Couldn't find cidToUnicode file for the 'Adobe-Japan1' collection Dec 28 03:31:25 hal9k cupsd[14770]: [Job 788] Unknown character collection 'Adobe-Japan1' Dec 28 03:31:26 hal9k cupsd[14770]: [Job 788] foomatic-rip version $Revision: 3.43.2.6 $ running... Maybe something is wrong with perl? Who knows. So tired...Debug 2 provides no more help either. Am I missing something?
Okay, so some more digging, and following the instructions here: http://www.cups.org/str.php?L196+P0+S0+C0+I0+E0+Qpdftops ln -s /etc/xpdfrc /etc/cups/pdftops.conf Solved the problem. Turns out it just needs a symlink and then it's okay. All that effort *whimper* Can this be plugged into the ebuild maybe as a post_inst? Maybe a warning for the Xpdf problem if CJK is enabled? Or, alternately assume the user wants CJK support just get the zn_CH, etc files?
Thanks for tracking down the problem. I think cups should create that symlink in src_install() unconditionally (I assume it doesn't harm anything). Anyhow, I don't have time to look further into the bug :( Sorry for the delay.
Created attachment 47086 [details] Ebuild correcting problem Adds the lines: # Let foreign charset PDF's print. (Bug: 67493) dosym /etc/xpdfrc /etc/cups/pdftops.conf to the end of src_install, testing on self now.
Created attachment 47178 [details] ebuild with proper dependencies Cups will now depend on xpdf if one of the language packs are available. It's possible to make pdf itself a use flag here (to prevent installation of xpdf) but doing so will break functionality of the linguas variable. Also, adds a comment if the user specified CJK support in their use flags (so they're not surprised when they lack CJK support). Tested on myself, is still stable.
please attach patches only
Created attachment 52668 [details, diff] A patch for the ebuild. One, healthy patch with three lines of context. Creates needed symlink, too (since our cups seems to relies on XPDF for the most part). Sorry about having not submit this in the first place.
The patch seems fine to me. (I cannot test it because I don't have cups ready Gentoo box atm :/)
fixed in -r3
Hm... Now I can not compile cups on my headless server w/o emerging xorg. Isn't it possible to have use flag to configure that?
set nomotif
I think cups should not depend on xpdf without cjk set
Cups needs xpdf for even crylic(sp?), greek, and hebrew support. The xpdf package is needed for giving full language support to incoming PDF files. In debian, they have the xpf font sets in seprate packages. We don't do this, we just emerge the neccessary fonts with xpdf. The odd thing is, cups still uses it's internal xpdf engine, which depends on a normal xpdf configuation and font set to work. How strange. The cjk flag just triggers the warning which tells the user they may need to set the linguas variable since it doesn't automagically give it support. I'm testing the new ebuild now, though, there's no reason for it to fail.
it needs xpdf now because i dropped the internal xpdf version so it's easier to maintain
