On Tue, Jun 3, 2008 at 8:44 PM, Florian Kulzer <firstname.lastname@example.org
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 installedI think this might be intentional. The sysadmin can customize the file
> > > 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.
in /etc/ppd without interfering with the Debian package; likewise,
upgrades of the Debian package will not overwrite possible
> > > 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 188.8.131.52
- 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.
Maybe the printer does not understand postscript directly, does it have
> I found out that the postscript backend sends always garbage (=ps source code)
> to my printer.
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 $%|
> rd@blackbox" --margins=36:36:36:36 --mark-wrapped-lines=arrow --word-wrap -p-
> --> This document is DSC-conforming!
I cannot print this file from kpdf either, and I have similar problems
> I uploaded the pdf with all sensitive data changed to bogus data to
> 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).
with foomatic-rip using Sid's "HP LaserJet 6P Foomatic/hpijs, hpijs
184.108.40.206 - 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
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