[ale] Printing plant (was Re: printing fun)

Jeff Hubbs jhubbslist at att.net
Fri Dec 15 10:50:40 EST 2017


I learned about "institutional" PC printing in a Banyan VINES 
environment; back then, printers were only ever hooked up to machines 
and a shared printer had to be connected to a PC that was up and running 
and had logged into the VINES system once since booting. Next time I 
revisited this it was in my Windows NT days and Microsoft's own (I 
confess, excellent) books described queue arrangements in which PCs not 
only didn't print directly to print devices, they suggested making it 
where they *couldn't* by putting network printers on their own network 
subnet.

Since then, I don't think I've ever worked anyplace where networked 
printers were set up that way; rather, folks' PCs are expected to 
connect to any printer directly and they just let print jobs collide at 
the printer whenever and wherever. Now, at A Former Employer (tm) there 
was a captive web app arrangement where a dozen or so Linux Tomcat 
servers submitted print jobs to CUPS servers that held a couple thousand 
queues and in my last weeks there I did a lot of work to simplify and 
improve the reliability and manageability of that whole arrangement; I 
never got to put it into production but because the printing plant was 
mission-critical I had designed a STONITH cluster arrangement to handle 
the CUPS load. I also did away with all the different print drivers and 
the fussiness associated with keeping track of which driver was selected 
for each printer by going PostScript for all of the laser printers, but 
I determined that there was one model of HP printer we used /whose 
PostScript implementation was defective/! I wound up scripting an 
automatic net-walk and firmware detect/replace operation that acted on 
hundreds of these printers. Ultimately the new printing plant wasn't put
in production because an initiative to replace the last of the remaining 
defective leased printers that couldn't be updated remotely never 
happened even though I'd been told it had. But even there, general 
desktop/laptop printing was ad hoc just like I'd seen most everywhere else.

Another takeaway from that work and other situations I've encountered is 
that any application that generates some kind of structured paper form 
out of printers should render its original document in 
hand-written-but-software-filled PostScript. I have seen a lot of 
heartburn come from trying to generate forms in some proprietary package 
or using Word/Excel macros and it never seemed to me that in the longer 
run it was worth the up-front effort supposedly saved. Once you've 
worked out how to render a doc in PostScript once, it's usually pretty 
simple to modify even for people who've never seen bare PostScript 
before and doing that cuts out at least one layer of stuff out of your 
dependency stack.

Have any of you ever worked anyplace where network printing was all 
properly queue-backed and shut away from regular net traffic?

On 12/15/17 9:38 AM, Solomon Peachy via Ale wrote:
> On Thu, Dec 14, 2017 at 05:52:19PM -0500, Kyle Brieden via Ale wrote:
>> I've found, lately, that network printers aren't worth the trouble to "set
>> up" on my machine.  Just navigate a web browser to port 80 on the printer's
>> IP and load up the web UI.  With most modern printers, there'll be a "submit
>> document to print" button or form.  Upload your PDF there and the printer
>> will make it into a real boy... er, document pretty promptly.
> If you're using a modern-ish printer, especially one that uses
> postscript (like I'm sure the LaserJet does) then it's already fully
> IPP-enabled with zeroconf.
>
> So a modern Linux distro will auto-discover the printer and set up the
> necessary "driver" (really just a matter of fetching the PPD from the
> printer) without any user interaction whatsoever.
>
>   - Solomon
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20171215/72ae2fcc/attachment.html>


More information about the Ale mailing list