Re: strange gs problem: unicode encoding problem with pdf (?)
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=bpl04055
[...]
> > > 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.
> 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.
> > 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.
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
Reply to: