Hi, Alan. On Sun, Jun 08, 2014 at 11:47:32PM +0200, Alan McKinnon wrote: > For Alan Mackenzie's benefit, a little back story:
> The whole topic of printing is a mess, no single mere mortal can wrap > their wits around it. > Long long ago a printer was a piece of hardware you plugged into a > serial or parallel port, the kernel found it and you were good to go. > Whoopee! > Because more than one user could use the printer and this causes > conflicts, print servers were written: the server controlled the printer > hardware and you submitted your print job to the server, and that took > care of all the messy parts. To do it over the network was just as easy, > modify the print server to also listen on a network port. > This server was the classic "lp" suite of tools. > Many years ago, HP developed a fancy printing language for their laser > printers called PostScript[1]. Wasn't it Adobe? > Think of it as a giant image format, it doesn't describe what the > printed page looks like, it really is simple code that tells the > printer how to print the page, including graphics and such. And so the > era of complicated drivers was begun. > These laser printers needed gobs of memory and big cpus to deal with > PostScript, in the 386 era it was common to have a printer much more > powerful than your computer. > Enter other vendors and Windows. Just like with sound cards, vendors > wrote their own drivers adding "features" done in software. This makes > sense if you can't get PostScript to do double-sided printing or scale > down so two pages fit on one page, doesn't make so much sense if you > just want to avoid paying HP a PostScript license. > After a while, HP got around to updating PostScript (or maybe it was > Apple's code all long - I forget...) and called it PCL (Printer Control > Language), needing new drivers. > meanwhile, printers shifted over to USB away from parallel ports and > this needed new drivers. Plus there's two way to do it: do the USB part > of the printing in userspace and only use the kernel for regular USB > work, or put the whole thing in the kernel. Needing more drivers. last I > looked, there were still some serious issues with the options to have it > all in the kernel. This is the CONFIG_USB_PRINTER, which if I remember correctly, must be either on or off depending on other things you might have configured. I have been confused about this in the past. Incidentally, my printer has a parallel port which was still in use until I got my new box in 2009. > On the print server side, the devs were getting real busy. We had > classic lp, then came lprng, then something else I forget and finally an > upstart crowd wrote CUPS (Common Unix Printing System), eventually > bought by Apple. Ironically, there's now nothing common about it and > it's for iOS not Unix. Such is life. With the latest major version > update Apple ripped out all the bits we find so useful and still declare > the software is "for Unix". I wasn't aware of that. This is a variant of MS's "Embrace, extend" and shows the dangers inherent in allowing commercial firms like Apple (or Redhat?) to take control of infrastructure bits of the system. I used lprng until ~2 years ago, when libreoffice stopped supporting classical print spoolers. lprng just worked, unlike all the kerfuffle with cups. > Firms like Canon had developed big expensive network-enabled stand-alone > printers. You'd think this is as easy as fitting an embedded OS with a > print server to replace a dedicated PC with USB/parallel ports... I've > had to deal with junk that despite being branded PostScript would only > work with it's own Windows drivers. 50 Linux users of all sorts and > different distros could not get this bitch to work. Presumably, there'll be a PostScript validation suite which probably costs much more than the printer you wanted to validate. > Enter the age of network printing protocols. We have IPP running on port > 631, something else that is supposedly HTML with huge amounts of extra > printer-specific stuff, JetDirect, and many more things I've long ago > forgotten about. Plus Samba to share a printer the way Windows does it. Yes. Lots of complication, with no benefit for users like me. :-( > Did I mention PPDs? Printer <something> Definition files that describe > how to drive a printer using a standard dscription file. Awesome. Where > do you get these things? Oh I dunno there's foomatic, cups built-ins, > gutenprint, magicfilter and some magic thing from HP called hplip that I > once found worked for an Epson inkjet! > Andreas did a fine job above of describing a map to get around this > driver stuff, including all the many wonderful ways these driver ebuilds > have to block each other to get installed at all. Indeed. > And I haven't even touched on CUPS' "feature" that requires you to > delete and re-add back all your printers after any remerge. Ask Dale > about this, he's the resident expert and he's even figured out how to > get hplip to work. I don't seem to need hplip at the moment. My emerge of cups last night (to 1.7.1) didn't need me to reinstall my printer. > Are you still here, still listening? Ye gods, this mail is 5x longer > than I thought it would be. I personally have given up on printing > period. I either randomly hit useful looking buttons in KDE's config > widget hoping it will work, or at work I print to PDF, put it on a USB > dongle and wander over to my wife's desk saying please print this on > your windows machine. I don't blame you. Why must things be this complicated? > I'm not surprised you felt pain dealing with CUPS, I feel your pain - I > really honestly do. But sadly, I can't help you fix it, see previous > para :-) My main problem was with emerge. The fact that various printing packages were blocking eachother was only apparent in the 147k line debug output, not in the normal messages printed to stdout/stderr. > [1] PostScript is still alive and well today in the form of PDF, and > that's how PDF started out - in it basic form it is essentially > compressed PostScript with hyperlinks! Have a good day! > -- > Alan McKinnon > alan.mckin...@gmail.com -- Alan Mackenzie (Nuremberg, Germany).
