[cups.development] Re: GUI to specify device dependant features

Kurt Pfeifle kpfeifle at danka.de
Thu Jun 17 06:08:29 PDT 2004


Helge Blischke wrote:

> Theodoor Bongers wrote:
> 
>>Hi there,
>>
>>I'm developing a CUPS-driver for a postscript printer. It has 
>>it's own PPD file, so most device dependent features are accessible 
>>through frontends like kprinter (or at least through the CUPS 
>>web-interface). There are some more options I would like my driver 
>>to support, but it's not possible to describe them in the PPD file. 
>>What I actually want, is to show the user a GUI to offer the full 
>>range of features. I understand that it's not CUPS' responsibility.
>>
>>Can anyone please tell me what's the easiest way to do what I 
>>need to do? I suppose it's bad to show a GUI from within a CUPS 
>>filter? The KDEPrint framework under linux provides a nice way to 
>>do some pre-filtering with a user interface, but that would only 
>>solve the problem for KDE applications.

That's not at all true, actually! See

    http://printing.kde.org/faq/kdeprint.php#IsKDEPrintforKDEusageonly

for more detailled info.

You can use the "kprinter" as a print command from any GUI or
desktop environment (most do support to edit their builtin
print commands), even XFCE or GNOME....

More, you can use kprinter as a print command *on the
commandline*. Type for example

   kprinter --help

in a konsole window to learn more about it.

Regarding the pre-filters in KDEPrint: you can include *any*
filter in the world there. Just get your MIME types (defining
their input and output) right. KDEPrint comes with some pre-
configured: enscript, pamphlet, image-to-ps, poster, n-up,
page-selection (odd/even) and more. It is easy to integrate
a2ps or any of your self-written filters.

You can configure your KDEPrint prefilters for each GUI,
save the settings and then use

   kprinter --nodialog -o[any options] -d printqueuename /path/to/printfile

to make kprinter use first its pre-filters and then pass
the output of the pre-filters to CUPS for further processing.


>>Isn't there a better way 
>>to achieve this? Would it be an idea to replace the lp and lpr 
>>binaries, 

You can always do that by renaming the lp/lpr binaries and
setting a symlink to kprinter. (Actually this is a trick to
force some legacy applications which dont provide a custizable
print command, but have hard-wired "lpr" as their print command
inside....)

>>show the GUI when lp or lpr is called, set the options 
>>in ~/.lpoptions and pass the call to the original
>>
> 
> 
> Well, somehow your printer must be told the selected device dependent
> features, either via PostScript
> code or via PJL commands. What sort of options do you think cannot be
> described in the PPD?
> 
> Helge







More information about the cups mailing list