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

[Helge Blischke]

Kurt Pfeifle wrote:
> 
> 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

Hi, Kurt,

nothing against kprinter - I even built fancy printing commands
providing things like
that (to a limited extend, though) before I even knew how to spell KDE.

My objection to the previous post was the statement that there may be
printer features
(_not_ features of the print job creating application!) for PostScript
printers
that cannot be described in a PPD.

Helge

-- 
H.Blischke at srz-berlin.de
H.Blischke at srz-berlin.com
H.Blischke at acm.org