On Wed 05 Nov 2014 at 22:27:37 +0100, Francesco Poli wrote: > I found a way to solve or work around the bug: I now use a PostScript > PPD and pdftocairo as PDF→PS renderer. > For instance: > > # lpadmin -p lj -E -v lpd://x.y.z.w/lp0 \ > -m postscript-hp:0/ppd/hplip/HP/hp-laserjet_1320-ps.ppd \ > -o pdftops-renderer-default=pdftocairo \ > -D "HP LaserJet 1320" > # lpoptions -p lj -o media=A4 -o sides=two-sided-long-edge > > After this print queue reconfiguration, lpr prints the troublesome > files correctly and it even seems to do so in shorter processing > times! :-) > I tested the same solution or workaround on other printers, with > similar results. > > I hope this strategy may work for the other users as well.
Thank you for pursuing this so assiduously and for finding a solution within the cups and cups-filters framework. I wonder whether you have a PDF which is troublesome with the HP-LaserJet_1320-pxlmono.ppd but is ok with HP/hp-laserjet_1320-ps.ppd and could send it here? I did try jaakov's Hensgen PDF with your print queues and my printer (an HP 2200DN) and had a a varied experience, which I will not bore anyone with. My tentative conclusion was that the Hensgen PDF just might not be kosher. But I know nothing about PDF structure so that is just a reaction to being knee-deep in paper. :) I do not think doing anything purposeful with the original bug report is really possible without a PPD to work with. Regards, Brian. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
