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.