On Wed, Jan 30, 2008 at 11:02:00PM -0500, Ken Hornstein wrote: > So, let me see if I can summarize. The two camps are: > > - Vanilla lpd, based on simplicity > - CUPS, because of features/PPD support/networking browsing/... CUPS, based on simplicity (for my poor printer-allergic brain :) > I admit that I was hesitant to use CUPS, because it seemed to be > only a client thing (that's what cups.org focuses on), and, well, > the web page implies that you need to run a frickin' web server to > configure it. No, it has its own webserver: IPP and HTTP status/user interface, all on port 631. As of CUPS 1.3, it finally supports kerberos auth for this interface (for either printing or admin), too, which can be handy if you're going to expose the listener non-locally. I wished for that dearly a year or two ago, but haven't yet been back to look at it since it appeared in pkgsrc a few weeks(?) ago. Of course, you can configure it from the command line too, using roughly svr4-style lpadmin etc commands (which then just post to 631), or by editing some simple text files, but that requires some thinking. Much easier to follow the html bouncing ball with dropdowns for model and options. If you have some kind of GNOME or KDE infestation, there are evidently gui tools in there, too, but I don't have or want that. > My network printer (an HP 2605DN) works _okay_ with my LPRng server > ... but it has vague problems with it, and getting things like plain > text printing to work seems to require some additional bits that I > haven't yet figured out. But sadly this printer seems to be > slightly buggy enough that it has a number of annoyances with LPRng, > and I think that to make it work better I will need the extra smarts > that CUPS provides. I appreciate all of the input! That's precisely the part I want to think about least, and that CUPS just does automagically: all the crap that transforms one format to another, so I don't wind up with a 700-page printout of machine- generated postscript source, or whatever. I suspect that people's concerns about complexity or bloat stem mostly from the infrastructure it uses to do this. Resources well spent, I say, especially if the alternative involves collecting most of that stuff anyway plus figuring out how to plumb it together for myself. Strictly speaking, you only really need that stuff on an actual print spooler/server. Because the command-line programs (lp/lpr/lpstat/...) are just frontends to the IPP service, it's often enough to just point them at cupsd on another box. No need to set up queues locally forwarding to those, or run 'heavy' servers that autodiscover eachother's queues. A smaller cups-client pkg, or compatible ipp support in native lpr, to point at a full cups running elsewhere, might be a nice way to address some of those concerns if someone wants yet more work to do. > It seems that I've learned rather late that HP, a once-good printer > company, now has products that are clearly second-rate. What a > bummer. The issue for me is that I mostly need to use other people's printers, with no influence on their prior choice, and often with little more information about its innards than the model name on the front panel. Oh, and usually with no time to figure out these details on the fly. Some nicer printers server their own PPD file from the IPP interface, which makes the whole thing a real no-brainer at last. -- Dan.
Attachment:
pgpoiQj74o5eG.pgp
Description: PGP signature