Bug#847462: the problem is with CUPS
On Fri 03 Mar 2017 at 18:42:15 +0100, Francesco Potortì wrote:
> >> I have the same problem. This happens with any application. For
> >> example, if I just try to print from Firefox an HTML page with just a
> >> line of text on it.
> >>
> >> To demonstrate the problem:
> >>
> >> # cupsdisable pdf
> >>
> >> - print a simple html text-only page on the pdf printer from Firefox
> >> - get the spool file from the /var/spool/cups: it's a PDF file which
> >> looks perfect (first attachment)
> >
> >So what's the problem? You wanted to produce a PDF from an html page.
> >That has taken place. You could have achieved the same by printing to
> >file from Firefox.
>
> If you want to tell me that che cups-pdf driver is useless because it's
> possible to print to file from the print interface, okay, I'll buy it.
I never said cups-pdf was useless. I would say its use is inappropriate
in some situations. Converting an existing PDF to a PDF is one of them.
As for buying it, you and the upstrem author agree:
> I remain with my view that if your application already
> supports PDF output - why not simply print to a file.
That's from #658004.
> If this is the case, the Debian description of the package should
> clearly mention it. Or maybe note that it makes sense to install it
> only when not using a graphical interface. If you think that this is
> the case, maybe it will be enough to update the Debian description of
> this package, or at least meantion this fact in README.Debian.
Package descriptions have been mentioned in this bug report. A wishlist
bug against cups-pdf would be the way to go.
> >> # cupsenable pdf
> >>
> >> - get the file from the ~/PDF directory: it's a bigger PDF file with no
> >> text information and jagged font appearance (second attachment)
> >
> >Now you want to convert the PDF file you wanted in the first place into
> >another PDF file. Why?
>
> No, I do just want to have a PDF file produced in my ~/PDF directory.
> The above steps are meant to help debugging the problem.
No? But that is what you are doing. A Firefox produced PDF can go in
~/PDF.
> >> This apparently has to do with the old problem of cups-pdf converting
> >> PDF to PS and back to PDF.
> >
> >CUPS is not the problem. The problem is users not realising CUPS+the
> >cups-pdf backend is intended for converting PostScript to a PDF file.
>
> From what you say I get that the problem is me, not CUPS, and cups-pdf
> is only a convoluted mean to avoid using ps2pdf.
I'll admit to the first. I did not say or imply the second.
> In contrast, as far as I can see, cups-pdf is intended to be generic,
> rather than specific for PS files. This is what I read on the Debian
> package description as well as on <http://www.cups-pdf.de/>.
The package description doesn't mention "generic". Neither can I see the
word at upstream's home page,
> >Firefox does not (as you have seen) send PostScript to CUPS.
>
> I see. But as a cups-pdf user, I should not be supposed to know what
> Firefox (or any other program) in fact does when it produces data for
> printing, I'd just like to find a hopefully good-quality pdf file in my
> ~/PDF.
If an action does not produce an expected outcome you are into some
level of investigation, whether it be computing or cooking.
> >> I have an old Ubuntu Lucid installation where the problem does not
> >> exist.
> >
> >Likely it has a different filter path through the printing system,
>
> I guess so. Which means that the problem should be solvable, and it
> would be nice if it were solved in Debian.
It depends on what the usecase is.
> Thanks for your work in maintaining this package
Martin-Éric Racine is the maintainer.
Regards,
--
Brian.
Reply to: