Closed michaelrsweet closed 15 years ago
CUPS.org User: h.blischke
May it be that both the pdftops and the pstops filter deal with that attribute and thus fight ageinst one another????
CUPS.org User: mike
No, the change specifically forces pdftops to think the page size is rotated so that it won't apply its own rotation.
More than likely the setpagedevice call is causing the problem. Unfortunately, there is no easy way to disable it aside from modifying the PSOutputDevice class, which I'd like to avoid since we'll need the same fix for CUPS 1.4's pdftops...
CUPS.org User: jgc
The fix put in for STR #2850 got us up and running again as soon as we updated from v1.3.7 to 1.3.8 - broke again with the 1.3.9 update, so we've had to revert. We have Mac OS X client machines printing to Kyocera FS-1030D printers, and to use twaugh's PDF representation:
+------+ |ABCDEF| |ABCDEF| +------+
Gives us this output:
+----+ | | |CDEF| |CDEF| +----+
CUPS.org User: jschwender
Is this the same thing? https://bugs.launchpad.net/ubuntu/+source/cups/+bug/300312
CUPS.org User: allianne
In a mixed environment, I have similar problems.
With cups 1.3.8, Windows users printing with cups+samba cannot print in duplex or use staple and punch features. However, Mac users can print landscape documents with 1.3.8.
With 1.3.9, cups+samba works properly, but OS X users cannot print landscape properly.
Additionally, with 1.3.9, it is the first page ONLY that prints rotated and cropped with OS 10.5 clients. Subsequent pages print properly landscaped.
CUPS.org User: torriem
Is there likely to be any movement on this bug? I get the impression the changes require a bit of reengineering which developers want to wait for 1.4 to do. Is this likely to be soon? We have a RHEL5 server with cups and none of our linux clients are affected by this, but all of our Mac users are affected when they print.
CUPS.org User: allianne
I can understand having other priorities, but this bug is a show-stopper for us. Can someone point me in the direction of a solution, or give an update on the status of this bug? Thanks in advance.
CUPS.org User: mike
All: at this point I am not sure what we'll be able to do with this; the PDF filter has always been largely third-party code, and the landscape handling (and specifically the auto-rotation code that is in Xpdf) has caused us grief for a while.
While we will continue looking for a solution, ultimately this will have to get fixed upstream in Xpdf and poppler.
CUPS.org User: mike
I'm currently looking at wrapping the local pdf-to-postscript filter and pstops so that we allow that filter to handle the auto-rotation of output and not pass landscape or orientation-requested to the pstops filter. That may fix things, but like all workarounds I don't know yet whether it will fix all things.
CUPS.org User: mike
Also, pushing this to CUPS 1.4, as the changes to run pstops will not be compatible with the CUPS 1.3 code.
CUPS.org User: mike
Back to CUPS 1.3, since we now have put the new pdftops in CUPS 1.3 as well (STR #3129)...
CUPS.org User: torriem
No go. I just tried the new pdftops filter from the svn 1.3.x head. My system is RHEL 5.3 stock, and I assume the underlying transform filter is poppler. The new pdftops code from 1.3.x now does this for all my Macs and from any Linux machine where -o orientation-requested=4 is used:
+----+ | | |CDEF| |CDEF| +----+
In other words the printout is not rotated and all I see is the lower right-hand part of the page.
Maybe this is progress. I dunno. Every fix I've tried over the last year and a half (various subversion versions of pdftops) has resulted in slightly different incorrect printouts.
Is this a poppler bug now? Is poppler guessing at the page orientation only to be (again) second-guessed by the pdftops filter in cups?
CUPS.org User: twaugh.redhat
I'm not even sure if submitting a landscape orientation PDF and giving the orientation-requested=4 option is really supposed to work. It seems like asking the print server to rotate the document again, when that is not required.
Is this really a Mac OS X bug?
CUPS.org User: torriem
Even more fun. I verified that I am indeed using poppler (I don't think RHEL 5.x by default uses poppler, but rather the older xpdf... I compiled it myself), and even tried the latest version 0.10. Still get the printout I described above.
I rebuild pdftops in cups-1.3.x without pdftops support, forcing it to use gs. This doesn't work either. With gs I get:
+----+ | | |ABCD| |ABCE| +----+
This is very interesting indeed. I'm going to try to hack on the pdftops filter some more.
CUPS.org User: torriem
You could be right about this, Rick. I originally did open this bug with Apple and they of course said it was RH's fault.
Yes it does seem daft to have a rotated page already and then request landscape. That's definitely what OS X requests though. Very odd indeed. Sadly it's easier to get an open source project to change to accommodate bad behavior that it is to get Apple to fix this on their end. I wonder if OS X printing to another OS X-hosts queue has this problem.
CUPS.org User: mike
Current 1.3.x does not have the change in place yet, it just has the backported wrapper from trunk without the changes. The changes are coming...
CUPS.org User: mike
Michael: This problem does not happen on Mac OS X since the cgpdftops filter does not rotate its output.
The problem is that Xpdf (and poppler) both rotate PDF's to portrait orientation, and then pstops also rotates the output to portrait orientation, resulting in double rotation.
The fix (that I'm still working on) is to run pstops from the wrapper program so that pdftops actually produces application/vnd.cups-postscript instead of application/postscript.
CUPS.org User: torriem
Okay. Thanks for the clarification. I did hack on pdftops and found that the code that checks the "orientation-requested" thing isn't even executing. Basically the if(size && fit) check is never true. Not sure if this is part that is yet to come or what.
Thanks for your work in this. Appreciate it very much.
CUPS.org User: mike
Tim: No, it isn't a Mac OS X bug, but just a side-effect of how the various pdftops filters work - namely, they try to set the page size and do things that the pstops filter normally does.
Since we're trying to get away from hacking the Xpdf pdftops in the CUPS sources, I'm focusing on removing the orientation-requested and landscape options from the arguments passed to pstops.
CUPS.org User: mike
Fixed in Subversion repository.
"str2881.patch":
--- conf/mime.convs.in (revision 8671) +++ conf/mime.convs.in (working copy) @@ -7,7 +7,7 @@ #
# -# Copyright 2007-2008 by Apple Inc. +# Copyright 2007-2009 by Apple Inc.
#
@@ -38,7 +38,7 @@
#
-application/pdf application/postscript 33 pdftops +application/pdf application/vnd.cups-postscript 66 pdftops application/postscript application/vnd.cups-postscript 66 pstops application/vnd.hp-HPGL application/postscript 66 hpgltops application/x-cshell application/postscript 33 texttops
--- filter/pdftops.c (revision 8671) +++ filter/pdftops.c (working copy) @@ -65,13 +65,23 @@ fit; /* Fit output to default page size? _/ ppd_filet *ppd; / PPD file _/ ppd_sizet *size; / Current page size */
const char _cupsserverbin; / CUPSSERVERBIN environment variable /
struct sigaction action; / Actions for POSIX signals /
@@ -158,21 +168,111 @@ cupsMarkOptions(ppd, num_options, options);
/*
/*
pdf_argc = 7;
if (ppd) @@ -184,27 +284,27 @@ if (ppd->language_level == 1) {
} else if (ppd->language_level == 2) {
} else
pdf_argv[pdf_argc++] = (char *)"-dLanguageLevel=3";
if ((val = cupsGetOption("fitplot", num_options, options)) == NULL) @@ -254,72 +354,88 @@
if (orientation & 1) {
pdfargv[pdfargc++] = (char *)"-paperw";
pdf_argv[pdf_argc++] = (char *)"-expand";
if (orientation & 1) {
pdfargv[pdfargc++] = pdfwidth;
pdf_argv[pdf_argc++] = pdf_height;
} }
execv(CUPS_GHOSTSCRIPT, pdf_argv); cupsLangPrintError(("ERROR: Unable to execute gs program"));
exit(1); }
if (job_canceled)
{
} }
/*
"str2881-1.3.patch":
--- conf/mime.convs.in (revision 8674) +++ conf/mime.convs.in (working copy) @@ -7,7 +7,7 @@ #
# -# Copyright 2007 by Apple Inc. +# Copyright 2007-2009 by Apple Inc.
#
@@ -38,7 +38,7 @@
#
-application/pdf application/postscript 33 pdftops +application/pdf application/vnd.cups-postscript 66 pdftops application/postscript application/vnd.cups-postscript 66 pstops application/vnd.hp-HPGL application/postscript 66 hpgltops application/x-cshell application/postscript 33 texttops
--- filter/pdftops.c (revision 8674) +++ filter/pdftops.c (working copy) @@ -65,13 +65,23 @@ fit; /* Fit output to default page size? _/ ppd_filet *ppd; / PPD file _/ ppd_sizet *size; / Current page size */
const char _cupsserverbin; / CUPSSERVERBIN environment variable /
struct sigaction action; / Actions for POSIX signals /
@@ -159,21 +169,111 @@ cupsMarkOptions(ppd, num_options, options);
/*
/*
pdf_argc = 7;
if (ppd) @@ -185,27 +285,27 @@ if (ppd->language_level == 1) {
} else if (ppd->language_level == 2) {
} else
pdf_argv[pdf_argc++] = (char *)"-dLanguageLevel=3";
if ((val = cupsGetOption("fitplot", num_options, options)) == NULL) @@ -255,74 +355,91 @@
if (orientation & 1) {
pdfargv[pdfargc++] = (char *)"-paperw";
pdf_argv[pdf_argc++] = (char *)"-expand";
if (orientation & 1) {
pdfargv[pdfargc++] = pdfwidth;
pdf_argv[pdf_argc++] = pdf_height;
} }
execv(CUPS_GHOSTSCRIPT, pdf_argv); cupsLangPrintf(stderr, ("ERROR: Unable to execute gs program: %s\n"), strerror(errno));
exit(1); }
if (job_canceled)
{
} }
/*
Version: 1.3-current CUPS.org User: twaugh.redhat
The fix for STR #2850 is incorrect. The PDF file: http://cups.org/strfiles/2850/landscape.pdf still prints incorrectly when the option 'orientation-requested=4' is given, even when the patch http://cups.org/strfiles/2850/str2850.patch is applied.
Representation of original PDF: +------+ |ABCDEF| |ABCDEF| +------+
I have scanned in the printed output resulting from this command: lp -oorientation-requested=4 landscape.pdf
on two different printers:
+----+
Printing the file using 'lp landscape.pdf' works correctly -- the problem only occurs when the orientation-requested=4 option is given.