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.