+++ This bug was initially created as a clone of Bug #132745 +++ Description of problem: Using a RHEL 5.5 system as a central CUPS print server. When a user printing from a Mac OS X client sets a document to landscape and prints it, the output is incorrectly rotated on the output page. The Mac OS X printing system sends PDF to the print server, then cups uses the pdftops print filter to process, then pstops print filter is used. Both of which are putting rotate directives in the postscript that is sent to the printer. This bug has been identified by the cups development team as STR #207 and fixed in CUPS v1.1.20rc1. http://www.cups.org/str.php?L207 http://www.cups.org/relnotes.php Version-Release number of selected component (if applicable): cups-1.3.7-18.el5_5.8 How reproducible: Always Steps to Reproduce: 1. on a Mac OS X client in TextEdit create a document 2. set page orientation to landscape 3. print Actual Results: the printed text is in landscape orientation but the paper is in portrait orientation. The printed text is at 90 degrees to the page orientation: ________ |text is here | | | | | | |_______| Expected Results: the printed text should be properly aligned with the page orientation in landscape mode. ______________ |text is here | | | | | |_____________| Additional info: You can also duplicate this following the instructions and sample pdf from Bug 447987, which seems to indicate that this used to work on EL5 but broke recently. Another interesting aspect is that we are sharing two different printers, an HP LaserJet 5m and a Dell 5130cdn. When a OS X client prints to the HP, it sends postscript output and we don't see this problem. When it prints to the Dell, it sends PDF ouput and we see the problem. I have no idea and would like to know why it decides to send different format output to the two printers. lpoptions HP: auth-info-required=none copies=1 device-uri=ipp://earth.cora.nwra.com:631/printers/poe job-hold-until=no-hold job-priority=50 marker-change-time=0 number-up=1 printer-info='Double sided LaserJet 5m by fax machine' printer-is-accepting-jobs=true printer-is-shared=false printer-location='Fax Machine' printer-make-and-model='HP LaserJet 5M Postscript (recommended) on earth.cora.nwra.com' printer-state=3 printer-state-change-time=1291138347 printer-state-reasons=none printer-type=18878550 printer-uri-supported=ipp://earth.cora.nwra.com:631/printers/poe lpoptions Dell: auth-info-required=none copies=1 device-uri=ipp://earth.cora.nwra.com:631/printers/miro job-hold-until=no-hold job-priority=50 marker-change-time=0 number-up=1 printer-info='Dell 5130cdn Color Laser' printer-is-accepting-jobs=true printer-is-shared=false printer-location='Computer Lab' printer-make-and-model='Dell 5130cdn Color Laser v3018.102 PS on earth.cora.nwra.com' printer-state=3 printer-state-change-time=1291138347 printer-state-reasons=none printer-type=19042526 printer-uri-supported=ipp://earth.cora.nwra.com:631/printers/miro
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg514571.html may have some relevant discussion.
CUPS bug, which you filed Tim :). Appears fixed in cups subversion, has this not made it to EL5 yet?
The fix for bug #447987 only went in as part of RHEL-5.5, i.e. cups-1.3.7-18.el5. What you are describing sounds like the same problem. It was fixed in CUPS by having the pdftops filter call pstops *itself*, without any rotation options. Part of the fix involved a change to mime.convs, and I wonder if that didn't take due to local modifications. What does 'grep pdftops /etc/cups/mime.convs' say?
Ah, sorry: # diff mime.convs mime.convs.rpmnew 41c41 < application/pdf application/postscript 33 pdftops --- > application/pdf application/vnd.cups-postscript 66 pdftops 109c109 < application/octet-stream application/vnd.cups-raw 0 - --- > #application/octet-stream application/vnd.cups-raw 0 - Moving mime.convs.rpmnew into place and restarting cups fixed it. Thanks! Now to figure out why I had uncommented application/octet-stream....
RHEL-5.10 (the next RHEL-5 minor release) is going to be the first production phase 2 [1] release of RHEL-5. Since phase 2 we'll be addressing only security and critical issues. I'm closing this ticket as WONTFIX because this problem is neither security nor critical. [1] https://access.redhat.com/support/policy/updates/errata/