Re: strange gs problem: unicode encoding problem with pdf (?)
I have currently problems with my DNS entry, please replace
alzental-castle.de by bokonew.homelinux.org
in URLs given below.
Thanks,
Rainer
Am Montag, 2. Juni 2008 schrieb Rainer Dorsch:
> 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:
> >
> > [...]
> >
> > > > The error messages in one of your earlier mails show that you are
> > > > using the Lenny/Sid version of ghostscript (8.62), but your PPD file
> > > > seems to be outdated (it is from HPLIP 2.7.10; the current version of
> > > > hpijs-ppds is 2.8.4 in Lenny and 2.8.5 in Sid). Maybe upgrading
> > > > and/or updating to the newest PPD in the CUPS setup will fix the
> > > > problem. (Sometimes it can necessary to remove the printer and add it
> > > > again with the newest driver.)
> > >
> > > Thanks for spotting this. This improved the situation but did not fix
> > > it yet.
> > >
> > > 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 "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.
> > >
> > > But still it does not print and there are a lot of indications to these
> > > 106 pages!
> > >
> > > The pcl version goes into error the ps version prints the ps source
> > > code.
> > >
> > > Inspecting the err file, I still see the 106 pages and enscript as file
> > > converter:
> > >
> > > 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 still don't like this invocation of enscript. I now ran enscript on a
> > 1-page PDF and it tried to send 99 pages of garbage to my printer.
> > AFAIK, enscript is meant for plain text input only. So there is either a
> > problem with the filtering setup of CUPS (maybe caused by the PPD) or a
> > quirk in the PDF itself.
>
> I found out that the postscript backend sends always garbage (=ps source
> code) to my printer. 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!
>
> Full output is at
>
> http://alzental-castle.de/~rd/err.working
>
> > > And for the postscript version this is in agreement with the "log" file
> > >
> > > rd@blackbox:~$ tail log
> > > (32934) s
> > > 5 94 M
> > > (%%EOF) s
> > > _R
> > > S
> > > %%Trailer
> > > %%Pages: 106
> > > %%DocumentNeededResources: font Times-Roman Courier-Bold Courier
> > > %%+ font Times-Bold
> > > %%EOF
> > >
> > > The complete outputs (STDERR) of foomatic-rip are here
> > >
> > > http://alzental-castle.de/~rd/err.pclbackend
> > >
> > > and
> > >
> > > http://alzental-castle.de/~rd/err.psbackend
> > >
> > > > [...]
> > > >
> > > > > The file is not secret and I would be ok with sharing it to
> > > > > individual developers (without any formal agreement), but I would
> > > > > not want to post it unprotected on an web page. If you are
> > > > > interested I would send it to you in a private mail or send you an
> > > > > URL.
> > > >
> > > > I would rather not receive any sensitive information. Can you
> > > > generate a new file from the same form with bogus data filled in?
> > >
> > > My bank is generating these PDFs for me. I cannot generate them with
> > > bogus data. Not sure if there would be a save way to edit a pdf file to
> > > remove my credit card data.
> >
> > You can try to uncompress it with pdftk:
> >
> > pdftk KKA-DKB.pdf output uncompressed.pdf uncompress
>
> Thanks, that worked.
>
> > It should be possible to edit uncompressed.pdf with any text editor and
> > remove all sensitive information (unless your bank uses an unusual
> > encoding or protected the content in some other way).
>
> I uploaded the pdf with all sensitive data changed to bogus data to
>
> http://alzental-castle.de/~rd/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).
>
> Many thanks,
> Rainer
>
>
>
> --
> Rainer Dorsch
> Lärchenstr. 6
> D-72135 Dettenhausen
> 07157-734133
> email: rdorsch@web.de
> jabber: rdorsch@jabber.org
> GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
> Full GPG key: http://pgp.mit.edu/
--
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdorsch@web.de
jabber: rdorsch@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/
Reply to: