« Media from Toronto trip | Home | More Japan trip links »

Workaround for "bad default print settings in GTK+" bug

Sun 21 Aug 2011 by mskala Tags used:

Today, after years of suffering, I finally managed to find a workaround for one of the several problems I'd been having with printing from GTK+ applications, in particular Firefox. Here are some notes for the benefit of others who may encounter the same thing.

BASIC SYMPTOMS: Every time I try to print something on my laser printer using a GTK+ application, I get inappropriate default settings (namely one-sided printing on card stock from the multi-purpose tray). If I don't change these defaults, the printer stops and waits for user intervention to insert card stock in the multi-purpose tray. Others reporting similar problems have often complained about letter-sized or A4 paper being the default when they wanted the other - sometimes adding a layer of chauvinistic slurs at countries following the other standard - but in fact I haven't had that particular problem myself.

DIFFERENTIAL DIAGNOSIS: The problem affects me most often when trying to print PDFs from the Web using Firefox, but it also appears in all other GTK+ applications, such as the GIMP, though there is a workaround for the GIMP in particular because the GIMP offers its own "gutenprint" dialogue which does not have the problem. But since the problem is global to GTK+ applications, the Firefox people say it has nothing to do with them, and they won't do anything about it. It's also true that the bad default values do not appear anywhere in Firefox's configuration files.

Firefox does not provide print configuration settings of its own that can override the bad defaults, and Firefox does not save the user's selections from one print job to the next. There have been numerous reported Firefox bugs over the fact that it doesn't save settings, over the course of many years, but since those bugs have remained unfixed, it's clear Firefox won't be doing anything about them soon. (I also found one person reporting as a Firefox bug the alleged fact that it does save printer settings; and one person reporting as a Firefox bug the fact that it allows users to adjust the settings at all, instead of just printing with the default settings all the time. I'm not sure what to make of those.) Firefox claims that it just uses and trusts GTK+'s print dialogue.

The same political issues apply to GTK+. GTK+ claims that it just uses and trusts the default settings from CUPS, and so users who want to change the defaults are advised to use the CUPS configuration for that. The screwy default print options shown by Firefox are not the default values I have set in CUPS, and changing the defaults set in CUPS (at least, if I do it according to the standard CUPS procedure by HTTP connection to localhost:631) has no effect on the problem.

Some people have suggested using the lpoptions command-line interface to change the default settings. That also doesn't work for me - I set those options to what I want and then Firefox ignores them and uses its own wacky defaults.

WHAT'S ACTUALLY GOING ON: It appears that GTK+, and therefore Firefox, does read the loptions settings, but it doesn't read them through the standard interface. Thus what lpoptions reports as its defaults are not actually what GTK+ uses as the defaults. What GTK+ uses is an incorrectly-parsed version of the /etc/cups/lpoptions file.

Here is what my /etc/lpoptions file looked like prior to my figuring out what was going on:

Dest zinc sides=two-sided-long-edge Duplex=DuplexNoTumble
Dest zinc/plain sides=two-sided-long-edge Duplex=DuplexNoTumble
Dest zinc/envelope sides=one-sided Duplex=None InputSlot=Upper MediaType=Env
Dest zinc/fancy sides=two-sided-long-edge Duplex=DuplexNoTumble InputSlot=Lower MediaType=Bond
Default zinc/plain
Dest zinc/sfancy sides=one-sided Duplex=None InputSlot=Lower MediaType=Bond
Dest zinc/splain sides=one-sided Duplex=None
Dest zinc/cards sides=one-sided Duplex=None InputSlot=Upper MediaType=Card
Special Advanced%20Faxing%20Tool%20(ksendfax)
Special Mail%20PDF%20File
Special Print%20to%20File%20(PDF)
Special Print%20to%20File%20(PostScript)
Special Send%20to%20Fax

That defines several printer "instances," which are separate sub-queues representing different options for the main printer, "zinc." It is clearly stated that "zinc/plain," which represents the basic standard print settings I want as the default, should be the default. But note that "zinc/cards" entry... it specifies card stock, one-sided, and the multi-purpose tray, which are the settings GTK+ is actually using as default.

So, is it as simple as "GTK+ uses the last instance defined for a printer, ignoring which one is flagged as default"? Not quite; because I tried deleting the instance zinc/cards, and then Firefox's defaults magically changed to the "Bond" media type - which at that point was specified in the second-to-last instance, not the last instance.

On further experiments, I think what is going on is as follows: GTK+ ignores the default, but it also doesn't understand printer instances at all. It just reads all the lines for a given printer, in order from top to bottom, and each setting of an option overrides all previous settings of that option. So the media type it uses will be the last one mentioned by any instance, and the same goes for duplex printing, paper tray, and probably (though I didn't test this) paper size as well. Since people will generally specify their usual settings first, followed by overrides for special situations, this approach guarantees that users will get their desired settings as rarely as possible.

It is quite possible the GTK+ may be achieving this effect by misusing some kind of CUPS API rather than directly reading the file itself, but the consequences are the same.

WORKAROUND: Create a new instance, which must be the last one in the file, having the desired default settings for GTK+ applications. I called mine "zinc/justforgtk." Note it must specify explicit values for all the settings that any of the previous instances have touched, because GTK+ will smear down settings from earlier instances if they aren't specified on the last instance. My /etc/cups/lpoptions file now looks like this:

Dest zinc sides=two-sided-long-edge Duplex=DuplexNoTumble
Dest zinc/plain sides=two-sided-long-edge Duplex=DuplexNoTumble
Dest zinc/envelope sides=one-sided Duplex=None InputSlot=Upper MediaType=Env
Dest zinc/fancy sides=two-sided-long-edge Duplex=DuplexNoTumble InputSlot=Lower MediaType=Bond
Default zinc/plain
Dest zinc/sfancy sides=one-sided Duplex=None InputSlot=Lower MediaType=Bond
Dest zinc/splain sides=one-sided Duplex=None
Dest zinc/cards sides=one-sided Duplex=None InputSlot=Upper MediaType=Card
Dest zinc/justforgtk sides=two-sided-long-edge Duplex=DuplexNoTumble MediaType=PRINTER InputSlot=Middle
Special Advanced%20Faxing%20Tool%20(ksendfax)
Special Mail%20PDF%20File
Special Print%20to%20File%20(PDF)
Special Print%20to%20File%20(PostScript)
Special Send%20to%20Fax

4 comments

trythil
If you're interested, the GTK+ code that pulls printer defaults out of /etc/cups/lpoptions (and user-specific files of the same nature) is in modules/printbackends/cups/gtkprintbackendcups.c:2447-2482: http://git.gnome.org/browse/gtk+/tree/modules/printbackends/cups/gtkprintbackendcups.c#n2447

In the file, there are separate mechanisms for getting printer information from a CUPS server _and_ pulling information out of /etc/cups/lpoptions, ~/.cups/lpoptions, and ~/.lpoptions. The latter (GTK+ calls this "local") is always invoked on GTK's printer backend initialization, and then the code that gets the information from the CUPS server is spun up in a separate thread.

I'm really not sure why the GTK+ developers felt the need to have two mechanisms for this. There's a presentation about the new ("new" of 2006) GTK+ printing API at http://people.gnome.org/~alexl/presentations/guadec2006-printing.pdf, but it doesn't mention the filesystem bits at all.

The parsing code I linked above seems to confirm your suspicions, though I'm not yet quite sure how GTK+ goes from printer name to GtkPrinter instance. trythil - 2011-08-22 18:35
Matt
Note line 2536 - it seems to be *deliberately* stripping the instance name from each line, which would lead to the effects I described as it reads all option settings for any instance to the one instance-less printer name it recognizes. I wonder why they thought that was a good idea? It's written as if the programmer knew that instances exist, but thought there would never be more than one of them. Matt - 2011-08-22 18:59
Matt
Filed bug 657706 ( https://bugzilla.gnome.org/show_bug.cgi?id=657706 ). Subsequently discovered bug 582747 ( https://bugzilla.gnome.org/show_bug.cgi?id=582747 ) which seems to be the same issue, and has remained "unconfirmed," despite containing detailed and easy instructions for confirming it, since May 2009. This doesn't make me hopeful that they will fix it properly any time soon. The submitter of that bug says this is what he loves about open-source software (being able to come up with barely-usable workarounds for himself), but it's actually what I hate about open-source software: nobody is responsible for fixing it properly. And they'll probably push a new version without fixing it and then close all the bugs filed on the current version as "outdated, try again and file a new bug if it's still a problem." Matt - 2011-08-30 10:06
trythil
Suggested, if pedantic, correction: this sort of lax treatment of errors is a problem with software that has no stakeholders. I've noticed that a lot of the open-source software being used by people to make money tend to get errors fixed pretty quickly. There are of course exceptions -- I have not had a good experience reporting bugs to Adobe in their Flex framework -- but that seems to be the trend to me.

(Occasionally you may also find a project whose maintainer really cares about Getting It Right for the sake of Getting It Right, but there aren't many of those...)

This implies that I think that GTK+'s printer module has no stakeholders, and that's correct: I do think that. I mean, if GTK+ is broken with regards to printing, who _really_ loses? trythil - 2011-09-04 04:03


(optional field)
(optional field)
Answer "bonobo" here to fight spam. ここに「bonobo」を答えてください。SPAMを退治しましょう!
I reserve the right to delete or edit comments in any way and for any reason.