[Gllug] Persuading Etch to use the right (configured) paper size

[Nix]

On Sun, 06 Aug 2006, John Winters moaned:
> The problem isn't CUPS - CUPS has the printers configured correctly
> and clients running on Sarge get the paper size right.
> 
> The problem is that Gnome-based clients running on Etch workstations
> seem to ignore the CUPS-configured paper size, and the paper size set
> in /etc/papersize, and use Letter instead.  It's irritating.

Ah, yes, I forgot that GNOME hasn't entered the 21st century and started
using the CUPS libraries yet (sigh).

The GNOME printing infrastructure is somewhat opaque to me; there's
printing code in recent Gtk releases, and there's libgnomeprint,
and there's libgnomeprintui, *and* there seems to be a surprisng amount
of independent (cut-and-pasted?) code in many apps to print as well.

libgnomeprint definitely has a transport module for CUPS, which does
something or other to dig around with paper sizes, but I'm not sure
how one such module gets picked over another...

... hm, there's a config abstraction layer in
libgnomeprint/gnome-print-config.c, which is used to dig up the value of
the key Settings.Transport.Backend.Module...

... which digs things out of a GnomePrintConfig GObject...

... by means of *another* gnome-print-specific abstraction layer,
`gpa'...

... which digs things out of, aha, globals.xml in the
gnome_print_data_dir, /usr/share/libgnomeprint/${version}/, what a place
for a config file. The default printer and transport module are *not
set* in there, but I'd guess that by modifying the PhysicalSize in the
models/GNOME-GENERIC-PS.xml file in that directory, you might have some
effect (although I can't see any reason why the code would decide to use
that XML file, there aren't any others *there*). There's a moribund
gnome-print-admin tool whose job is I think to edit this stuff, but it's
been untouched in CVS for four years, and didn't compile last I tried.

Gah.

(I never thought I'd say this, but why the *hell* doesn't it use gconf?)

-- 
`We're sysadmins. We deal with the inconceivable so often I can clearly 
 see the need to define levels of inconceivability.' --- Rik Steenwinkel
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug