Capture Printed data....

[shervieux]

Hi all,

I am not sure this is the right section for this, but since most of the systems we interface with are Windows-based... I am looking for a utility that will capture data that is printed to a printer. The data needs to be stored in a file, then also sent to the printer at the same time.

Usage: I work in a healthcare environment, and we ware looking for a way to capture encounter forms that are printed at the front desk, store the data in a file so that it can be uploaded to laboratory and billing systems, and have the encounter form print on the printer that was chosen by the front desk receptionist. This solution must be tranparent to the end user (i.e. all the front desk receptionist would see is the printer dialouge for chosing the printer and the report appearing on her printer - he/she would not know or have to interact in order to have the data saved to a file as well).

While I am looking for an off the shelf product, I am not opposed to developing something internally if someone wants to share code. I need the ability to capture from the printer driver - rather than trying to retrofit into multiple applications - as we have many off the shelf products we print from. Basically - what ever is sent to the printer - I need to capture in a file and also have go to a printer.

I have looked at alphatronics.com and they have a viable solution - but my boss wants to investigate other products and see about doing something internal as well. Any help would be greatly appreciated. if anyone has written something and would like to share code, that is great. I also work in a multitude of programming languages. My issue is the application we print from is locked down and cannot be touched - thus why I need to capture what is going to the printer.

 

[EricB]

windows has a print to file option

that said you should print to adobe pdf (Adobe Acrobat required) or MS office document image first, then print the form

 

[bla!!]

I have no idea in code how one would do this, but doesn't everything (if set up as defaults) print through a print spooler?

Could you make a program that reads from the spooler (generally implemented as a fifo of some sorts) along with the printer?

 

[shervieux]

capturing print data

Eric & DosWizard,

Thanks for your replies. What we used in the past was Adobe Acrobat (if we could) to print to PDF. Unfortunately, we run into instances where our clients do not let us install software on their PC's. We also try not to touch client's PC's for liability reasons (you be surprised how many people point fingers if something breaks - even if it is not related to what you did). In some instances we have attached external devices (A10 converter) to the printer. This works fine for serial and paralell printers. the issue is network printers. We can't capture from that. The issue is we need to trap either what is coming off the printer port from the PC, or into the printer from an ethernet TCP/IP connection. While I was willing to try to write something, the issue is we really do not want to put anything on a client's PC - where they would have to call us for support -if nothing prints on the printer at all. The other issue is some of the clients we deal with do not run the Office management software on the local PC, rather through a terminal emulator. the actual software is either on a windows, unix, linux, openvms, or some other type of mainframe/server and operating system. We also had some clients who are running Apple products and hardware. Since those are far and few in between (for the time being) - we have said we will only support Windows 2000 and up. We still have yet to find anything for Unix / Linux. Unix / Linux I could write something - but the problem is only 3 of us work with Unix and Linux and neither of us are really that fluent enough to support 700 clients in N.C., S.C., Georgia, Tennesee, Virginia, and where ever we expand to next. Also, it would be too expensive to contact each of the vendors of the OMS software to write something. Some places we put in an interface, but at a cost of $1000 to $6000 each - gets rather expensive - that is why we are looking to go this route (trappnig the printer traffic). Plus we have more flexibility on getting the data in a format to be read in by our servers. generally we make them use a generic text driver - so we don't have to deal with all the printer encoding.

Also having the client print twice (one to the printer and once to the file) is way out of the question - we cannot impact our client's workflow. Besides our field techs are under Sales not I/T, so they do not have the best technical skills to support anything elaborate (i.e. not plug and play). Used to be easier when the field techs were under the I/T dept - so we could train them and work with them on issues they are facing. Now we are faced with "just get it done, and I want it yesterday."

Thanks guys, I'll keep looking around.