I have a Brother QL-570 label printer, with continuous 62mm tape in it. I set the page size to 62mm x 50mm with no border in OpenOffice, created a 2-page test document, printed it. The PDF, if I print to file or turn the printer off and steal it from the CUPS spool directory, looks fine: http://david.woodhou.se/labels.pdf However, it doesn't print correctly. See the right-hand printout in http://david.woodhou.se/labels.jpeg However, if I run 'ps' and see the command lines used by CUPS to run the printer filters when OpenOffice submits the job, and run them *myself* manually, it all works fine: gs -sstdout=%stderr -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=cups -r300x300 -sOutputFile=%stdout labels.pdf | /usr/lib/cups/filter/rastertoptch dummyjob dummyuser dummytitle 1 'PixelXfer=ULP BytesPerLine=90 Align=Right SoftwareMirror LabelPreamble PrintDensity=3 ConcatPages PrintQuality=High > /dev/usb/lp0 That's the left-hand printout in the photo. Why is it different? Is CUPS preprocessing the PDF somehow before feeding it to ghostscript? How do I debug this? Preferably without actually using up all the rest of my label roll...
David, do you print directly from OpenOffice ? Is it the same when you print it directly with 'lpr [-P <printer>] labels.pdf' ? It'd be nice if you could attach an output from 'printing troubleshooter'. https://fedoraproject.org/wiki/How_to_debug_printing_problems#Printing_troubleshooter
Created attachment 882759 [details] troubleshooting information (In reply to Jiri Popelka from comment #1) > David, do you print directly from OpenOffice ? > Is it the same when you print it directly with 'lpr [-P <printer>] > labels.pdf' ? Differently broken. Far left-hand side of http://david.woodhou.se/labels2.jpeg with the previous two still there for comparison. > It'd be nice if you could attach an output from 'printing troubleshooter'. > https://fedoraproject.org/wiki/ > How_to_debug_printing_problems#Printing_troubleshooter This is from OpenOffice trying to print it (resulting in the right-hand version).
I see it running pdftops and pstops, thus: pdftops -level3 -r 300 /var/spool/cups/tmp/foomatic-JfbZ1D - pdftops 256 dwoodhou labels 1 Align=Right BytesPerLine=90 ConcatPages CutMedia=JobEnd LabelPreamble PageSize=FloppyTape PrintDensity=3Medium RollFedMedia=Roll job-uuid=urn:uuid:2b373e3c-6841-3cec-43e7-6a5131c12549 job-originating-host-name=localhost time-at-creation=1396624057 time-at-processing=1396624057 /var/spool/cups/tmp/foomatic-JfbZ1D (the latter really is pstops): [pid 19418] execve("/usr/lib/cups/filter/pstops", ["pdftops", "256", "dwoodhou", "labels", "1", " Align=Right BytesPerLine=90 Con"...], [/* 35 vars */]) = 0 But if I do the same it still works: pdftops -level3 -r 300 labels.pdf > labels.ps /usr/lib/cups/filter/pstops 256 dwoodhou labels 1 'Align=Right BytesPerLine=90 ConcatPages CutMedia=JobEnd LabelPreamble PageSize=FloppyTape PrintDensity=3Medium RollFedMedia=Roll job-uuid=urn:uuid:2b373e3c-6841-3cec-43e7-6a5131c12549 job-originating-host-name=localhost time-at-creation=1396624057 time-at-processing=1396624057' labels.ps > labels2.ps gs -sstdout=%stderr -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=cups -r300x300 -sOutputFile=%stdout labels2.ps | /usr/lib/cups/filter/rastertoptch dummyjob dummyuser dummytitle 1 'PixelXfer=ULP BytesPerLine=90 Align=Right SoftwareMirror LabelPreamble PrintDensity=3 ConcatPages PrintQuality=High' > /dev/usb/lp0 I'm confused by the page dimensions here in the log though: 'D [04/Apr/2014:15:43:25 +0100] [Job 253] Started filter pdftops (PID 32024)', 'D [04/Apr/2014:15:43:25 +0100] [Job 253] Started filter pstops (PID 32025)', 'D [04/Apr/2014:15:43:25 +0100] [Job 253] Page = 176x142; 18,36 to 158,106', ... 'D [04/Apr/2014:15:43:25 +0100] [Job 253] PageLeft = 18.0, PageRight = 158.0', 'D [04/Apr/2014:15:43:25 +0100] [Job 253] PageTop = 106.0, PageBottom = 36.0', 'D [04/Apr/2014:15:43:25 +0100] [Job 253] PageWidth = 176.0, PageLength = 142.0',
When running filters by hand, set the PPD environment variable to the path to the PPD (/etc/cups/ppd/...). I expect that is what's different.
Created attachment 882781 [details] PPD file Thanks. Setting that for the final ghostscript invocation is what breaks it. Even when I change the *HWMargins: line therein to 0 0 0 0 or 1 1 1 1 Should I refile against the ptouch-driver package?
HWMargins appears to do nothing. If I change the ImageableArea for the paper size I'm using to '0 0 172 142' though, it starts working.
Seems like that needs to be fixed in the ptouch PPD then.
The original PPD you were using was for QL-550 so that's most likely the reason for the wrong margins. ptouch-driver unfortunately uses foomatic XML files to create the final PPD file, so the change isn't that simple. Actually I've tried and had no idea what to change/add to accomplish this without having the printer at hand. Maybe I could just try to ship your working PPD file instead of fighting with the XML files. Can you attach it here once you're sure it works as expected ? Thanks.
note to myself: see also bug #560610, comment #4
I don't quite understand how these margins could be correct for the QL-550, which is just an older version of the same device. They're both continuous-feed devices, and the output from rastertoptch in both cases only seems to feed the roll on by 70px for each label in the print run, not the full 142px that is the size of the label. I find it hard to believe that the QL-550, when told that it was printing onto labels which are 50mm (142px) high, would gratuitously force you to spool over the top and bottom quarters of each label without spewing ink at them, and only let you print in the middle half. This must be some other confusion in the PPD file related to continuous vs. discrete labels or the auto-feed feature or something like that, surely? Not related to the difference between QL-550 and QL-570?
Everything's possible. I think ptouch-driver users can be count on one hand (bug #560610 is proof - Tim discovered that it was actually useless but nobody had bothered to fill a bug).
Created attachment 883572 [details] Brother PPD Here's the PPD from Brother's own printer driver, FWIW. It does actually manage to cut after each label, which the ptouch driver does not. The option handling for that seems to be different in the QL-570, and there's a 'cut after N labels' integer choice. I'll have to look how that is translated into the escape codes. With the Brother driver, the black border on at the top and left of my first page doesn't get printed — it's outside the printable area, in the 2mm or so that isn't printed. This is probably the correct behaviour — the ptouch driver ought to know about the left-hand and right-hand margins at least. The Brother driver also prints (only) the right-hand border of my first page on a second label. My paper size in OpenOffice is a little too large for the printer's paper width. Despite both being set to 62mm. So each "page" from OpenOffice comes out as two pages via the Brother driver. As opposed to being cropped, via the ptouch driver.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.