Florian, I appologize for the really slow response and thanks for testing the pdf file.
On Tue, Jun 3, 2008 at 8:44 PM, Florian Kulzer < [EMAIL PROTECTED] <[EMAIL PROTECTED]>> wrote: > On Mon, Jun 02, 2008 at 23:01:18 +0200, Rainer Dorsch wrote: > > Am Montag, 2. Juni 2008 schrieb Florian Kulzer: > > > On Sun, Jun 01, 2008 at 16:33:53 +0200, Rainer Dorsch wrote: > > > > Am Sonntag, 1. Juni 2008 schrieb Florian Kulzer: > > > > > On Sat, May 31, 2008 at 16:31:26 +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: > > [...] > > > > > A cupsys upgrade apparently does not replace the ppds for installed > > > > printers. > > > > > > The relevant PPD file is copied to /etc/cups/ppd (and renamed according > > > to the CUPS designation for this printer) whenever a printer is > > > installed. This copy is not changed when the original PPD file is > > > subsequently updated during a package upgrade. > > > > Surprises me that CUPS is not using symbolic links. > > I think this might be intentional. The sysadmin can customize the file > in /etc/ppd without interfering with the Debian package; likewise, > upgrades of the Debian package will not overwrite possible > modifications. > > > > > I "changed" the printer using the localhost:631 web interface and > tried > > > > two options (I also added a new test printer, but same result): > > > > > > > > *NickName: "HP LaserJet 6P Foomatic/hpijs, hpijs 2.8.4.2 - HPLIP > 2.8.4" > > > > *NickName: "HP LaserJet 6P/6MP - PostScript Postscript (recommended)" > > > > > > > > > > > > And this brought a nice improvement: > > > > > > > > foomatic-rip -v --ppd /etc/cups/ppd/hplj6p.ppd > ~/tmp.nobackup/KKA-DKB.pdf > > > > >log 2>err > > > > > > > > generates now a ps or pcl file (depending on the selected driver) in > the > > > > "log" 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. > > > The pcl backend works for other pdf files though, altough it > > contains the same enscript command > > > > file converter command: enscript -G -M A4 -b "Page $%| > > [EMAIL PROTECTED]" --margins=36:36:36:36 --mark-wrapped-lines=arrow > --word-wrap -p- > > --> This document is DSC-conforming! > > [...] > > > I uploaded the pdf with all sensitive data changed to bogus data to > > > > http://alzental-castle.de/~rd/uncompressed.pdf<http://alzental-castle.de/%7Erd/uncompressed.pdf> > > > > 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 (?). Then I can print fixed.pdf normally. This command should also work when > used directly on the original compressed file. It will produce a PDF > version 1.4; if you prefer to keep fixed.pdf at version 1.3 then you can > do so: > > gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.3 > -o fixed.pdf uncompressed.pdf > I think for now a working solution for my environment is acrobat reader (although it seems to be not localized). I could try to integrate pdfwrite as filter into cups, but I do not know what implications this has on other documents.... > > 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 Thanks, Rainer
