[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