PDQ print system

Experiencing problems with CUPS again, I remember wistfully the days when Puppy had the PDQ print system. I posted a comment to the previous post, but thought this deserves it's own post.

PDQ homepage:

Early versions of Puppy had PDQ, which is very nice, really tiny. It fell by the wayside for various reasons:

No longer being developed.
GTK 1.2 GUI application only.
Some apps expect CUPS to be there.
Very basic printer configuration.

We could save an incredible amount of space with PDQ, plus it is very simple, and "just works". But, it would need someone who is able to commit to developing it. It is written in C. For a start, the GUI application would have to be rewritten for GTK2.

Mandrake Linux used to use PDQ as the default printing system. Um, I can't recall what version was the last to do that... 8.x comes to mind. The thing is, those guys had developed PDQ to a high art, did very nice things with it. But, like all the other distros they dropped it and went for CUPS

So, if anyone wanted to take on PDQ as a project, getting an old Mandrake distro would be useful.
I don't recall the last version of Puppy that used PDQ -- it would be in my online blog archive.

I had developed a setup GUI that asked various questions about your printer, like how many color nozzles in an inkjet cartridge, so it didn't need a big database of printer types, but that would probably need to be developed further -- which is where the Mandrake stuff would be useful.

I wouldn't mind messing around with it again. Anyone interested in helping out with porting it to GTK2?

Posted on 19 Nov 2009, 18:48


Posted on 19 Nov 2009, 18:47 by BarryK
Old puppies with PDQ
I have just checked the history. Puppy 2.16 and 2.16.1 have PDQ. 2.17 has CUPS only, but then 2.17.1 has both CUPS and PDQ -- interesting, gave people a choice. I think 2.17.1 was the last that had PDQ.
I recall, jcoder24 developed print-to-PDF for PDQ, which is in those releases.

Posted on 19 Nov 2009, 21:23 by capoverde
Back to PDQ hopefully?
Hi Barry,

when you annouced that CUPS would become the printing manager for Puppy, I groaned loud; and with good reasons, sadly... In other words, PDQ's comeback is good news here!

A dreamer's view: the PDQ source should be translated into Vala/Genie, and then it would probably be easier to find some good-hearted coders to maintain and update it.
Sure it's just a dream, since although the Vala compiler also yields a corresponding C code, that doesn't work the other way 'round... Doh! :((

Posted on 20 Nov 2009, 4:39 by 8-bit
PDQ compatability
One of the problems with the linux printing system using either PDQ or CUPS is the inability to use drivers that came with purchased printers.
The software driver designers for a long time designed their drivers for windows and that was that.
It is only recently that some of the printer manufacturers have offered linux drivers for their printers.
I would like to actually see a wrapper designed for CUPS or PDQ that would let the user use the drivers supplied with his printer.
In other words, the wrapper would use the windows printer drivers.
The big problem is bloat. The windows printer drivers want to use a bunch of DLLs and support that is in Windows but not in linux.

Posted on 20 Nov 2009, 7:25 by ttuuxxx
Firefox was having issues with printing in 2.14x, I found a solution online and it worked :)
Basically it was a way to removed cups from firefox, what you do is delete /usr/bin/lpr and make a script with the same name that launches /usr/bin/gtklp that works like a treat :).
Here's a link to the original thread

Posted on 20 Nov 2009, 11:12 by cli_user
running win lp drivers
well, there's ddiwrapper from SUSE 10.3. It looks like google summer of code 2009 and openprinting haven't tackled it either.

The pdq code itself looks really good. I'd be happy with a cli tool (duh!).

I'd also suggest a tool to automatically convert printer defns from cups.

Posted on 20 Nov 2009, 11:26 by cli_user
running win lp drivers #2
Most of the files listed for ddiwrapper are the same as those for ndiswrapper, which we're already using. The filesize hit might be tolerable.