printer redirect based on job name / doc name

[caver456]

For example, 104's should go to one printer (loaded with non-carbon transfer paper); all other jobs should go to the other printer (loaded with plain white paper).

Redmon seems to be a good lead. Basically you add a new printer port which redirects the print job to the stdin of whatever program you want. Good progress so far: redirecting to a python script that just prints each line of stdin to a log file, it is apparent that the log file lists whether it is a 104 or not. Now need to get the python script to actually send the entire job to a real printer selected with the logic as above.

[caver456]

Note also, this whole issue is one proposed solution for the larger topic of optimizing the carbonless-transfer workflow. Other ideas should not be ruled out.

[robsheldon]

As an intermediate solution, I'm pretty sure we can just create multiple printer connections to the same printer but with different print settings.

[caver456]

do you know if we can create a printer with settings to do what we want (duplex, and print on 'reverse' only, if that's what you're thinking of)? Big picture, this solution would still require babysitting each print job to send to the correct printer, just like the flip-and-cut-without-redirect method which is the best option right now anyway. Not sure this would give too much benefit vs just making sure to flip and cut when loading.

My understanding of the long term options:

1. flip and cut without redirect
2. flip and cut with redirect
3. no flip and cut, with a new printer object that does duplex-and-reverse-only

1 can be used right now; requires print-job babysitting; requires flip-and-cut 2 is not yet proven, in progress (redmon), and would NOT require print-job babysitting; would require flip-and-cut 3 is not yet proven, would require print-job babysitting; would NOT require flip-and-cut

Weighing those out, it's not clear how much benefit 3 would be vs 1; I'll keep working on 2 which would hopefully make the rest a moot point. 1 would always be the fallback.

On Tue, Jul 4, 2017 at 7:55 PM, Rob Sheldon notifications@github.com wrote:

As an intermediate solution, I'm pretty sure we can just create multiple printer connections to the same printer but with different print settings.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ncssar/tech_worklist/issues/1#issuecomment-312984670, or mute the thread https://github.com/notifications/unsubscribe-auth/AR4iZtY97O2xHwqrt1ZFISAx2YJ57Ms5ks5sKvs4gaJpZM4ONt1y .

[caver456]

see these two stackoverflow questions: https://stackoverflow.com/questions/44950317 https://stackoverflow.com/questions/44360133

no responses on either one so far...

It can't be too difficult to just route a whole incoming print job to a specified printer using python; the next step is probably just a bit of RTFM.

[caver456]

This might actually be working. Need to install and test it in the trailer since test results are unclear with 'fake' printers here at home. Will plan to test it this Sunday.

[caver456]

Tested it in the trailer, it actually works. Since this would be a very invasive change (even though the fall-back option is golden since we don't have to get rid of any existing printers / print queues) we should set a pretty high bar for robustness and QA. So, several items on the checklist before roll-out. First pass at the checklist:

• is performance / delay acceptable vs sending to a real printer directly?
• try to break it: one printer off, both printers off, server off, python not in the path, redirect script not found, etc
• build up some history: use it on a mock search or a small search
• look into more features: automatically print 2 copies, regardless of input job setting, for 104s?

[caver456]

Also:

• documentation: install docs, and usage docs (target audience = everyone in IC, while they are in a hurry) - I took some notes to build docs from today

[caver456]

idea - can the intercepted print job be modified to fill searcher names into the 104 fields using the latest data available at print time? If so it could integrate nicely with a computerized t-card system.

[caver456]

Done. See NCSSAR tech bulletin: https://docs.google.com/document/d/1vAuPkp1SD30oW51QWaRSy1Rpzun6onl4St64A6UlrKg/edit?usp=sharing

(Since this issue was about redirecting, the issue is now closed. Investigating print job modification like for searched names, and investigating forcing of copy count to 2 for 104s, would have to be created as separate issues.)