Re: strange gs problem: unicode encoding problem with pdf (?)
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
rd@blackbox:~/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
rd@blackbox:~/tmp.nobackup$ echo $?
0
rd@blackbox:~/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: 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: