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 [details]
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: