Hi Florian, thanks for your reply.
Am Samstag, 5. Juli 2008 schrieb Florian Kulzer: > On Thu, Jul 03, 2008 at 22:53:02 +0200, Rainer Dorsch wrote: > > On Tue, Jun 3, 2008 at 8:44 PM, Florian Kulzer wrote: > > > On Mon, Jun 02, 2008 at 23:01:18 +0200, Rainer Dorsch wrote: > > > > > > > > > > > > > On Sat, May 17, 2008 at 23:47:06 +0200, Rainer Dorsch wrote: > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a pdf file here which > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Displays perfectly with kpdf > > > > > > > > > > > > > > - Does not print from kpdf. This is because gs > > > > > > > > > > > > > > fails > > > > > > with > > > > > > > > > > > > > > > > > this file: > > [...] > > > > > I found out that the postscript backend sends always garbage (=ps > > > > source > > > > > > code) > > > > > > > to my printer. > > > > > > Maybe the printer does not understand postscript directly, does it have > > > a built-in postscript interpreter? > > > > it is a HP LJ6. I am pretty sure that it has a built-in interpreter. > > Some LaserJet 6 models only have a built-in PCL 6 interpreter; see for > example the first 3 models on this page: > > http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=bpl0 >4055 You are right, my lj6p has no postscript interpreter. I did not know that. Thanks for pointing that out. > [...] > > > > > I verified that it still does not print...and I am curious if you can > > > > reproduce the problem (I managed it on two lenny systems now, both > > > > using > > > > > > a > > > > > > > HPLJ 6p printer). > > > > > > I cannot print this file from kpdf either, and I have similar problems > > > with foomatic-rip using Sid's "HP LaserJet 6P Foomatic/hpijs, hpijs > > > 2.8.5.23 - HPLIP 2.8.5" PPD (as well as with the PPD of my own > > > printer). On my system, a2ps is used instead of enscript, but that does > > > not seem to make any difference after all. > > > > hplip 2.8.6-1 entered lenny, but no improvement. > > > > > I can fix the file by running it though ghostscript like this: > > > > > > gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -o fixed.pdf > > > uncompressed.pdf > > > > That is an interesting observation. Apparently gs *can* read and > > interpret the file correctly. The hplip backend is unable to deal with > > the pdf file, the pdfwrite backend handles the file correctly (?). > > [...] > > > I think for now a working solution for my environment is acrobat reader > > (although it seems to be not localized). > > The acroread-l10n-de package is available from debian-multimedia.org, as > well as -en, -es, -fr, -it, -pt-br. I have never tried any of these > localization packages myself, though. Cool. I was not aware of that, thanks. > > I could try to integrate pdfwrite > > as filter into cups, but I do not know what implications this has on > > other documents.... > > You can always define an additional printer with different settings that > you use only for the problematic documents. The KDE printing framework > allows you to set up filters for print jobs (under "properties"), which > might be useful for this case. I have never had any reason to play > around with this feature, so I don't know any details. yes, I noticed that. Since I have a working solution for now (acroread), I did not invest more time into that. I rather devoted the time to generate debug data to help to find out the root cause of the problem. > > > I suspect that something is not quite kosher with the PDFs that your > > > bank generates. The fact that they work with the Adobe reader does not > > > necessarily mean that they conform 100% to the PDF specification. > > > > I understand that the Adobe reader is not the same as the standard. > > Nevertheless I am surprised that gs can handle the file as well with the > > "right" backend. So I am not sure if the problem is in the pdf file or if > > the problem is in the hplip backend. > > > > Do you agree with this conclusion? If yes, I probably would file a > > question at hplip launchpad https://launchpad.net/hplip > > I think that cannot hurt, if you can supply them with an example PDF to > demonstrate the problem. Done: https://answers.launchpad.net/hplip/+question/38386 While regenerating the logs, I found that foomatic seems to run fine on the command line [EMAIL PROTECTED]:~/tmp.nobackup$ foomatic-rip -v --ppd /etc/cups/ppd/hplj6p.ppd uncompressed.pdf > foomatic-rip.log 2> foomatic-rip.err and returns no error code [EMAIL PROTECTED]:~/tmp.nobackup$ echo $? 0 [EMAIL PROTECTED]:~/tmp.nobackup$ but the CUPS IPP report shows job-printer-state-message /usr/lib/cups/filter/foomatic-rip failed which looks odd for me. Also what surprises me further is that the foomatic-rip.log file ( http://bokomoko.de/~rd/foomatic-rip.log ) contains a valid PCL file which seems to print the pdf source code, when I send it to the printer. Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]