gnome programs don't respect ~/.cups/lpoptions

[Superkatze]

I managed this problem and many duplicates bugs :

    * Bug #31864
    * Bug #38149
    * Bug #41303
    * Bug #41304
    * Bug #41402

So i resume here the problem.

When you use Gnome-Cups-Manager to mark a printer as default user, or when you change some parameters (like PageSize), modifications are saved in ~/.cups/lpoptions . This comportement is ok.

But this user configuration file is not used by gnome-cups-manager so user's parameters like default printer or user default parameters are not used.

STEP TO REPRODUCE THE BUG:
open gnome-cups-manager
add a new local printer (even if you don't have one)
change settings (like paper format A4/A5/A3 ...)
close gnome-cups-manager
view ~/.cups/lpoptions ... your changes are well saved.
open gnome-cups-manager
go to printer settings and you can see that your changes are lost

> ORIGINAL DESCRIPTION
>If I set my printer (HP Deskjet 6540 with hplip) to fast >draft mode it will not work. It still prints in normal mode.
>
>If I look at the web frontend for cups the settings didn't >change.
>
>If I change the settings directly in the web frontend it >works as desired.

[Tim (tim-redhat-bugs)]

Description of problem:
When printing a job to a remote CUPS queue using lp or lpr, the options seen in
'lpoptions -p dest' are included in the job. When printing from an application
using libgnomecups (such as gedit or evince), these options are not sent with
the job.

Version-Release number of selected component (if applicable):
libgnomecups-0.2.0-2

How reproducible:
100%

Steps to Reproduce:
1. Make a queue called 'dest' on server1.
2. Edit /etc/foomatic/filter.conf on server1 and add 'debug: 1'
3. On server1, make sure server2 has access to the queue.
4. On server2, 'lpoptions -ddest -ofitplot'
5. On server2, 'lp -ddest /usr/share/evolution/2.2/help/quickref/C/quickref.pdf'
6. On server1, cp /tmp/foomatic-rip.log /tmp/foomatic-rip.lp
7. On server2, 'evince /usr/share/evolution/2.2/help/quickref/C/quickref.pdf'
and print it to dest.
8. On server1, cp /tmp/foomatic-rip.log /tmp/foomatic-rip.evince
9. Compare /tmp/foomatic-rip.lp and /tmp/foomatic-rip.evince, and the print-outs.

Actual results:
foomatic-rip.lp shows the 'fitplot' option is passed, foomatic-rip.evince shows
it is not.

Print-out from 5 is scaled to fit, but from 7 is not.

Expected results:
Both print-outs scaled to fit.

[Pascal De Vuyst (pascal-devuyst)]

What is the application you printed from?
I did a test with my HP DeskJet 3820 printer using OpenOffice.org and draft and normal mode printout both work.

The CUPS web interface changes default printer options directly in the PPD files located in /etc/cups/ppd.

gnome-cups-manager printer options are saved in ~/.lpoptions

You can type this in a terminal to see if options are set by gnome-cups-manager:
$ lpoptions

[Matthias Klose (doko)]

please recheck after a dist-upgrade to dapper 20060414, removal and reinstallation of the printer

[ARR (alanrr-sr)]

I am using a epson CX 4100, and changes are not applied for the printer (even the "set default" change"
I could not that if I try to change in WEB interface, I get printer not found... maybe because of the freak name of the driver?? (CX4100---CUPS+Gutenprint-v5.0.0-rc2)

[Holger Arnold (holgerarnold)]

If I start the printer setup dialog by "sudo gnome-cups-manager", then changes to the printer options are preserved (and shown in the "Properties" dialog of the printer).

Strangely, these settings are not used when printing, and, more strangely, the web interface of CUPS shows different settings than gnome-cups-manager.

[Holger Arnold (holgerarnold)]

If I change a setting in gnome-cups-manager (started from the menu), the file ~/.lpoptions is deleted. I don't think that this is the intended behavior.

This bug seems to be related to #26122.

[Gerry Tool (gerry-thetoolshed)]

The gnome-cups-manager app appears to change the paper size from A4 to US Letter, but if I print a test page it is still A4. The change is not persistent. When I look at the properties of the printer again, it is still set to A4. I tried in the localhost:631 interface, but according to the page it is disabled, and of course if I enter my name and password, it just keeps asking over again. Since there is no root account, I can't try as root in the web interface.

If I run sudo gnome-cups-manager, the paper size change sticks. However, since the web interface still shows the paper size to be A4 (yes, I did a fresh view), thee is a very large upper margin on the top of the page. I have had this problem in many gnome systems, and it is always indicative that localhost:631 and gnome-cups-manager have different settings.

Since I can't make the change in localhost:631, I cannot get rid of this large top margin. This causes progarms like glabels to not be able to line up the label with the medium.

[Gerry Tool (gerry-thetoolshed)]

OK, I found the file with instructions on enabling the web interface. I did that, rebooted, and was able to set the paper size in the web interface to the same value as in gnome-cups-manager. The top margin is now correct.

However, this is not going to fly if normal users cannot set the paper size and have it viewed as the same value in both interfaces. That needs fixing.

[Gerry Tool (gerry-thetoolshed)]

Sorry, I spoke too soon about the margin.

Even with both interfaces reporting the same settings, glabels printing, and gedit printing, and probably any gxxx printing has too large a top margin. This testing was done using a Samsung ML-1750 laser printer set for US Letter and 1200x600dpi printing.

[Gerry Tool (gerry-thetoolshed)]

Update - sorry about the flip-flopping here, but I just succeeded in getting my Canon PIXMA ip-4000 working in Dapper using Turboprint 1.94-2. I set the printer up in the Turboprint config utility and then used the CUPS web interface to adjust the settings to be the same both places.

It prints from Glabels now with the CORRECT top margin.

I was still curious why the Samsung top margin is too large, so I tried the lj4dith driver instead of the recommended pxlmono driver. That fixed the top margin problem for that printer.

[Martin Pitt (pitti)]

This seems to bite many people, upgrading severity.

[Andrew Jorgensen (ajorg)]

What more info is needed on this bug?

[Carthik Sharma (carthik)]

Confirmed bug. Needs Info seems inappropriate to at least one subscriber.
As a note, this remained "needs info" since others like me might have hesitated to spam all the subscribers to this bug. Thank you for reporting this bug.

[Paul Sladen (sladen)]

This needs some looking at.

[Martin Pitt (pitti)]

Got it! Testing patch with Patrice now.

[Martin Pitt (pitti)]

 libgnomecups (0.2.2-1ubuntu3) dapper; urgency=low
 .
   * libgnomecups/gnome-cups-printer.c, parse_lpoptions(): Do not only look in
     the obsolete ~/.lpoptions file, but also into ~/.cups/lptoptions. This
     fixes the handling of user defined printer settings, default printer, etc.
     Closes: LP#34112 and half a thousand duplicates.

Finally! Feedback appreciated, but it works just fine here now (for Patrice as well).

[hove99 (hove99)]

When I modify properties for a printer (System -> Administration -> Printing), I can see the changes in ~/.cups/.lpoptions, but the changes cannot be seen in (System -> Administration -> Printing). However, the options seem to have gone in to effect, since I can enable and disable duplexing.

[Patrice Vetsel (vetsel-patrice)]

Hove99 : please see Martin 's comment before your's and wait for libgnomecups (0.2.2-1ubuntu3) :)

[Andrea Garbarini (garba)]

okie now the lpoptions file in .cups is updated accordingly and gnome-cups-manager properly seems to parse it, problem is, I've just printed a doc from evince but my personal settings are still ignored, it's the system wide settings that are being used (i.e. stuff in /etc/cups/pppd)

[Patrice Vetsel (vetsel-patrice)]

This Bug is closed. And your problem is with evine not gnome-cups-manager.
If you have a bug with evince please create a new one after a search if the bug is already reported.
Thank you

[Jens Berke (jensberke)]

I've got the same problem Andrea reported two posts above. I checked with Evince, GPdf and GEdit, and all three applications don't care about the settings I made wth gnome-cups-manager. I've got Dapper Release Candidate 1 with libgnomecups 0.2.2-1ubuntu5 installed. Maybe this bug needs to be reopened?

Jens

[drafil (dragosfilipescu)]

Hi Berke!
Have you tried to reinstall your printer?

[Jens Berke (jensberke)]

You mean removing it in gnome-cups-manager and then installing it again? If so, yes, several times, but to no avail.
Jens

[drafil (dragosfilipescu)]

Yes, Jens, but forget it! I have the same problem! :((
I can print from Windows to Ubuntu printer well (there are the setting made on Windows machine that are applied), but when printing from Ubuntu, my settings are ignored...
I think this bug should be reopened.

[Martin Pitt (pitti)]

Reopening, it seems that there is still an issue with that.

[Jens Berke (jensberke)]

If you need more info (debug info, logs, config files...) let me know and I see what I can do.
Jens

[Sean Middleditch (elanthis)]

My issues detailed in bu #44469 are still present, with libgnomecups1.0-1 0.2.2-1ubuntu5.

My .cups/lpoptions is configured correctly. The problem is that all libgnomeprint-using applications ignore the settings set in the individual print-dialog UIs (that is, the dialog reflects the settings in .cups/lpoptions, but doesn't use them), while non-libgnomeprint-using applications honor the defaults *and* actually work correctly.

[Dirk (ubuntu-tobit)]

Sorry about the "me too" post, but I cannot stress enough that this is NOT a duplicate of any bug to do with *lpoptions.

The bug we are complaining about is that any attempt to alter the default options presented in the libgnomeprint dialogs for a print are either ignored (eg duplex printing or tray selection) or wrongly implimented (as in landscape: where the print is done landscape, but on portrait oriented paper).

Just to be clear here, we are specifically NOT talking about storing or using stored options, we are complaining about print specific, default overriding, selections.

[drafil (dragosfilipescu)]

I have exactely the same problem reported by Sean Middleditch two posts above.

[Pascal De Vuyst (pascal-devuyst)]

We have 2 bugs here:
- libgnomecups looking in the obsolete ~/.lpoptions instead of ~/.cups/lpoptions, this was fixed in libgnomecups 0.2.2-1ubuntu3.
- libgnomeprintui ignoring ~/.cups/lpoptions as described below, this is still not fixed.

I did some debugging of foomatic-rip and come to the following conclusion.

Printing options can be set in 2 ways:
- By changing Default values in the configured PPD for your printer in /etc/cups/ppd, this is done for printing options set by CUPS web interface.
- By setting options in ~/.cups/lpoptions, this is done by gnome-cups-manager.

Now the problem is that printing options set with gnome-cups-manager in ~/.cups/lpoptions are not applied when printing from a gnome application (libgnomeprintui), only options from the configured PPD in /etc/cups/ppd are used.

When printing from a non-libgnomeprintui application (e.g. firefox or the command line) both the options from the configured PPD /etc/cups/ppd and ~/.cups/lpoptions are applied, in that order (meaning options in ~/.cups/lpoptions override options in the configured PPD).

The way I see it there are 2 possible solutions:
* gnome-cups-manager should directly change printer options in the configured PPD like CUPS web interface does. This is the recommend way since it will work with every application understanding PPDs.
* Or gnome applications (libgnomeprintui) should make use of printer options in ~/.cups/lpoptions. Perhaps this one is easier to fix.

I already suggested these solutions 3 months ago in bug #26122.

I have no C programming experience, please can somebody fix this before dapper release.

[Patrice Vetsel (vetsel-patrice)]

@Pascal De Vuyst

It's normal that libgnomeprintui ignore lpoptions, that lib has nothing to do with it.
libgnomeprint should not have to interact with lpoptions, but it's too late to do anything.

For informations :
~/.cups/lpoptions is changed by gnome-cups-manager when used normally by the user
/etc/cups/ppd/ drivers are changed by gnome-cups-manager run as ROOT or by cups web interface.

It's clear that a quick work around for this bug is to always run gnome-cups-manager as root (using gksudo). Pitti ?!

The best is to find where user options are lost. May be libgnomeprintui forgot to return all options passed for dialogs or ...

[Andrea Garbarini (garba)]

Actually, running gnome-cups-manager as root won't cause the ppd driver in /etc/cups/ppd to get modified, at least on my box here.

[Jens Berke (jensberke)]

Same here: gnome-cups-manager as root is no workaround.

[Patrice Vetsel (vetsel-patrice)]

Sorry :/
running gnome-cups-manager save changes in /etc/cups/lpoptions

[Jens Berke (jensberke)]

Ok, /etc/cups/lpoptions is modified actually when running "gksudo gnome-cups-manager". File looks like it should according to my settings:

Dest DeskJet-5940 PrintoutMode=Draft.Gray Quality=FromPrintoutMode PageRegion=A4

but these settings are ignored.

Don't know if this has something to do with the bug, but I get the following output only when starting gnome-cups-manager with gksudo:

(gnome-printer-view:5539): GnomeUI-WARNING **: While connecting to session manag er:
Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.

[Pascal De Vuyst (pascal-devuyst)]

This bug also exists in Fedora, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157878.
Can somebody change this bug number in the Fedora bug watch, initially I gave the wrong bug number and now I am unable to change it.

[ozonehole (taibei)]

I don't know if I should be posting this here, but anyway, I was one of the people who originally reported this bug (when I was running Dapper beta). Now I've installed Dapper final release, and the situation has changed. Instead of getting draft printing when I should be printing high quality, I'm simply not getting any printing at all. I can setup the printer and jobs will queue, but nothing gets printed.

Whatever has been changed between the beta and final release killed my printing altogether.

My printer is an Epson 24-pin dot-matrix on /dev/lp0.

cheers,
Robert

[Pascal De Vuyst (pascal-devuyst)]

The problems described here are because gnome-print libraries are not maintained and buggy. Thanks to Project Ridley these libraries are abandoned and a new printing dialog and libraries will be part of GTK+ (available in GTK+ 2.10). These new libraries will bring a better printing experience and are the right way forward. More info on http://live.gnome.org/ProjectRidley.

Until then we are stuck with gnome-print in dapper (GTK+ 2.8). I have created a patch for libgnomeprint that improves the current printing experience from gnome applications by:
  * Reading options set in PPD, /etc/cups/lpoptions and ~/.cups/lpoptions by making use of gnome_cups_printer_get_options from libgnomecups. This makes sure that options set by gnome-cups-manager will be applied, even options that can't be changed in the gnome print dialog like Printing Quality.
  * allowing more options to be usable in the gnome print dialog: changing of Paper Size, Page Orientation (e.g. Landscape), Duplex and Tumble, 2 pages to 1 and 4 pages to 1. These options only apply to the current print job and are not saved when closing the gnome application.
This was part was inspired by gnome-bug 166564.
Hard to believe that e.g. landscape printing didn't work in gnome apps, this fix solves that.

You find the patch in attachment. This patch solves bug #34112 and its duplicates according to me in the best way possible for the current gnome-print implementation. I advice everyone to test it and to report possible problems with it.

[Pascal De Vuyst (pascal-devuyst)]

This patch lets gnome applications use the printing options set in gnome-cups-manager.

[Andrea Garbarini (garba)]

thanks a LOT for the patch Pascal, i've just rebuilt the libgnomeprint package applying ur patch and now i can print multiple pages on a single page :)

[Andrea Garbarini (garba)]

I also happily report that now even the settings applied in gnome-cups-manager are honored when printing through the gnome frontend, thanks again!

[Prinz Igor (pigor)]

how can i build and patch libgnomeprint by myself?

will the patch be part of dapper soon? i mean so that "normal" users can print again?

[Andrea Garbarini (garba)]

there's a post of mine at the ubuntu forums with the patched debs attached:

http://www.ubuntuforums.org/showthread.php?t=190714

hope this helps, regards, andre

[Jens Berke (jensberke)]

Many many thanks for that patch. I can confirm that now the settings for printer quality and grayscale are used. Tested with Evince and GEdit (using the debs provided in ubuntuforums).

[Prinz Igor (pigor)]

one question to all which have applied the patch successfully: do you use turboprint?

my problem is that (with turboprint) every job is queued but nothing happens. perhaps i have to open a new bug ...

[Ante Karamatić (ivoks)]

Open new bug only if there are problems with official package. If there are problems with patched package, them you should discuss it with author of that patch/package.

[Jens Berke (jensberke)]

Found a bug with the patch applied (reason for that bug might be in a different package, though): printing a pdf that has text and images in it, with the option for "layout" set to "2 pages on 1", produces the 2 on 1 now but with big black boxes beneath some of the images. These boxed overlay the text, which is printed fine. If needed, I can post an attachment which shows how it looks like.

[Prinz Igor (pigor)]

> Open new bug only if there are problems with official package.

that's because i have make my question. i don't know if it is a special turboprint problem or a general problem with ubuntu-print.

so again: are there any people using turboprint who have applied the patch above? is it working or not?

[Martin Pitt (pitti)]

Closing libgnomeprintui task

[Martin Pitt (pitti)]

Fixing affected source package

[Martin Pitt (pitti)]

Pascal, thanks a lot for your patch! I tested it and it works just fine. I built a test package (amd64 and i386, and source) on

  deb http://people.ubuntu.com/~pitti/packages/libgnomeprint/ ./
  deb-src http://people.ubuntu.com/~pitti/packages/libgnomeprint/ ./

just add this to /etc/apt/sources.list, sudo apt-get update, and upgrade. More test reports greatly appreciated!

[Martin Pitt (pitti)]

Once we have enough test reports and Matt approves, I'll upload this to dapper-updates.

[Florian L (flad)]

Duplex printing and 2-to-1 printing of pdf using evince (that's what I tried so far) works for me now using the new packages. The pdf has images in it and it prints fine for me (no black boxes like the ones reported above). Thanks!

[Patrice Vetsel (vetsel-patrice)]

Pitti :
trying to print here at home, with Canon iP3000 with turboprint drivers works as i want ! Patch is OK for me :)
Excellent patch Pascal De Vuyst !

I have to test it at work now ...

[Prinz Igor (pigor)]

@VETSEL Patrice:

i am using the same printer with turboprint too. but i cannot print. every time when i start a print job the panel icon appears but nothing else happens. all jobs are ignored. do you have changed anything else? (in xtpsetup is a message: "USB printer is busy; will retry in 5 seconds")

[Prinz Igor (pigor)]

i have tested a little bit more. printing with evince works fine!

but when i try to print with acroread nothing happens and i have to turn off and on my printer to print with evince again.

[Patrice Vetsel (vetsel-patrice)]

@Prinz :

installed turboprint.
run gnome-cups-manager to add printer and choosen canon turboprint ip3000 driver
nothing else.

@Pitti: patch seems ok at work too :)

[Prinz Igor (pigor)]

@VETSEL:

1) could you test another format please? e.g. 4x6 inch (10x15cm) borderless with gimp prints just a small bar on one side of the paper.

2) do you have tested acroread too?

[Sean Middleditch (elanthis)]

Prinz Igor: Neither GIMP nor Acroread use gnome-print. They're GTK applications, yes, but they're not GNOME applications. GIMP uses gimp-print and Acroread uses something else. Neither of these programs' problems should be related to this bug (theoretically). Are the problems only occurring after installing the patched libgnomeprint packages?

[Martin Pitt (pitti)]

Please be aware that acroread is not a gnome program and thus doesn't use libgnomeprint. Printing problems in acroread are entirely unrelated to this bug report.

[Prinz Igor (pigor)]

thanks sean. i did not knew that acroread and gimp use another printing-environment.

> Are the problems only occurring after installing the
> patched libgnomeprint packages?

the problem is not new.

@VETSEL: because you have the same printer as i - could you mail me please, if you have the same problems (printing with gimp or acroread and/or with excotic formats like 4x6inch borderless)? my mail-address is dev[at]ceglarek[dot]org

[Dirk (ubuntu-tobit)]

So does this mean that I need to open new bugs on gimp and acroread to reflect the fact that they use different printing mechanisms and they don't work?

Could I politely say that: not having printing working, to the extent of offering non-default options on dialogs and then ignoring them, not printing landscape correctly, if some are selected - on officially released product - strikes me as pretty show stopping bug for any serious or commercial user!

Please could you make sure that all the various paper location selections (eg top tray, bottom tray) work. Again, this is because commercial users will have different papers in these trays and will want to print on the correct one. If you want a concrete example for (a less serious) user, I have A4 normal paper in the top tray and thick 6x4 borderless glossy photo paper in the bottom tray of a Canon IP4000. Currently I cannot print with *any* gnome based program (including gimp) on the bottom tray - whether I select it or not.

KDE programs - meanwhile - work flawlessly. But I don't want to use KDE.

[Martin Pitt (pitti)]

 libgnomeprint (2.12.1-3ubuntu2) dapper-updates; urgency=low
 .
   * Add debian/patches/cups-transport.patch:
     - Teach libgnomeprint to respect the settings made in the printing options
       dialog.
     - Many thanks to Pascal De Vuyst for this patch!
     - Closes: LP#34112 and the longest list of duplicates ever.

[Patrice Vetsel (vetsel-patrice)]

Many Thanks Pascal De Vuyst !

[Pascal De Vuyst (pascal-devuyst)]

Thanks for including this patch in dapper-updates.

@Dirk
Tray selection in libgnomeprint based apps should have worked before the patch and still should work with the patch.
I can't test this since I have a printer that has only one tray. Looking at foomatic-rip.log this should work since the option InputSlot is applied, can somebody verify that tray selection works?
If you still have the problem you should file a seperate bug report indicating that tray selection does not work for you specific printer model.

[Dirk (ubuntu-tobit)]

@Pascal

I have not yet tried the patch, but the only printing that ever happens in the current issue ubuntu is the whatever the default is for that printer. You cannot change it with the gnome printer dialog. Any changes/options one makes in the dialog is ignored. If the default is A4 600 dpi plain paper from the top tray, then that is what you get - regardless that you select 6x4, 2400 dpi, glossy photopaper from the bottom tray.

[Pascal De Vuyst (pascal-devuyst)]

@Dirk

Please file a seperate bug report for this.

[Pascal De Vuyst (pascal-devuyst)]

@Martin
The updated package is still not available from the archives. Any idea why?
Should we not mark this bug as "fix committed" until the fix has actually been released. This would allow people to still find the bug and avoid duplicates.

[Martin Pitt (pitti)]

Pascal: the package is available for quite some time now. "Fix committed" means I have a fix and prepared a package to upload. "Fix released" means it's in the archive.

[Martin Pitt (pitti)]

Sorry, the archive still does not have fixed binaries. Only the source is on the mirror, apparently the buildds need a manual kick to actually built the new package. Reopening bug until that's fixed.

[mannheim (kronheim)]

Maybe I have messed up apt, or misunderstood. But I don't think that binary debs are in the archive.

If I do "apt-get source" then I do get a source tree which contains the patch. But I don't see the binary debs in

http://archive.ubuntu.com/ubuntu/pool/main/libg/libgnomeprint/

[Peter Meiser (meiser79)]

Fix released. Thanks, Martin!

[Junglebz (junglebz)]

Guys ... I'm still having this issue in Ubuntu Dapper 6.06 and package libgnomeprint (2.12.1-3ubuntu2) installed.

Could anyone help me with this?

Thanks.
Fernando.

[Pascal De Vuyst (pascal-devuyst)]

@Junglebz

I believe the patch fixes printing for libgnomeprint based applications as far as it can be fixed, many people have confirmed it.
Perhaps you have a different issue that is only related to your printer model. You are not being very specific, please help us first by providing more information.
What printer model do you have? What application(s) did you try to print from?
The patch normally solves several issues, can you give examples of issues you still have (e.g. printer quality set in gnome-cups-manager not respected).

[Vincenzo Ciancia (vincenzo-ml)]

I have libgnomeprint2.2-0 version 2.12.1-3ubuntu, my lpoptions file has been set up by the gnome printer configuration interface, it contains Dest lj5 Duplex=DuplexNoTumble, I just removed and added the printer again, but it prints single-sided. Kde applications and firefox print double-sided.

[Ante Karamatić (ivoks)]

2.12.1-3ubuntu1 or 2.12.1-3ubuntu2?

[Tormod Volden (tormodvolden)]

Vincenzo, you are probably victim of the most irritating "feature" of dpkg -l, it silently truncates the output strings. Use "dpkg -l libgnomeprint2.2-0 | cat" or make a wide terminal window to see the complete version string.

[Vincenzo Ciancia (vincenzo-ml)]

Sorry for the late reply, I forgot to check the "e-mail me about changes" checkbox. I just tested that I still have the bug (removed and added the printer again) and that I have 2.12.1-3ubuntu2 - sorry for the inconvenience. This bug is really irritating, please tell me anything I can do to provide more information.

[Marcin Białoń (mbialon)]

Yesterday I checked this in a new, clean install of Dapper (libgnomeprint 2.12.1-3ubuntu2) and everything works fine.

[Dirk (ubuntu-tobit)]

Well I am using 2.12.1-3ubuntu2 and it (specifically selecting duplex for a print from the dialog box) does *not* work (and never has). However, as far as I can tell, paper selection and all the other options now *do* work.

Since the duplex check box is on a different screen to all the others, could it simply be that it has got overlooked?

Just a reminder: duplex printing is working in kde programs and manually with lpr with the "-o sides=two-sided-long-edge" option.

[Pascal De Vuyst (pascal-devuyst)]

@Vincenzo and Dirk
Please provide the following information:
1) Your printer model and the driver you use.
2) Tell us in which application(s) duplex printing does not work.
3) Please debug foomatic-rip to find out more: edit /etc/foomatic/filter.conf and set debug: 1. Print a document with duplex activated from gedit or evince. After printing attach the file /tmp/foomatic-rip.log here.

@Dirk
Does tray selection work for your printer after the update to libgnomeprint 2.12.1-3ubuntu2?

[Matthew (matthew-redhat-bugs)]

Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

[Tim (tim-redhat-bugs)]

I guess network default options will fix this in FC6 anyway.

[Huygens (huygens-25)]

Very weird, I have the problem yet again with evince 0.8 (Ubuntu Feisty Fawn).
My printer is an HP Laserjet 4345 and is configured in CUPS with the duplex mode. I can print with OpenOffice.org or other applications with the two side printed. However, if I open a PDF with Evince (the default), when I want to print I have only the "one-sided" possibility for the "two-sided" option (in Page set-up of the HP printer).
In all application I can print two-sided but Evince :-(

[Alexander Papaspyrou (lxndrp)]

I can confirm this, using Feisty with evince-0.8.1 with a HP LaserJet 4050. All other apps do duplex perfectly, just evince doesn't.

However, this seems to be a gnome-cups-admin issue. Although I setup my printer settings with the GNOME printer setup tool, none of the settings have been propagated to CUPS correctly. After setting things up via the CUPS web frontend, evince recognizes everything in the correct way and seems to work.

[chuan137 (chuan137)]

I have the same problem with evince-0.8-1.

"After setting things up via the CUPS web frontend, evince recognizes everything in the correct way and seems to work."

How is that done?

[Pascal De Vuyst (pascal-devuyst)]

@Alexander Papaspyrou and maybee
This is a different issue that has been reported as bug #111964, please add further comments there.

[Stijn (stijn-redhat-bugs)]

Tim, unfortunately this is not correct.

We have a network printer with duplex unit, which has a default of printing on
both sides. However it is impossible to make a *user* default option for one of
our users, who by default wants everything printed single-sided.

Fortunately Pascal de Vuijst fixed this for Ubuntu, see

https://bugs.launchpad.net/ubuntu/+source/libgnomecups/+bug/34112

especially comment 38. I'll upload his patch here as well. I've tested a rebuilt
libgnomecups22 on Fedora Core 6, and this problem is fixed for gedit.
Unfortunately Evince still doesn't comply with these user defaults, and I'm not
sure why. I'm investigating this next.

Note also that libgnomecups is looking for user options in the wrong place --
but that's a separate bug that I'll file also.

[Stijn (stijn-redhat-bugs)]

Created attachment 158429
respect user default CUPS options

Patch by Pascal de Vuyst that lets libgnomeprint respect the user default CUPS
options, as set by lpoptions(1).

[John (john-redhat-bugs)]

this needs to be refactored for gtkprint also

[Stijn (stijn-redhat-bugs)]

Created attachment 159409
patch for CUPS GtkPrint backend to honor ~/.cups/lpoptions

Turned out that Evince used GtkPrint instead of libgnomecups, indeed (I didn't
know that).

Attached is a patch to the FC-6 GTK+ (2.10.8) that enables both a user-set
default printer as well as user-set default options for printers.

As this is my first C code in a very long time, there's bound to be errors, so
please review carefully :)

[Stijn (stijn-redhat-bugs)]

Reported upstream as bug 469210 (
http://bugzilla.gnome.org/show_bug.cgi?id=469210 ).

[Matthias (matthias-redhat-bugs)]

These patches are in rawhide now.