"Copies" and "Two-sided" options interact incorrectly

Bug #325436 reported by Nelson Elhage
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libgnomeprint (Ubuntu)
Expired
Low
Unassigned

Bug Description

Steps to reproduce:

You need a printer with a duplexer. Load a single-page document in something that prints using libgnome-print. I've tested evince and edit. Set "Copies" to 2 on the "General" tab, and set "Two-sided" to "Long edge" ("short edge" probably has the problem too), and print the document.

Expected behavior: The printer prints two sheets of paper, each with the document printed on one side.
Observed behavior: The printer prints a single sheet of paper, with the document printed once on each side.

Ubuntu version:
[nelhage@phanatique:~]$ lsb_release -rd
Description: Ubuntu 8.10
Release: 8.10

libgnomeprint2.2-0:
  Installed: 2.18.5-1
  Candidate: 2.18.5-1
  Version table:
 *** 2.18.5-1 0
        500 http://mirrors.ccs.neu.edu intrepid/main Packages
        100 /var/lib/dpkg/status

evince:
  Installed: 2.24.1-0ubuntu1
  Candidate: 2.24.1-0ubuntu1
  Version table:
 *** 2.24.1-0ubuntu1 0
        500 http://mirrors.ccs.neu.edu intrepid/main Packages
        100 /var/lib/dpkg/status

Revision history for this message
Nelson Elhage (nelhage) wrote :

> I've tested evince and edit.

Whoops, that was supposed to read "gedit"

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

If you print directly to CUPS with something like

lpr -o Duplex=DuplexNoTumble -#2 /usr/share/system-config-printer/testpage-a4.ps

or from a non-GNOME app like OpenOffice.org it comes out correctly?

Revision history for this message
Nelson Elhage (nelhage) wrote :

> lpr -o Duplex=DuplexNoTumble -#2 /usr/share/system-config-printer/testpage-a4.ps

That command-line does not come out correctly (It produces a single sheet).

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Can you please attach the PPD file of your print queue (it is in /ec/cups/ppd/)? Can you also tell which printer model you have and whether it supports multiples copies and/or collated copies by hardware?

Revision history for this message
Nelson Elhage (nelhage) wrote :

I'm printing through a remote CUPS server, so I'm not sure how to get a copy of the PPD. The web interface lists the driver as "HP LaserJet 8150 Foomatic/Postscript (recommended)". The printer is a HP LaserJet 8150DN. I believe it does implement multiple copies in hardware, although I don't know if can collate.

I'm not sure if this is useful, but if I produce two duplex copies at the PS level by inserting
<< /NumCopies 2 /Duplex true >> setpagedevice
just after the preamble in testpage-letter.ps, and print that document, it does exhibits the correct behavior.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

First, the PPD file selected for your printer on the print server is not the best one. Perhaps on the server (whatever distro it is running) the manufacturer-supplied PPDs (part of either the HPLIP or the foomatic-db package) are not installed there. You can get also the single manufacturer-supplied PPD file for your printer from

http://openprinting.org/show_printer.cgi?recnum=HP-LaserJet_8150

If you want to see/download a printer's PPD on a remote CUPS server, go to the web interface of CUPS (http://localhost:631/), go to the page to manage the existing print queues and select the desired printer. When you are on the printer's page, add ".ppd" to the end of the URL and press Return. Then the printer's PPD gets displayed in the browser and you can save it locally with "File"/"Save as ...".

The URL of a printer's page looks usually like that

http://<name or IP of server>:631/printer/<queue name>

and of the PPD:

http://<name or IP of server>:631/printer/<queue name>.ppd

You can also wget this URL, for example to let a script read the PPD file.

The PPD you are using is very generic and therefore does not support printer-internal features to simplify printing multiple copies. It contains

*cupsManualCopies: True

which means that multiple copies get implemented by sending the job's full content repeatedly, once per copy. It does not contain "*cupsEvenDuplex" nor a "Collate" option.

Your test of adding "/NumCopies 2" to the PostScript code (this code sets the item NumCopies to the value 2 in the setpagedevice dictionary) shows that the printer is actually able to do multiple copies internally.

According to the manufacturer-supplied PPD file the printer supports multiple copies by hardware and it also supports collate by hardware, but this only with a hard disk. So collated copies have to be done by CUPS, in our case by the pdftopdf filter if there is no disk in the printer.

Can you try the following:

Set up a queue for you printer with the generic PPD (Foomatic/Postscript) and edit the PPD (/etc/cups/ppd/<queue>.ppd) adding the line "*cupsEvenDuplex: True" right after the line "*cupsManualCopies: True". Restart CUPS ("/etc/init.d/cups restart") and see whether this queue prints the copies correctly.

Set up a queue with the manufacturer-supplied PPD. Does this work?

If one looks at above-mentioned manufacturer

Revision history for this message
Nelson Elhage (nelhage) wrote :

> Set up a queue for you printer with the generic PPD
> (Foomatic/Postscript) and edit the PPD (/etc/cups/ppd/<queue>.ppd)
> adding the line "*cupsEvenDuplex: True" right after the line
> "*cupsManualCopies: True". Restart CUPS ("/etc/init.d/cups restart")
> and see whether this queue prints the copies correctly.

That works correctly, but the printer also prints a blank page after
each copy.

> Set up a queue with the manufacturer-supplied PPD. Does this work?

That works as expected. I guess I will try to get the CUPS server
maintainers to update their PPDs to more correct ones.

I don't claim to understand very much about CUPS or printing, but it
still seems like a bug to me that using a more generic PPD will result
in duplexing multiple copies together. I would expect that the worst
it should cause is CUPS doing the copies itself, rather than having
the printer do it.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Can you try again the generic PPD file (Foomatic/Postscript) but with the "*cupsEvenDuplex: True" line removed? Do not forget to restart CUPS after editing the PPD file.

Does this work correctly for you?

Revision history for this message
Nelson Elhage (nelhage) wrote : Re: [Bug 325436] Re: "Copies" and "Two-sided" options interact incorrectly

That appears to have the same behavior as without the "cupsEvenDuplex"
line (i.e. prints two copies, with a blank page after each).

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

So with the generic PPD you have the same behavior with and without the "*cupsEvenDuplex: True" line?

For me it looks like that the copies get generated and also extra blank pages so that the next copy starts on a new sheet, but it also seems to me that when this is sent to the printer the printer does not switch into duplex mode.

Can you let the output of your new print queue with the generic PPD file go into a file by running

cupsfilter -m application/vnd.cups-postscript -p /etc/cups/ppd/<queue name for generic PPD>.ppd -n 2 -o Duplex=DuplexNoTumble /usr/share/system-config-printer/testpage-a4.ps > output.ps

and attach output.ps?

Which URL did you use for your test queues?

The wrong output when printing through your server (Both copies on the same sheet) is a problem of the operating system running on the server (I cannot reproduce it on Intrepid or Jaunty). Please report a bug to the supplier of that system.

Revision history for this message
Nelson Elhage (nelhage) wrote :

> So with the generic PPD you have the same behavior with and without the
> "*cupsEvenDuplex: True" line?

Yes. The result of printing using the unmodified generic PPD is
attached. I used the URL lpd://<hostname>/<queuename> when configuring
the printer.

The print server is apparently running Hardy, so the bug may have been
fixed since then.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

The output is correct. You have run the "cupsfilter" command on the client (Intrepid)?

Can you also run it on the server (Hardy) and attach the output, too?

Revision history for this message
Nelson Elhage (nelhage) wrote :

Attached. I used the same ppd; Let me know if I should re-generate one
on the server.

Revision history for this message
Zeno Gantner (zeno-gantner) wrote :

I have the same problem (can be reproduced following the steps in the original bug report).

However,
lpr -o Duplex=DuplexNoTumble -#2 /usr/share/system-config-printer/testpage-a4.ps
produces two single papers, as it should be.

I have also attached the ppd file.

Please let me know if you need more information.

lsb_release -rd
Description: Ubuntu 8.10
Release: 8.10

reportbug --bts=debian -q --template -T none -s none -S normal -b --list-cc none -q libgnomeprint2.2-0
Warning: no reportbug configuration found. Proceeding in novice mode.
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'Zeno Gantner <mrg@take>' as your from address.
Getting status for libgnomeprint2.2-0...
Will send report to Debian (per request).
Maintainer for libgnomeprint2.2-0 is 'Ubuntu Core Developers <email address hidden>'.
Looking up dependencies of libgnomeprint2.2-0...

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Zeno Gantner <mrg@take>
To: Debian Bug Tracking System <email address hidden>
Subject: none
X-Debbugs-Cc: none

Package: libgnomeprint2.2-0
Version: 2.18.5-1
Severity: normal

-- System Information:
Debian Release: lenny/sid
  APT prefers intrepid-updates
  APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500, 'intrepid-proposed'), (500, 'intrepid-backports'), (500, 'intrepid')
Architecture: i386 (i686)

Kernel: Linux 2.6.27-14-generic (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libgnomeprint2.2-0 depends on:
ii libart-2.0-2 2.3.20-2 Library of functions for 2D graphi
ii libc6 2.8~20080505-0ubuntu9 GNU C Library: Shared libraries
ii libcomerr2 1.41.3-1ubuntu1 common error description library
ii libcups2 1.3.9-2ubuntu8 Common UNIX Printing System(tm) -
ii libfontconfig1 2.6.0-1ubuntu4 generic font configuration library
ii libfreetype6 2.3.7-2ubuntu1 FreeType 2 font engine, shared lib
ii libglib2.0-0 2.18.2-0ubuntu2.1 The GLib library of C routines
ii libgnomecups1.0 0.2.3-2build1 GNOME library for CUPS interaction
ii libgnomeprint2. 2.18.5-1 The GNOME 2.2 print architecture -
ii libgnutls26 2.4.1-1ubuntu0.3 the GNU TLS library - runtime libr
ii libkrb53 1.6.dfsg.4~beta1-3 MIT Kerberos runtime libraries
ii libpango1.0-0 1.22.2-0ubuntu1 Layout and rendering of internatio
ii libxml2 2.6.32.dfsg-4ubuntu1.1 GNOME XML library
ii zlib1g 1:1.2.3.3.dfsg-12ubuntu1 compression library - runtime

libgnomeprint2.2-0 recommends no packages.

-- no debconf information

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Zeno, which OS is your client and which OS your server? Note that CUPS processes the jobs on the server.

Changed in libgnomeprint (Ubuntu):
status: New → Incomplete
Revision history for this message
Zeno Gantner (zeno-gantner) wrote :

Hi Till, sorry for the late reply,

The information above is (was) the computer I ran evince and lpr on.
The "server" is a remote printer with a network card, an HP Laserjet 4250dtn.

Does that help?

btw, the client information has changed.
Still the same behavior, for both long and short edge.

Best regards,
  Z.

# lsb_release -rd
Description: Ubuntu 9.04
Release: 9.04

Versions of packages libgnomeprint2.2-0 depends on:
ii libart-2.0-2 2.3.20-2 Library of functions for 2D graphi
ii libc6 2.9-4ubuntu6 GNU C Library: Shared libraries
ii libcomerr2 1.41.4-1ubuntu1 common error description library
ii libcups2 1.3.9-17ubuntu3.1 Common UNIX Printing System(tm) -
ii libfontconfig1 2.6.0-1ubuntu12 generic font configuration library
ii libfreetype6 2.3.9-4ubuntu0.1 FreeType 2 font engine, shared lib
ii libgcrypt11 1.4.1-2ubuntu1 LGPL Crypto library - runtime libr
ii libglib2.0-0 2.20.1-0ubuntu2 The GLib library of C routines
ii libgnomecups1. 0.2.3-3 GNOME library for CUPS interaction
ii libgnomeprint2 2.18.6-1 The GNOME 2.2 print architecture -
ii libgnutls26 2.4.2-6 the GNU TLS library - runtime libr
ii libkrb53 1.6.dfsg.4~beta1-5ubuntu2 MIT Kerberos runtime libraries
ii libpango1.0-0 1.24.1-0ubuntu1 Layout and rendering of internatio
ii libtasn1-3 1.5-1 Manage ASN.1 structures (runtime)
ii libxml2 2.6.32.dfsg-5ubuntu4 GNOME XML library
ii zlib1g 1:1.2.3.3.dfsg-12ubuntu2 compression library - runtime

libgnomeprint2.2-0 recommends no packages.

Versions of packages libgnomeprint2.2-0 suggests:
ii cups 1.3.9-17ubuntu3.1 Common UNIX Printing System(tm) -

Changed in libgnomeprint (Ubuntu):
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for libgnomeprint (Ubuntu) because there has been no activity for 60 days.]

Changed in libgnomeprint (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.