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.
