Description of problem: "lpr -o landscape" no longer works. I get text in portrait mode. See http://www.cups.org/documentation.php/options.html dor documentation. This worked correctly int he past. Version-Release number of selected component (if applicable): $ rpm -qf `which lpr` cups-1.2.7-1.5.fc6 $ cat /proc/version Linux version 2.6.18-1.2869.fc6xen (brewbuilder.redhat.com) (gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)) #1 SMP Wed Dec 20 15:28:06 EST 2006 $ cat /etc/fedora-release Fedora Core release 6 (Zod) How reproducible: every time. Steps to Reproduce: 1. echo hello | lpr -o landscape Additional info: Printer = Samsung ML-1210 usb.
This is caused by the paps CUPS filter rotating its output when it sees the 'landscape' option. Instead it should format the output for a landscape page (with the writing the correct way up), because CUPS' own pstops filter will take care of rotations needed by landscape and orientation-requested. At the moment paps rotates it by 90°, then pstops rotates it again, resulting in a 180° transformation. The function SetCommonOptions() in cups-1.2.x/filter/common.c shows how to do this.
This is now a very old bug and it appears to also exist in FC7 and F8. Any chance of a fix soon?
I have looked into this a bit more. If I configure (with the system-config- printer tool) a portrait queue and do the following: 1 > ls -l | lp -dportrait 2 > ls -l | paps --landscape | lp -dportrait I get the expected result, i.e. (provided the ls is not too long) an ordinary portrait page (1) and a landscape page (2). The width is also correct for landscape. However if I do the same with a landscape queue, e.g. 3 > ls -l | lp -dlandscape 4 > ls -l | paps --landscape | lp -dlandscape I get for the first a portrait page (including line width as for portrait, but also the top removed) printed in landscape (3) and ordinary portrait (4).
should be fixed in 0.6.8-1.fc9. please check with it and will backport the fix to other versions then.
I assume you mean paps-0.6.8-1.fc9. However, from the test above I think shows that paps works correctly and it's pstops which behaves incorrectly?
Original status: The bug appears on FC6, F7 and F8. This fix works out of the box on F8. On F7 I need to add landscape=true as an option when configuring a landscape printer. I have not tested on FC6.
(In reply to comment #5) > I assume you mean paps-0.6.8-1.fc9. However, from the test above I think shows > that paps works correctly and it's pstops which behaves incorrectly? Well, the landscape feature that paps itself supports works fine. but it just behaved the wrong behavior as CUPS filter in the older release. as Tim already mentioned the text filter doesn't have to rotate. I suppose this is because of providing the feature for all the documentation, including printing out the PS documentation with the landscape. However, that isn't good that the text filter just doesn't do anything, because pstops just rotates the documentation but not adjust the page boundary at all. i.e. it doesn't care if the documentation is printed out of page. so paps in the CUPS filter mode does deal with the landscape but not just rotate it. FYI. (In reply to comment #6) > Original status: The bug appears on FC6, F7 and F8. > > This fix works out of the box on F8. On F7 I need to add landscape=true as an > option when configuring a landscape printer. I have not tested on FC6. > Ok, thanks. I'll backport the fix for FC6, F7 and F8 then.
Pushed the update for FC-6, F-7 and F-8.
it is working fine in rawhide (as expected), tested with following package: cups-1.3.4-5.fc9 --- Can I close bug for FC6 or someone going to test this on FC6?
sorry paps version is paps-0.6.8-1.fc9 --
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This: echo hello | lp -olandscape prints in portrait for me with Fedora 8 (paps-0.6.8-1.fc8).
Tim, are you sure your default printer is a local printer that uses paps 0.6.8-1.fc8? I have tested on F-8 again though, it works fine as expected, with: paps-0.6.8-1.fc8 cups-1.3.6-2.fc8
Yes, I'm sure. I've tried it on two separate F-8 installations, i386 and x86_64, both with paps-0.6.8-1.fc8, one with cups-1.3.6-3.fc8 and the other with cups-1.3.7-1.fc8. Both print in portrait even when -olandscape is specified. I have verified that texttopaps is really being used as the text filter by reading /var/log/cups/error_log. Trying just the texttopaps step: echo hello |\ /usr/lib/cups/filter/texttopaps 1 tim '' 1 'landscape' \ > texttopaps.ps I get output that contains "%%Orientation: Portrait", but viewing the output file in evince shows that, even though the page is in portrait orientation, the text is rotated.
Ok, I see. I thought it should be gone since the result of the real printing here is no problem. I'll have a look more.
Does 'echo hello | lp -olandscape' print in landscape for you? Because that's what I've tried, and it prints in portrait here on two different installations. I only tried running the texttopaps filter directly to try to understand why it was printing in portrait.
Yes, it does here. guess it may be the printer feature then.
Aha, trying it with a PostScript-capable printer does indeed print in landscape. I had previously tested with inkjet printers.
Tim, just realized that texttops doesn't give any %%Orientation and I can't find any code to deal with landscape option in texttops. but pstops just rotate it if -o landscape is given. apparently texttops + pstops doesn't care of if the content is exactly fit into the page. but paps is trying to do that. IMHO if %%Orientation is given right, should pstops not rotate the page anyway, shouldn't it?
Anyway, I have a workaround to get this issue fixed now. I'm pondering to add a PostScript like "90 rotate 0.0 page_width page_margin sub neg translate" to the end of %%PageSetup.
The CUPS texttops filter does in fact deal correctly with the 'landscape' option. Try this: perl -e 'print "abcd "x25' | /usr/lib/cups/filter/texttops 1 tim '' 1 'landscape' > texttops.ps The resulting texttops.ps file looks like this: +--------+ |a a a a | |a | +--------+ and has a special line near the top: %cupsRotation: 270 to tell pstops what type of rotation it should do. Perhaps texttopaps should behave in the same way?
No, that's not what I mean. texttops itself is ok. but CUPS is giving the result of texttops to pstops. and pstops is capable of making it in landscape right. see what happens on evince say after: cat texttops.ps | /usr/lib/cups/filter/pstops 1 tim '' 1 'landscape' > pstops.ps
That resulting pstops.ps file displays correctly in ghostscript. It displays with the page bounding box rotated 90° in evince -- I think that might be an evince bug.
Hmm, okay. to make sure, is the result presented by the following steps what you are expecting then? $ echo hello | paps --landscape > paps.ps (Add a line of "%cupsRotation: 0" to paps.ps) $ cat paps.ps | /usr/lib/cups/filter/pstops 1 foo '' 1 'landscape' > papstops.ps
For testing package: http://koji.fedoraproject.org/koji/taskinfo?taskID=608631 Please note that you may need to downgrade or uninstall the package after testing to apply the official updated package if you are going to test it on F-9 or older say.
Doh, wrong patch. this should be the same to what I did in comment #24. http://koji.fedoraproject.org/koji/taskinfo?taskID=608659
Those test packages both produce portrait output. Don't you have an inkjet printer available to test with yourself? Or else just compare the output to what texttops does.
No, I don't. hmm, does exchanging the width and the height in %%*BoundingBox helps? i.e. %%PageBoundingBox: 0 0 612 792 to 0 0 792 612 say.
Created attachment 305486 [details] paps-landscape.patch You can use 'gs pstops.ps' to see the output. For the texttops case it shows a portrait-orientation window with the text on the right-hand side of the page, rotated 90° clockwise from upright -- this is the output we need. Attached is a patch against current devel which fixes it for me. We now set cupsRotation to 0 to prevent pstops performing any rotation, and set /Orientation to 2 to get the correct page orientation ready for printing. What do you think?
http://koji.fedoraproject.org/koji/taskinfo?taskID=610696 Another testing package. Thanks Tim for your patch. the result looks good on ghostscript, but evince still report it's a portrait because of comment #28. I have built the testing package with it. though it doesn't still fix that issue for evince. as you said, there might be a bug in it. Anyway, please check if this testing package works for you.
Works fine for me. Evince is full of bugs that don't get fixed: I trust the ghostscript output a *lot* more.
paps-0.6.8-6.fc8 has been submitted as an update for Fedora 8
Thanks, Fixed in 0.6.8-6.fc{7,8,9,10}.
paps-0.6.8-6.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
I have changed -o landscape to -o portrait. It was worked as landscape , strange but successful :)