[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