[Bug 964184] New: CUPS sends invalid orientation-requested IPP parameter value, producing scaled and shifted printouts
http://bugzilla.opensuse.org/show_bug.cgi?id=964184 Bug ID: 964184 Summary: CUPS sends invalid orientation-requested IPP parameter value, producing scaled and shifted printouts Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Printing Assignee: jsmeix@suse.com Reporter: roland_wirth@web.de QA Contact: jsmeix@suse.com Found By: --- Blocker: --- Created attachment 663795 --> http://bugzilla.opensuse.org/attachment.cgi?id=663795&action=edit original file When I try to print a non-A4 document via Okular from my workstation (openSUSE Tumbleweed 20160117 (x86_64)) on a PostScript printer (A4 paper) connected to a server running openSUSE 13.1 and CUPS 1.5.4 the document on the printout is scaled down, shifted to the right and partially cut off by the page border. It seems like the document is shifted and scaled for printout in landscape orientation, although the paper orientation is portrait. I've tracked the issue down to an invalid `orientation-requested=0` IPP parameter value (valid values are 3 to 6) that is sent in the Create-Job request from the client to the cups daemon on the server. Because okular sends a PS file and the printer is a PS printer cups processes the file through the pstops filter to prepare it for printing. The orientation-requested parameter is used by code in `filters/common.c` (line 107) to set the global variable `Orientation` to a value in the range 0-3. However, it does not validate the input value so `Orientation` ends up with a value of `-3`. Some code parts in `filters/pstops.c` check the last bit of the `Orientation` variable to determine whether the orientation is landscape while some use switch statements on the value of the variable. The value -3 seems to cause disagreement between these code parts. Replacing the orientation-requested=0 with 3 or omitting the parameter altogether fixes the problem (when executing the filter manually), as does omitting fit-to-page (which probably disables the problematic code path). The invalid value is also transmitted when printing with evince, but evince sends a pdf that is passed through a different filter chain, which behaves correctly. I have currently worked around the problem by wrapping the cups filter pstops with a script that removes the offending parameter. The arguments for the pstops filter on the server are [Job 8616] argv[0]="xerox_2ndfloor" [Job 8616] argv[1]="8616" [Job 8616] argv[2]="user" [Job 8616] argv[3]="document.pdf" [Job 8616] argv[4]="1" [Job 8616] argv[5]="Collate ColorModel=CMYK cups-browsed document-name-supplied=okularYv2259.ps Duplex=None finishings=3 fit-to-page job-uuid=urn:uuid:b0cdef39-b931-3ec0-6d84-607410d1eee6 media=A4 number-up=1 orientation-requested=0 OutputBin=Stacker outputorder=normal page-bottom=12 page-left=11 page-right=12 page-top=11 portrait print-quality=0 sides=two-sided-long-edge job-originating-host-name=xxx.xxx.xxx.75 time-at-c reation=1453983619 time-at-processing=1453983619 PageSize=A4" -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=964184
http://bugzilla.opensuse.org/show_bug.cgi?id=964184#c1
--- Comment #1 from Roland Wirth
http://bugzilla.opensuse.org/show_bug.cgi?id=964184
http://bugzilla.opensuse.org/show_bug.cgi?id=964184#c2
--- Comment #2 from Roland Wirth
http://bugzilla.opensuse.org/show_bug.cgi?id=964184
http://bugzilla.opensuse.org/show_bug.cgi?id=964184#c4
--- Comment #4 from Roland Wirth
Note that the CUPS 1.5.4 output of lp -d testq -o fit-to-page -o orientation-requested=0 original.pdf is not "wrong" and the CUPS 1.7.5 is "right" - it is just a random result when wrong options are used (i.e. it is an implementation detail what the result is). Basically, the implementation should ignore unknown option values and treat
http://bugzilla.opensuse.org/show_bug.cgi?id=964184
http://bugzilla.opensuse.org/show_bug.cgi?id=964184#c7
--- Comment #7 from Roland Wirth
By the way: I do not think that it is CUPS that sends an invalid orientation-requested value - I think that value originated from okular and CUPS only forwards the print job with its option values as it was created by okular. The option does not come directly from Okular. I tried to print the same file via evince, which works as expected although I see the `orientation-requested=0` in the filter parameters. The difference is that evince sends a PDF to the server and triggers a different filter chain.
Regarding the main issue: Okular seems to use contradicting printing options.
To find out whether or not okular actually use contradicting printing options, set up a test queue on your workstation that outputs PostScript into a file: [...] I tried printing to the test queue and for some reason I no longer see the orientation-requested option (fit-to-page is present). The printouts from ghostscript are as expected, the only difference between okular and lp being that the lp printout is in landscape orientation while okular prints portrait (the paper orientation in okular was set to landscape; strange).
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=964184
Johannes Meixner
participants (1)
-
bugzilla_noreply@novell.com