From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.14) Gecko/20080416 Galeon/2.0.4 Firefox/2.0.0.14 Description of problem: Printing a landscape document from an OS X 10.4 or 10.5 client to a linux cups server results in the document being printing with shifted margins, shifting the page down and to the right, and cuts off the edges. This happens with any postscript printer set up in our cups server. I will attach a pdf document that can be used to reproduce this problem. Version-Release number of selected component (if applicable): cups-1.2.4-11.14.el5_1.6 How reproducible: Always Steps to Reproduce: 1. Use any OS X app, like MS Word and print a landscape page, or make a pdf 2. If you made a pdf, take it to the RHEL5 box and print it using: "lp -o orientation-requested=4 filename.pdf" as this simulates how Apple's Cups system sends the document Actual Results: Document prints, but margins are shifted. Expected Results: document should have printed in landscape correctly, but without shifting the margins. Additional info: Apple claims this is not their bug. They say it is a problem in the PDF filter system that RedHat EL 5 ships with cups. In debugging this problem, I compiled from source the latest version of poppler pdf library and utilities, creating a custom /usr/local/bin/pdftops converter. Then I compiled the "pdftops" cups filter from the latest svn version of cups to try. With this combination the margins are correct but the landscape pages don't get rotated, so everything is cut off the right side. So there still is a problem. Apple claims that problem is in the RedHat EL 5 cups distribution still.
Created attachment 306414 [details] PDF landscape page, printed from MS Word on OS X 10.5 To use this pdf, on a RedHat EL 5 machine with cups set up to print to a postscript printer, run: lp -o orientation-requested=4 test.pdf The page will print with the shifted margins.
Also occurs with Fedora 9 as the print server.
Just as another data point, I rigged up Adobe Reader to be a PDF filter for cups. The output for that is the same as poppler and what you describe in your cups bug report. Definitely appears to be a cups bug.
Upgrading to EL 5.2 did not change it. With stock pdftops filter I get: +------------+ | | | | | abcdefgh| +------------+ Instead of +------------+ | | | abcdefgh | | | +------------+
CUPS revision 7726 is meant to fix this.
Will wee see this fix rolled into an update rpm for RedHat EL 5? In the meantime I'll roll my own pdftops filter from the cups 1.3 branch where this is fixed.
Actually the fix in revision 7726 does *not* fix the problem. In fact, rather than getting the output I mentioned in comment #4, I now get exactly the output that you mention in your cups bug report. The output has correct margins, but is not rotated. In fact the note on the cups bug report now says that the output from cups-1.3 pdftops filter is now essentially the same as the output from the cups 1.4 pdftops filter, which still has this annoying problem. I will attempt to comment and re-open the cups bug.
A fix for this has been checked in upstream now.
I changed the mime.convs file in /etc/cups as per the patch mentioned in str 2881 and compiled pdftops from the latest cups-1.3 svn sources and now landscape printing works for all my mac users. I do have one Mac-originated PDF (a sheet with chart from MS Excel) that doesn't print correctly (nothing to do with landscape though) with the new svn pdftops filter. I can supply this pdf if needed--probably need to open a new cups bug for this. Except for this one problem that I encountered, the landscape problem appears solved. Will you be integrating this fix into the RH EL 5 stock cups package?
The patch provided upstream applies to the re-written pdftops filter introduced in 1.3.10. I'm not sure we'd want to switch to that in Red Hat Enterprise Linux 5 at this stage, so it would mean finding a way to do the same thing in the "original" (1.3.7, Xpdf-based) pdftops filter.
On the other hand, the re-written pdftops filter seems to behaving well in Fedora, and switching to it would be other advantages as well.
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~ RHEL 5.5 Beta has been released! There should be a fix present in this release that addresses your request. Please test and report back results here, by March 3rd 2010 (2010-03-03) or sooner. Upon successful verification of this request, post your results and update the Verified field in Bugzilla with the appropriate value. If you encounter any issues while testing, please describe them and set this bug into NEED_INFO. If you encounter new defects or have additional patch(es) to request for inclusion, please clone this bug per each request and escalate through your support representative.
The RHEL 5.5 beta cups rpms depend on poppler-utils, which is not in any of the beta channels. Is this an oversight? In any event, I installed the 1.3.7-16.el5 rpms from the beta channel on rhn using the poppler-utils that yum found in the normal, 5.4 channel. Is 1.3.7-16.el5 the version in 5.5 beta? There was absolutely no change. The bug is still present, at least in the configuration I just mentioned (no new poppler-util). The margins on the left and top were correct, but the result was not rotated.
Not sure at all that I got the latest beta cups packages. What version are the latest beta packages? The 1.3.7-16.el5 ones didn't work for me at all. cupsd crashed about once an hour. Rolled back to latest stable cups in the normal RHEL 5.4 channel.
Thanks for testing it out. Yes, cups-1.3.7-16.el5 is the latest version. First about cupsd crashing: I would very much appreciate it if you could try to obtain a stack trace from cupsd at the point it crashes. Here's how: 1. Install the cups-debuginfo-1.3.7-16.el5 package, as well as gdb 2. Find the process ID of cupsd using 'ps aux' 3. As root, gdb /usr/sbin/cupsd 5302 (or whatever PID it is) 4. At the '(gdb)' prompt, enter 'continue' 5. When/if cupsd crashes, enter 'bt' and copy the output here. The output of 'info locals' would also be useful. Secondly, about the original problem: I have taken another look at the patch we've used and I can see a missing part. The mime.convs file should have had this line: application/pdf application/postscript 33 pdftops change to this: application/pdf application/vnd.cups-postscript 66 pdftops because the patched pdftops filter runs pstops itself. I will re-test a package with this change added.
Thank you for your work, Tim. On my test machine I made the change to mime.convs and indeed landscape printing appears to be working! Good news indeed. As for debugging my crash, I cannot find a cups-debuginfo package in the beta channel on rhn's web page. Is there another place I need to look? I'll be happy to get you a trace as soon as I can find this.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0210.html