Re: printtool in Debian
[ I'm not on debian-devel; please cc me. ]
>>>>> Osamu Aoki <debian@aokiconsulting.com> writes:
> Your lpdomatic seems to be very capable. Is there nice GUI
> front-end to use your filter/data by setting /etc/printcap or
> something, so I do not need to specify printer type for each lpr
> invocation?
No, there's no cute GUI. For the analagous CUPS front-end, both XPP
and QtCUPS have been modified to parse the existing Perl-language
foomatic data and offer up buttons and sliders and what-not for all
the options.
It would be a straightforward project to adapt that logic into, say,
Glpr (part of VA's gnulpr project). But no one has done so. Come to
think of it, the PPD logic ripped from CUPS that exists in gnulpr
should be plugged into lpdomatic, too; that would give LPD users
something akin to equivalent functionality to CUPS users. Although I
do keep meaning to write that PPD decompiler...
Anywho, as you'll see on my roadmap, these existing application hacks
will shortly need to be redone to parse a more sensible XML format.
So any new work should probably be done with that in mind.
> By looking at your site, it looked to me that I had to specify from
> lpr's option.
Yes. Stock LPD is only recommended for people what know what LPD is
and want that. I point most people at CUPS or PDQ, both of which
offer pointy-clickey GUIs for configuration and job submission. Plus
a few actual features.
Of course, not a one of them is particularly secure. This is a sort
of looming problem. I tell people to use PDQ if they want security:
PDQ doesn't spool or any of that nonsense, so it's a bit less exposed
to the usual security flaws.
> LPRNGTOOL was originally written by Geoff Silver <geoff@uslinux.net>.
Ah! Patrick had just pointed me at turbolinux's RPM, and it had some
turbolinux guy all over the changelog. So I figured he wrote it.
> My comment came from the fact RH did not list all drivers in
> RH6.0? days while selling CD to me with Aladdin GS, I think.
> No offense to your work. Please understand.
None taken. Red Hat has always sucked from the standpoint of actually
including all available printer drivers. Their GUI was cute when it
came out, but even now the design precludes using whole swaths of
drivers in any useful way.
>> No, I think they're throwing printtool away - it's DEAD. Please do
> *** I disagree here. ***
Feel free ;)
Red Hat has declared it dead, and they'll be shipping a new
foomatic/magicfilter/lprng oriented replacement (I think written in
Perl/Gtk?) shortly. That GUI can be expected to instantly obsolete
printtool, at least from a functional and technical standpoint...
So I'm perfectly happy to have the world forget about printtool.
Oh, the Red Hat guy doing this work is Crutcher Dunnavant
<crutcher-at-redhat.com>; he's on linuxprinting.foomatic.devel.
I think you should join up with Till of Mandrake and the KUPS guy;
they've finally gotten the bug that it would be straightforward to
make a config tool that works for all spoolers. Till sort of started
the discussion in a thread entitled "Grand Unified" something in
linuxprinting.foomatic.devel.
I still think it'd be pretty nifty to do a debconf-based
spooler-independant print configuration thingy. But that's a project
for another day...
--
Grant Taylor - gtaylor@picante.com - http://www.picante.com/~gtaylor/
Linux Printing Website and HOWTO: http://www.linuxprinting.org/
Reply to: