Bug 776080

NOTE:

   This is the first time I have ran into this problem.
   I did not have not had problem using the printer with previous releases.

I do not have your particular printer model
so that I cannot reproduce it on my own.
Have a look at
http://en.opensuse.org/SDB:How_to_Report_a_Printing_Issue
how you could provide more information that could help me
to find out the root cause of your issue.


In comment#0 you wrote "YAST ... The test pages printed correctly".

Does this mean that in YaST you selected "Print Test Page" and
then "Two test pages" and you got the two test pages printed
in duplex mode (i.e. on both sides of a single paper)?

If yes, it means that basically duplex printing works
(i.e. the printing system can do it) but probably
something in your applications dos no longer let
you do duplex printing.

Does duplex printing also work when you print with

echo -e 'One\fTwo' | lp -d <queue_name>

and depending on your paper format with either of the commands

echo -e 'A4-1\fA4-2' | a2ps -1 -M A4 -o- | lp -d <queue_name>
echo -e 'Letter-1\fLetter-2' | a2ps -1 -M Letter -o- | lp -d <queue_name>

Yes, as I said, the test from YAST works.  And, Yes the command lines work (I didn't expect them not to.)  What I did mean to say was:

  When I try to print from ANY GUI program, I get a pop-up that does not let me select single or double sided printing.  Went I use the default (Flip on the long the long side), printing is still single page.

O.k. this means the printing system can do duplex printing
but the GUI printing dialogs won't let you choose it.

Please attach your PPD file /etc/cups/ppd/<queue_name>.ppd
as MIME type "text/plain" to this bug
and
attach a screenshot of such a GUI program pop-up that does not
let you select single or double sided printing.

Created attachment 504946 [details]
The requested PPD file

Created attachment 504947 [details]
The requested SnapShot

I have downloaded the public release of 12.2.  The problem still exist.

I have attached the requested files.

Note that though the GUI pop-up appears to say duplex printing should occur, in reality the printer only does single side printing.

An observation: The printing is slower than normal and printer appears to be running a duplex page.  But only a single page is printed.

Created attachment 508445 [details]
Dell 5110cn PPD

This is the PPD I have previously used.

Duplex printing broke for me when I upgraded from 12.1 to 12.2.  I did an "on-line" upgraded (added repos and did a zypper dup).

This also occurs on another 12.2 machine where I did a fresh install.

My printer is a Dell 5110cn.

I used the same PPD as with 12.1 (it was all in /etc/cups/ppd.

I tried the two page Yast test print.  The two pages were printed on separate sheets.  

Duplex printing from application programs fail as well.

I have IPV6 disabled and /var/log/cups/error_log has "Unable to bind socket for address [v1.::1]:631 - Cannot assign requested address."

I have been doing additional test.  I am able to print duplex successfully from the command line with both 'lp -d printer -o sides=two-sided-long-edge' and with separate printer established with lpoptions print/duplex-log -o sides=two-sided-long-edge.

However, the GUI program I have tested (libreoffice, calligrawords, and gedit always print simplex.  No matter how I select duplex, it never prints duplex.

After reading RedHat Bugzilla, I change my libreoffice from using a PDF driver to a PS driver (my printer is a Dell5110cn: industrial network printer) and found the Duplex setting now works.  Still no duplex in other programs (Chrome, Okular, etc).

I am wondering if this could be a CUPS or Ghostscript issue.

Eric Schott,
many thanks for your testing and your valuable comments!

It seems the switch from PostScript to PDF as the standard
print job format has become the topmost reason for various
new printing issues.

This switch is advocated by the
OpenPrinting workgroup of the Linux Foundation
and the CUPS author, see "PDF as standard print job format"
http://www.linuxfoundation.org/collaborate/workgroups/openprinting

See also
"PDF: The future common printing format" at
http://en.opensuse.org/Concepts_printing

For my personal opinion see
https://bugzilla.novell.com/show_bug.cgi?id=732442#c5

I think the real problem with the switch from PostScript to PDF
as standard print job format is when applications cannot be easily
switched back from PDF to PostScript as standard print job format
both by a normal user who runs a particular application and
by an admin to specify a system default print job format.

I don't know if one can cofigure Qt or Gtk or applications
using Qt or Gtk or KDE or Gnome so that they produce again
PostScript by default.

See in particular those bug reports:

bnc#732442
Applications using Qt produce PDF for printing which can fail
on PostScript printers

bnc#781193
LibreOffice: Cannot print landscape if it generates PDF
(works for PostScript)

Even bnc#774627 and its duplicates (i.e. Printing on PostScript
printers no longer works) is a side-effect of this switch, see
https://bugzilla.novell.com/show_bug.cgi?id=774627#c3

Thanks for that message.  Here is a more complete test.  First, I defined two functions:

ps-test () { echo -e "PS Print: Page 1:\"${@}\"\fPS Print: Page 2: \"${@}\"" | a2ps -1 -M Letter -o- | lp ${@}; }
pdf-test () { echo -e "PDF Print: Page 1:\"${@}\"\fPDF Print: Page 2: \"${@}\"" | a2ps -1 -M Letter -o- | ps2pdf - | lp ${@}; }

My printer default as shown by 'lpoptions -l -p dell5110cn | grep Duplex' is 'Duplex/2 Sided Print: *None DuplexNoTumble DuplexTumble'

Now, the tests:
'ps-test -d dell5110cn -o sides=two-sided-short-edge' RESULT: Duplex as expected
'ps-test -d dell5110cn -o Duplex=DuplexNoTumble' RESULT: Duplex as expected
'pdf-test -d dell5110cn -o Duplex=DuplexNoTumble' RESULT: NO Duplex *FAIL*
'pdf-test -d dell5110cn -o sides=two-sided-short-edge' RESULT: NO Duplex *FAIL*

Could it be the options are lost somewhere in the interaction between CUPS and GhostScript.

I am using the printing repository: 
cups-1.5.4-96.1.x86_64
ghostscript-9.06-27.1.x86_64

I now realize my problem is different from the original poster.  Should I open a new bug request?

Let's simply continue here:

To find out what actually is sent to the printer device,
set up a test queue that uses the exact same PPD file
but sends the final data into a file.

As root do:

1.)
Add in /etc/cups/cupsd.conf the line
FileDevice yes
and restart the cupsd, see "FileDevice" at
http://www.cups.org/documentation.php/doc-1.5/ref-cupsd-conf.html

2.)
# lpadmin -p testq -v file:///tmp/testq.out \
  -P /etc/cups/ppd/dell5110cn.ppd -E

3.)
Run your tests:

# ps-test -d testq -o sides=two-sided-short-edge
# mv /tmp/testq.out /tmp/testq.out.ps-test.two-sided-short-edge

# ps-test -d testq -o Duplex=DuplexNoTumble
# mv /tmp/testq.out /tmp/testq.out.ps-test.DuplexNoTumble

# pdf-test -d testq -o Duplex=DuplexNoTumble
# mv /tmp/testq.out /tmp/testq.out.pdf-test.DuplexNoTumble

# pdf-test -d testq -o sides=two-sided-short-edge
# mv /tmp/testq.out /tmp/testq.out.pdf-test.two-sided-short-edge


Now you have what would be actually sent to your printer
for each test in the files
/tmp/testq.out.ps-test.two-sided-short-edge
/tmp/testq.out.ps-test.DuplexNoTumble
/tmp/testq.out.pdf-test.DuplexNoTumble
/tmp/testq.out.pdf-test.two-sided-short-edge

In your PPD file in your attachment #508445 [details]
there is
-----------------------------------------------------------------------
*Duplex DuplexNoTumble/Flip on Long Edge: "
    2 dict dup /Duplex true put
    dup /Tumble false put setpagedevice
"
*End
-----------------------------------------------------------------------
which means that for "lp ... -o Duplex=DuplexNoTumble"
you should find those PostScript snippet in the
data that would be actually sent to your printer
(line breaks do not not matter for PostScript):
-----------------------------------------------------------------------
    2 dict dup /Duplex true put
    dup /Tumble false put setpagedevice
-----------------------------------------------------------------------

I guess only in the "...ps-test..." files you find those
PostScript snippet and that would explain why your printer
is not switched into duplex mode in caes of "...pdf-test..."
but that does not yet show the root cause why it fails.

See "What is a PPD file and how does it work?"
and "What does the filter system do and how does it work?" at
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell
for background information how PostScript snippets
from the PPD file are usually inserted into the PostScript
thst is sent to a PostScript printer.


We do not have a printer like yours to reproduce it on actual hardware
but I will try to reproduce it with file:///tmp/testq.out
and with your PPD - nevertheless please do it also on your system
at least to make sure your results and mine are the same.


The importance was set by the initial reporter to "critical" but
this is no "Crash, loss of data, corruption of data, severe memory leak"
see https://bugzilla.novell.com/page.cgi?id=fields.html#importance
and I was set as "needinfo" without a question.

I change the importance to something that matches
https://bugzilla.novell.com/page.cgi?id=fields.html#importance

Only FYI:

On my SLED11-SP1 workstation (I run on my workstation
what most of our business customers run) with CUPS 1.5.4
and Ghostscript 9.06 from the "Printing" project
I cannot reproduce it
(your PPD file in your attachment #508445 [details]
 is /tmp/bug776080/bug-776080_delllocal.ppd
 on my workstation):
----------------------------------------------------------------------------
# lpadmin -p testq -v file:///tmp/testq.out \
 -P /tmp/bug776080/bug-776080_delllocal.ppd -E

# echo -e "page1\fpage2" | a2ps -1 -M a4 -o- \
 | lp -d testq -o Duplex=DuplexNoTumble
[stdin (plain): 2 pages on 2 sheets]
[Total: 2 pages on 2 sheets] sent to the standard output
request id is testq-76 (0 file(s))
# mv /tmp/testq.out /tmp/testq.out.ps-test.DuplexNoTumble

# echo -e "page1\fpage2" | a2ps -1 -M a4 -o- | ps2pdf - \
| lp -d testq -o Duplex=DuplexNoTumble
[stdin (plain): 2 pages on 2 sheets]
[Total: 2 pages on 2 sheets] sent to the standard output
request id is testq-77 (0 file(s))
# mv /tmp/testq.out /tmp/testq.out.pdf-test.DuplexNoTumble

# for f in /tmp/testq.out* ; do echo $f: ; \
 grep -A4 DuplexNoTumble $f ; echo == ; done
/tmp/testq.out.pdf-test.DuplexNoTumble:
%%BeginFeature: *Duplex DuplexNoTumble

    2 dict dup /Duplex true put
    dup /Tumble false put setpagedevice
%%EndFeature
==
/tmp/testq.out.ps-test.DuplexNoTumble:
%%BeginFeature: *Duplex DuplexNoTumble

    2 dict dup /Duplex true put
    dup /Tumble false put setpagedevice
%%EndFeature
==
----------------------------------------------------------------------------

This shows that neither CUPS nor Ghostscript seem to be
the root cause but more likely something in openSUSE 12.2

I will re-do the test on an openSUSE 12.2 system...

Created attachment 509394 [details]
Snippet if PS files with Duplex

This shows the section of each PS file where the duplex is inserted into the code.

Created attachment 509395 [details]
All four PS files

This tar has all four PS files in their entirety. Curious how mangled the PostScript is by the PS -> PDF -> PS translation.  Maybe GhostScript is the culprit.

Eric Schott,

only as a shot in the dark, try out if this works for you:

# echo -e "page1\fpage2" | a2ps -1 -M a4 -o- \
   | ps2pdf - - | pdf2ps - - \
   | lp -d dell5110cn -o Duplex=DuplexNoTumble

i.e. additional conversion back to PostScript via "pdf2ps - -"

Reason,
see "Why it works with the 'Postscript Level 1/2' drivers" at
https://bugzilla.novell.com/show_bug.cgi?id=770880#c9
Basically the 'Postscript Level 1/2' drivers and "pdf2ps - -"
run Ghostscript to make PostScript and in bnc#770880
Ghostscript's PostScript has made the printer happy.

Regarding "Curious how mangled the PostScript is by the PS -> PDF -> PS
translation.  Maybe GhostScript is the culprit."

In your files testq.out.pdf-test.DuplexNoTumble
and testq.out.pdf-test.two-sided-short-edge there is
-----------------------------------------------------------------------------
%Produced by poppler pdftops version: 0.20.0 (http://poppler.freedesktop.org)
-----------------------------------------------------------------------------

poppler's /usr/bin/pdftops and
Ghostscript's /usr/bin/pdf2ps and /usr/bin/ps2pdf
are totally different programs.

If the additional conversion back to PostScript
via Ghostscript's "pdf2ps - -" in comment #18
works for you, it indicates that the root cause
of this issue is again poippler's PostScript.

(In reply to comment #18)
> Eric Schott,
> 
> only as a shot in the dark, try out if this works for you:

Was the pun about "shot" intended? :)

> # echo -e "page1\fpage2" | a2ps -1 -M a4 -o- \
>    | ps2pdf - - | pdf2ps - - \
>    | lp -d dell5110cn -o Duplex=DuplexNoTumble

This produced a duplex output as intended.  Very good detective work.

No, I did not intend to shoot something,
I only used http://dict.leo.org/
to get a translation for the German "ins blaue"
and I got "a shot in the dark".

The German "ein Schuss ins Blaue" means to do something
without good knowledge about it, something like
"on the off chance" or "hit-or-miss"...


Since comment #20 it looks like one more duplicate
of bnc#774627 (and its duplicates).

Eric Schott,

please try out if a poppler version upgrade as described
in some comments in bnc#774627 also helps in your case.

If yes, this one is actually a duplicate of bnc#774627

In your case the Dell Color Laser 5110cn PS is a bit
smarter than the other PostScript printers in bnc#774627
(and its duplicates) because the Dell Color Laser 5110cn
does not completely fail - only duplex (and perhaps
some other options) do not work with poppler's PostScript.

Your translation to "a shot in the dark" was appropriate.

Where I live, my surname is pronounced the same as "shot."  I enjoy playing with that.  No bruised feeling here.

In any event, the 0.20.3 Poppler did NOT work.  Still no duplexing.

I see Poppler 0.20.05 was released.  My limited understand of the commit logs didn't seem to relate to my issue.

By the way, I noticed a few days ago there is a firmware upgrade to my printer. I decided to hold off on that since duplex worked correctly before my upgrade to 12.2.

I can see where your area of support is difficult.  So many changes.

Now hopefully a shot in the dawn:

-----------------------------------------------------------------
# /usr/bin/pdftops -h
...
  -duplex                : enable duplex printing
-----------------------------------------------------------------

It seems pdftops has its own built-in duplex handling
and perhaps one needs to call pdftops with -duplex
so that pdftops's built-in duplex handling also
enables duplex printing regardless that afterwards
CUPS will add the PostScript snippet
-----------------------------------------------------------------
2 dict dup /Duplex true put dup /Tumble false put setpagedevice
-----------------------------------------------------------------
to enable duplex as usual for a PostScript printer
via the matching PostScript snippet from the PPD file.

When CUPS gets PDF it runs /usr/bin/pdftops to convert it
into PostScript because CUPS needs PostScript so that
it can add the PostScript snippets from the PPD file
to enable this or that option in a PostScript printer.

I assumed that CUPS runs /usr/bin/pdftops in a generic way
because it needs generic PostScript (without any options
set as "/usr/bin/pdftops -duplex" might do) because the
options are set by CUPS via the PostScript snippets.

To verify how CUPS calls /usr/bin/pdftops, I did
# mv /usr/bin/pdftops /usr/bin/pdftops.away
and installed this as -rwxr-xr-x /usr/bin/pdftops
-------------------------------------------------------------
#! /bin/bash
echo $@ >/tmp/pdftops.args
set >/tmp/pdftops.env
sleep 60
exit 0
-------------------------------------------------------------

Then I sent a print job:
-----------------------------------------------------------------
# echo -e "page1\fpage2" | a2ps -1 -M a4 -o- | ps2pdf - - \
  | lp -d testq -o Duplex=DuplexNoTumble
[stdin (plain): 2 pages on 2 sheets]
[Total: 2 pages on 2 sheets] sent to the standard output
request id is testq-93 (0 file(s))
-----------------------------------------------------------------

This is what ps shows while /usr/bin/pdftops runs:
-------------------------------------------------------------------------
lp ... /bin/bash /usr/bin/pdftops -level3 /var/spool/cups/d00093-001 -
-------------------------------------------------------------------------
and accordingly /tmp/pdftops.args contains
-------------------------------------------------------------
-level3 /var/spool/cups/d00093-001 -
-------------------------------------------------------------

As expected CUPS calls /usr/bin/pdftops in a generic way
in particular without -duplex.


Eric Schott,

now you need to verify if calling pdftops with -duplex
is required to make duplex printing work regardless that
afterwards CUPS will add the PostScript snippet to also
enable duplex printing.

pdftops needs its input in a regular file (usual requirement
when processing PDF files which have a reference "xref" table
at the end) therefore the test has now two steps:

# echo -e "page1\fpage2" | a2ps -1 -M Letter -o- \
  | ps2pdf - /tmp/test.pdf

# pdftops -level3 -duplex /tmp/test.pdf - \
  | lp -d dell5110cn -o Duplex=DuplexNoTumble


One more shot in the dark:

If the Dell Color Laser 5110cn PS is only a PostScript Level 2 printer
try out if

# pdftops -level2 -duplex /tmp/test.pdf - \
  | lp -d dell5110cn -o Duplex=DuplexNoTumble

or even

# pdftops -level2 /tmp/test.pdf - \
  | lp -d dell5110cn -o Duplex=DuplexNoTumble

print duplex (see the "pdftops -h" output).

(In reply to comment #23)

> now you need to verify if calling pdftops with -duplex
> is required to make duplex printing work regardless that
> afterwards CUPS will add the PostScript snippet to also
> enable duplex printing.
> 
> pdftops needs its input in a regular file (usual requirement
> when processing PDF files which have a reference "xref" table
> at the end) therefore the test has now two steps:
> 
> # echo -e "page1\fpage2" | a2ps -1 -M Letter -o- \
>   | ps2pdf - /tmp/test.pdf
> 
> # pdftops -level3 -duplex /tmp/test.pdf - \
>   | lp -d dell5110cn -o Duplex=DuplexNoTumble
> 
> 
> One more shot in the dark:
> 
> If the Dell Color Laser 5110cn PS is only a PostScript Level 2 printer
> try out if
> 
> # pdftops -level2 -duplex /tmp/test.pdf - \
>   | lp -d dell5110cn -o Duplex=DuplexNoTumble
> 
> or even
> 
> # pdftops -level2 /tmp/test.pdf - \
>   | lp -d dell5110cn -o Duplex=DuplexNoTumble

Sorry for the delay .. other fires to fight here. But I am sure you have been occupied.  I tried several tests:

1)  I did your requested items and all failed to duplex.

2)  I created an openSUSE 12.1 virtual machine with the bare packages need to run a print server.  This did duplex correctly.  I used the same PPD and test.pdf from my 12.2 machine.

3)  On my 12.2 machine, I downgrade poppler-tools to 0.18.0-2.6.1 from 12.1 Updates repo and installed libpoppler18-0.18.0-2.6.1.  Duplex works correctly.

From this, I am comfortable making the claim this is either a Poppler problem or a Dell printer problem.  I would day most likely Poppler.

See the above comment #24:

It seems there is a regeression in the poppler version in openSUSE 12.2
which affects at least a Dell Color Laser 5110cn PostScript printer.

With the poppler version in openSUSE 12.2 duplex printing
does no longer work on a Dell Color Laser 5110cn PS.

With poppler 0.18.0 duplex printing works on that printer.

Coming from report #774627.

Duplex printing to Postscript printer Kyocera cs-3050 is broken, i.e., it does not print both sides of a sheet of paper despite having the settings enabled to do so, and has printed duplex in the past.

I encountered the same problem with a Ricoh Aficio MP 3351.  I suspect the bug is not printer-specific.  The work-around, as suggested by earlier comments, was to install these three packages from openSUSE 12.1:

    libpoppler18-0.18.0-2.1.3.i586.rpm
    libtiff3-3.9.5-8.1.2.i586.rpm
    poppler-tools-0.18.0-2.1.3.i586.rpm

However, these files are the only ones that really matter:

    /usr/bin/pdftops
    /usr/lib/libpoppler.so.18

I encountered the same problem with a HP LaserJet P2015 on OpenSuse 12.2.

But, if I choose in LibreOffice's print dialogue "Printer Properties" and then "Device" and then switch "Printer language" from Pdf to Postscript,  and then Duplex work fine.

How to change the Printer Language for the entire system (OpenSuse 12.2) from PDF to Postscript?

As far as I know there is no general switch to change the print job
language for the entire system from PDF to Postscript, compare
https://bugzilla.novell.com/show_bug.cgi?id=732442#c9

Stefan,
only FYI, see starting at
https://bugzilla.novell.com/show_bug.cgi?id=776080#c24

Created attachment 514920 [details]
Simple postscript file

The output generated by poppler can be simplified to the following:
---
%!PS-Adobe-3.0 EPSF-3.0
/Helvetica-Bold findfont 12 scalefont setfont
<< /Duplex true >> setpagedevice
<< /PageSize [595 842] >> setpagedevice

16 720 moveto % XXX: margin
(Printing Page 1, Doc 1 ...) show
showpage

% This one breaks duplex
<< /PageSize [595 842] >> setpagedevice

16 720 moveto % XXX: margin
(Printing Page 2, Doc 1 ...) show
showpage
----

Duplex printing fails due to the second setpagedevice call.

Function can be test with:

$> netcat -w5 -q2 kyocera 9100 <  simpletext_duplex.ps

If the second setpagedevice is removed, duplex works.

Stefan Brüns,
it seems you have fixed it in the package cups
in the openSUSE build service project
openSUSE:12.2 cups home:StefanBruens:branches:openSUSE:12.2:Update
by adding to cups.spec only "BuildRequires:  poppler-tools"
and with this cups.changes comment:
-------------------------------------------------------------------------
Wed Nov 28 21:54:57 UTC 2012 - stefan.bruens@rwth-aachen.de

- newer poppler pdftops supports and needs '-origpagesizes' when called
  from cups filter. The configure check requires poppler-tools
  Fixes bnc#776080 (nonworking duplex printing)
-------------------------------------------------------------------------

From Benjamin Brunner I got the openSUSE build service request 143497
to review this change.

I do not have the time to reverse-engineer in detail how exactly
this fix works so that I ask here for some explanation how
"BuildRequires: poppler-tools" in the package cups actually
makes it work.

On a first glance it seems it is as follows:

It seems the issue is related to
https://www.cups.org/str.php?L3689

From what I read there there is a check during "configure"
that disables using '-origpagesizes' if poppler-tools
are not installed in the build system.

Therefore - as far as I currently understand it - adding
"BuildRequires: poppler-tools" makes the build-time check
succeed when the installed Poppler is really new enough
to contain the "-origpagesizes" option in /usr/bin/pdftops
which causes that the CUPS filter /usr/lib/cups/filter/pdftops
uses "-origpagesizes" when calling /usr/bin/pdftops.

Stefan Brüns,
is my understanding correct?


Regarding adding "BuildRequires: poppler-tools":

At some time in the past we had a build dependency cycle
between cups and poppler (see cups.changes) so that
adding "BuildRequires: poppler-tools" may re-introduce
such a build dependency cycle again.

Furthermore:
Adding "BuildRequires: poppler-tools only to let
a configure check succeed looks like overkill,
compare what I wrote in cups.changes some time ago:
-------------------------------------------------------------------
- full_path_to_configure_with-pdftops.patch
  adds support to specify a full path in
  'configure --with-pdftops=/usr/bin/pdftops'
  to avoid 'BuildRequires: xpdf-tools' which would
  bloat the build system but would be only needed to
  satisfy 'AC_PATH_PROG(CUPS_PDFTOPS, pdftops)'
  in cups-pdf.m4 if only 'configure --with-pdftops=pdftops'
  was possible (Novell/Suse Bugzilla bnc#526847).
-------------------------------------------------------------------

I think the whole idea of such a check in the build system
is broken because such a check would actually have to be done
during runtime because what really matters is whether or not
/usr/bin/pdftops on the end-user system supports '-origpagesizes'
which means the check would actually have to happen in
/usr/lib/cups/filter/pdftops.

But I do not have the time to fix this mess properly so that
for me adding "BuildRequires: poppler-tools" is o.k.
if it does not cause issues in our whole build system.


Benjamin Brunner,
please check if adding "BuildRequires: poppler-tools"
causes a build dependency cycle.
If adding "BuildRequires: poppler-tools" does not cause
a severe issues in our build system, I accept it.

The build itself succeeds and I didn't find a BuildRequire from poppler to cups. It should be ok, from our side. (I added Marcus Meissner to the cc-list if he wants to double-check)

I accepted the review request 143497 with this comment:
------------------------------------------------------------------
For me (jsmeix) adding "BuildRequires: poppler-tools"
is o.k. regarding the package cups but it might cause issues
(e.g. build dependency cycle) in our build system, see
https://bugzilla.novell.com/show_bug.cgi?id=776080#c32
------------------------------------------------------------------

+BuildRequires:  poppler-tools


is this a runtime or a build requirement?

I suspect more this is a runtime requirement, if yses, it should be
Requires: poppler-tools

See https://bugzilla.novell.com/show_bug.cgi?id=776080#c32 from Johannes, which is correct.

Short version: configure checks if poppler pdftops supports the "-origpagesizes" option. If it is not there during build, but during runtime, the wrong options are used.

Yes, this is broken - if you e.g. install poppler from KDE/Release/49 on oS12.1, this breaks duplex printing.

It really should be a runtime check, on the other hand this is not necessary if we know it is there.

Maybe something like (warning, pseudo code only) should be done in the specfile:

--
%if{SUSE_VERSION} > 1210
Requires: poppler-tools >= 0.21    <- version guessed
Patch99:  disable_origpagesizes_configure_check.diff
%else
Patch99:  do_runtime_origpagesize_check.diff
%endif
--

i think people installing mismatching poppler-tools between build and runtime are on their own.

however ... should we not then have both requires and buildrequires poppler-tools, or does something else pull in poppler-tools in the system?

The cups specfile has:
Recommends: /usr/bin/pdftops

I think a requires would be fitting better, as the pdftops filter is used/required for all PDF producing applications, which is anything Qt4 or recent Cairo based.

Please read my comments in cups.spec:
-------------------------------------------------------------------------
# The CUPS filter /usr/lib/cups/filter/pdftops is a wrapper
# which calls /usr/bin/pdftops
# (see the configure setting '--with-pdftops=/usr/bin/pdftops')
# so that this might justify a RPM Requires but this CUPS filter
# is not used on all systems (e.g. on a print server with
# only "raw" queues) so that a weak Recommends is sufficient:
Recommends:     /usr/bin/pdftops
-------------------------------------------------------------------------

RPM Requires are hard dependencies that cannot be skipped by
end-users (without having unresolved dependencies in their systems)
and cups is installed on almost any system (except minimal systems)
so that all RPM Requires in cups result that all those hard
dependencies must be installed on practically any system.

If I remember correctly the openSUSE build service installs
all RPM Requires to set up the build system of a package
so that all RPM Requires in cups result that all those hard
dependencies must be installed in our build systems for
any package that directly or indirectly BuildRequires cups.

In short:
Keep RPM Requires as small as possible - i.e. only what is really
mandatory to let the software run - and specify all what is optional
(i.e. what is not really mandatory) as RPM Recommends.

Regarding comment #38 "pdftops filter is used/required for all PDF
producing applications, which is anything Qt4 or recent Cairo based":

No.

PDF printing works on a client system even without pdftops on the
client system when the client system uses only CUPS servers in
the network for printing so that the pdftops filter is not run
on the client but on a CUPS server.

Please do not make our printing packages only for home-user systems
with a local printer but keep network environments in mind.
Not only SLES but also openSUSE is used in network environments
(sometimes even in business network environments).

Only for the log:
Request 143497 was accepted by msmeissn
so that currently there is the fixed cups
as package cups.openSUSE_12.2_Update
in project openSUSE:Maintenance:1147

Created attachment 517058 [details]
Packages used for tests

List of cups and poppler packages.

(In reply to comment #41)
> Only for the log:
> Request 143497 was accepted by msmeissn
> so that currently there is the fixed cups
> as package cups.openSUSE_12.2_Update
> in project openSUSE:Maintenance:1147

Results of tests with packages in Maint-1147
  - Tests per comment 13:
    - ps-test & pdf-test with Duplex=DuplexNoTumble: Correctly duplexes long edge
    - ps-test & pdf-test with Duplex=DuplexTumble: Correctly duplexes short edge
    - ps-test & pdf-test with Duplex=None: Correctly printes on two sheets
    - ps-test & pdf-test with sides=two-sided-long-edge: Correctly duplexes long edge
    - ps-test & pdf-test with sides=two-sided-short-edge: Incorrect: duplexes on long edge
    - ps-test & pdf-test with sides=one-sided: Incorrect: duplexes on long edge
    - For the above, /etc/cups/lpoptions had Default dell5110cn Duplex=DuplexNoTumble sides=two-sided-long-edge.  I may test with more lpoptions defaults later.
  - Tests per comment 10:
    - Libreoffice with PDF output filter correctly duplexes long and short edges
    - Gedit correctly duplexes long and short edges (CUPs from remote client)
  - Okular: Duplexes, but always on long edge. Possibly related to above.

I appreciate the work and headway.

(In reply to comment #43)

> Results of tests with packages in Maint-1147
>   - Tests per comment 13:
>     - ps-test & pdf-test with Duplex=DuplexNoTumble: Correctly duplexes long
> edge
>     - ps-test & pdf-test with Duplex=DuplexTumble: Correctly duplexes short
> edge
>     - ps-test & pdf-test with Duplex=None: Correctly printes on two sheets
>     - ps-test & pdf-test with sides=two-sided-long-edge: Correctly duplexes
> long edge
>     - ps-test & pdf-test with sides=two-sided-short-edge: Incorrect: duplexes
> on long edge
>     - ps-test & pdf-test with sides=one-sided: Incorrect: duplexes on long edge
>     - For the above, /etc/cups/lpoptions had Default dell5110cn
> Duplex=DuplexNoTumble sides=two-sided-long-edge.  I may test with more

I changed /etc/cups/lpoptions to have "Default dell5110cn sides=two-sided-long-edge" and all the above tests duplex correctly.

Very happy here.

Running more test.  More data in a few days.

Eric Schott,
for general information regarding the various ways
of option settings and possible confusions, see
http://en.opensuse.org/SDB:Print_Settings_with_CUPS

I think in your case the default option settings
via lpoptions might mix up with the individual
option settings via lp command line parameters '-o...'
or with individual option settings in print menues of
application programs so that in the end the CUPS filters
might get self-contradicting option settings like

sides=two-sided-long-edge sides=two-sided-short-edge
(one from lpoptions the other one from lp command)

CUPS filters get all option settings via argv[5],
see "man 7 filter". To see which option settings
have been actually used for a print job, set in
/etc/cups/cupsd.conf "LogLevel debug" and
restart the cupsd. Then argv[5] will be shown
in /var/log/cups/error_log

If CUPS filters get self-contradicting option settings
it would be random which option setting is actually used.

Furthermore in comment#43 you wrote
"/etc/cups/lpoptions" and "remote client":
If I remember correctly, /etc/cups/lpoptions is only applied
for print jobs that are submitted on the host where the
/etc/cups/lpoptions is. This means that for print jobs that
come in from a remote client a /etc/cups/lpoptions file
on that client is used but a /etc/cups/lpoptions file on
the print server is not used. The actual behaviour may
even depend on the CUPS version.

See in particular the "Suggestion for Keeping an Overview" in
http://en.opensuse.org/SDB:Print_Settings_with_CUPS

(In reply to comment #41)
> Only for the log:
> Request 143497 was accepted by msmeissn
> so that currently there is the fixed cups
> as package cups.openSUSE_12.2_Update
> in project openSUSE:Maintenance:1147

After upgrading from opensuse 12.1 to 12.2 I had similar issues with my HP LaserJet P3005 regarding failures to duplex print when using browsers, etc. After applying the appropriate (matching my configuration) RPM's from Maintenance:1147, duplex printing now works correctly. Tested portrait, landscape, DuplexNoTumble and DuplexTumble.

Update released for openSUSE 12.2. I'll close the bug resolved fixed, but feel free to reopen it if something is still wrong.

openSUSE-RU-2012:1662-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 776080
CVE References: 
Sources used:
openSUSE 12.2 (src):    cups-1.5.3-2.4.1

Fixed cups in the "Printing" project accordingly
via submitrequest 146146
and forwarded this to openSUSE:Factory
via submitrequest 146147

FYI,
a possible regression on SLE11-SP1 systems
related to comment#32 "check in the build system is broken":

On one of my workstations I run SLED11-SP1
where xpdf-tools was installed.

Accordingly I had initially "BuildRequires: pdftools_any" in cups.spec
because this is provided by xpdf-tools and by poppler-tools
to make the build work even for SLE_11_SP1.

But our build system for SLE_11_SP1 installs poppler-tools-0.12.3
and even that version has /usr/bin/pdftops that supports the
"-origpagesizes" option so that I got CUPS build for SLE_11_SP1
where /usr/lib/cups/filter/pdftops calls /usr/bin/pdftops
with "-origpagesizes".

But on my workstation where I have SLED11-SP1 with xpdf-tools
I could no longer print any PDF because /usr/bin/pdftops
from xpdf-tools aborts because it does not know about
the "-origpagesizes" option.

The only possible solution is to replace xpdf-tools
by poppler-tools >= 0.12.3 on SLE11-SP1 workstations.

Because our build system installs poppler-tools "everywhere"
I use now "BuildRequires: poppler-tools" in cups.spec
to make it more obvious what is actually used for build.

FYI:

A summary for CUPS in the "Printing" project
whether or not /usr/lib/cups/filter/pdftops
calls /usr/bin/pdftops with "-origpagesizes":
------------------------------------------------------------------------------
$ for r in SLE_11 SLE_11_SP1 SLE_11_SP2 \
  openSUSE_11.4 openSUSE_12.1 openSUSE_12.2 \
  openSUSE_Factory openSUSE_Tumbleweed ; \
  do for a in i586 x86_64 ; \
     do echo $r $a ; \
        osc remotebuildlog Printing cups $r $a \
        | grep -o ' checking whether pdftops supports -origpagesizes.*' ; \
     done ; \
  done

SLE_11 i586
 checking whether pdftops supports -origpagesizes... no

SLE_11 x86_64
 checking whether pdftops supports -origpagesizes... no

SLE_11_SP1 i586
 checking whether pdftops supports -origpagesizes... yes

SLE_11_SP1 x86_64
 checking whether pdftops supports -origpagesizes... yes

SLE_11_SP2 i586
 checking whether pdftops supports -origpagesizes... yes

SLE_11_SP2 x86_64
 checking whether pdftops supports -origpagesizes... yes

openSUSE_11.4 i586
 checking whether pdftops supports -origpagesizes... yes

openSUSE_11.4 x86_64
 checking whether pdftops supports -origpagesizes... yes

openSUSE_12.1 i586
 checking whether pdftops supports -origpagesizes... yes

openSUSE_12.1 x86_64
 checking whether pdftops supports -origpagesizes... yes

openSUSE_12.2 i586
 checking whether pdftops supports -origpagesizes... yes

openSUSE_12.2 x86_64
 checking whether pdftops supports -origpagesizes... yes

openSUSE_Factory i586
 checking whether pdftops supports -origpagesizes... yes

openSUSE_Factory x86_64
 checking whether pdftops supports -origpagesizes... yes

openSUSE_Tumbleweed i586
 checking whether pdftops supports -origpagesizes... yes

openSUSE_Tumbleweed x86_64
 checking whether pdftops supports -origpagesizes... yes
------------------------------------------------------------------------------

It seems this CUPS update for openSUSE 12.2 that lets
/usr/lib/cups/filter/pdftops call "pdftops -origpagesizes"
to fix this bug apparently triggers the next bug:
bnc#795582
  "pdftops -origpagesizes" fails with signal 8
  at least for some PDFs made by cairo

As expected the switch from PostScript to PDF as standard print job format
(see http://en.opensuse.org/Concepts_printing)
that is advocated by the OpenPrinting workgroup of the Linux Foundation
causes some pain until PDF printing actually works well, compare
https://bugzilla.novell.com/show_bug.cgi?id=732442#c5

This is an autogenerated message for OBS integration:
This bug (776080) was mentioned in
https://build.opensuse.org/request/show/146147 Factory / cups