Description of Problem: pdf2ps generates clipped portrait pages for pages which are supposed to be in landscape. At last that's how a postscript file generated with pdf2ps prints. I could be wrong, the problem could be in the printing or in the source PDF document. I don't trust the gv display of the resulting postscript, as gv correctly displays the pdf, but, IIRC, the generated postscript has the problem when viewed with gv. (sorry, I'm not at the box just now and can't test.) Note, I've had this problem with other pdfs, perhaps all pdfs containing landscape pages. Version-Release number of selected component (if applicable): This behavior didn't appear, IIRC, in ghostscript 6.51 (as distributed in the Redhat 7.2 errata.) In any case, earlier versions of ghostscript did not have this problem. I first noticed it when I noticed that gv would rotate the pages depending on whether they should be landscape or portrait. I've tried ghostscript 6.52 (as distributed in the RedHat 7.3 errata), and ghostscript 7.0.5 (as distributed in RedHat 8.0, recompiled for RH 7.3.) How Reproducible: Always Steps to Reproduce: Try pdf2ps on the attached document. Pages 47 and 48 are portrait. Pages 49-51 should be landscape, but they print as portrait and are clipped. pdf2ps -dPrinted -dFirstPage=47 -dLastPage=51 \ A0.00.004.man.1.pdf test.ps Then print test.ps. I've tried -dPrinted=false and (IIRC, which I dont) -sAutoRotatePage=PageByPage and -sAutoRotatePage=None. Actual Results: Portrait pages print fine, landscape pages print portrait and are clipped on the right. Expected Results: Additional Information: FWIW, I'm using a RedHat 7.3 system, with the following RedHat 8.0 packages recompiled (rpm --rebuild) and installed: (Note: nothing was --force-d or --nodep-ed) fontconfig-2.0-3.i386.rpm freetype-2.1.2-7.i386.rpm freetype-demos-2.1.2-7.i386.rpm freetype-devel-2.1.2-7.i386.rpm freetype-utils-2.1.2-7.i386.rpm ghostscript-7.05-20.i386.rpm ghostscript-devel-7.05-20.i386.rpm ghostscript-fonts-5.50-7.noarch.rpm ghostscript-gtk-7.05-20.i386.rpm gimp-print-4.2.1-5.i386.rpm gimp-print-cups-4.2.1-5.i386.rpm gimp-print-devel-4.2.1-5.i386.rpm gimp-print-utils-4.2.1-5.i386.rpm hpijs-1.1-20.i386.rpm Omni-0.7.0-6.i386.rpm Omni-foomatic-0.7.0-6.i386.rpm patchutils-0.2.14-3.i386.rpm psutils-1.17-17.i386.rpm I'm printing on a hp4100tn laser printer using the lj5grey driver, with lpd. I also tried on a stock (errata updated) RH 7.3 system.
Created attachment 83664 [details] Test pdf, pages 49-51(+) are landscape
The ghostscript folks (https://sourceforge.net/tracker/?func=detail&atid=101897&aid=633642&group_id=1897 ) say that it works for them in APFL ghostscript 7.32. I downloaded APFL ghostscript 7.32 and did a: ./configure make root@jcp ghostscript-7.32]# (export GS_LIB=./lib ; export PATH=./bin:$PATH ; lib/pdf2ps -dPrinted -dFirstPage=47 -dLastPage=51 ~/ghostscript_upgrade/test_docs/A0.00.004.man.1.pdf /tmp/test.ps) No encode_color proc defined for device. No encode_color proc defined for device. The landscape pages still printed portrait. I'm using a hp-4100tn printer, which is a postscript printer. I assume that I'm sending postscript directly to the device; setting pre-render postscript (checkbox) in the RH printer config tool has no effect on the output. Still broken. However, I'm using the lj5grey driver for the printer. As a test I'll try the 'postscript printer' driver. Perhaps it's not the pdf conversion that's the problem but the ps printing.
Using AFPL Ghostscript 7.32 pdf2ps and printing directly to a 'postscript driver' printer works. But printing with the ghostscript 7.05 lj5grey driver fails.
Are you using CUPS? There is a known problem with landscape printing with CUPS 1.1.15.
No, I am using lpd not cups. (As cryptically noted in the original report.)
I mean, LPRng (LPRng-3.8.9-4).
Allrightie. I wacked together a AFPL Ghostscript 7.32 rpm and tried with that. It still didn't solve the problem, although, again, printing directly to a printer using the postscript driver worked fine. So, the problem's either in the lj5grey driver or somewhere else in the printing system. The problem, btw, with just using the postscript driver is that it gives no control over which paper tray the paper comes from. For me, this means that my documents all print on the wrong paper when the tray with the right paper runs out. All this wouldn't matter so much if "lpr -B" worked. (See bug #66133.) As it is, my workarounds have workarounds that don't always work.
The problem persists when I use the postscript driver instead of the lj5grey driver, at least in some cases when using ghostscript-7.05-20.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. Note that any bug still open against Red Hat Linux on will be closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Closing as CANTFIX.