[Pkg-cups-devel] Bug#619461: Bug#619461: cups-pdf: PDFVer and GSCall keys not taken into account

[Jean-Philippe Thierry]

Hi,

Le 24 mars 2011 15:44, Martin-Éric Racine <martin-eric.racine at iki.fi> a
écrit :

> 2011/3/24 Volker Behr <behr at physik.uni-wuerzburg.de>:
> > The log-file you sent me contains the following line:
> >
> > Thu Mar 24 11:05:53 2011  [DEBUG] file already pdf, simply copying it
> > (cp /var/spool/cups-pdf/SPOOL/cups2pdf-12256
> /home/jpht/tmp/PDF/Bugs_in_package_cups-pdf_--_Debian_Bug_report_logs.pdf)
> >
> > This option to directly copy PDF instead of reprocessing it was
> > suggested to me some time back and I decided not to implement it since
> > it would disable all options set in cups-pdf.conf on the respective
> > files. This is exactly what happens to you here: the PDF is just passed
> > through instead of getting re-worked with all your desired options by
> > CUPS-PDF.
> >
> > So, speaking for upstream: no fix needed.
> > My advise to the distribution: remove this additional patch on CUPS-PDF
> > since it breaks basic functionality.
>
> The patch in question was removed in 2.5.1-1 as far as Debian and
> Ubuntu are concerned:
>
> * Dropped 70_cups-pdf_support-pdf-workflow.patch
>    + This patch has received more criticism than praises from the
> end-users,
>      because it essentially renders the Ghostscript options in
> cups-pdf.conf
>      useless, plus it no longer applies cleanly to the upstream code.
>
> From this perspective, I'd mark the issue as fixed since that version.
> Agreed?
>
> Martin-Éric
>

just tried installing cups-pdf from sid on my squeeze. GSCall and PDFVer are
taken into acount but... I am only getting 1 page empty documents; even
failling back to the default settings in /etc/cups/cups-pdf.conf. Could it
be due to a dependency issue even if not raised by the package?

log file attached

-- 
Jean-Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-cups-devel/attachments/20110324/c5c8b324/attachment.htm>