Can you print to a printer driver without having the hardware and see the output?

Question

Here is our situation. Our software has an option to print cards (credit card sized ID cards). We have various options to set transparencies of images, different fonts, colors, and just a bunch of stuff to make the cards look pretty. The problem seems to be that not every card printer really functions the same with the same set of parameters. For example, some edge to edge printing really doesn't seem to be edge to edge, while on other printers it seems to go over the edge.

What I think we need is a way to install various card printer drivers, print to them, and have the output go to an image or pdf or something that we can view on screen to see what it looks like when the driver prints to the printer.

However, I am not sure if that would really work or not. I am not a hardware person, so I don't know how the drivers really interact with the printer hardware.

We ordered yet another card printer (different manufacturer) to test on yet another printer... The problem is, we could be spending a whole lot of money every time a customer comes to us and says, "ummm, our Joe's Hardware Card Printer isn't working quite right."

Any advice on how to deal with this is appreciated.

Answer 1

There is a thing called Print to File. This feature is supported by almost all applications. This puts the PDL on your disk instead of sending it to the spooler (which would in turn pass it to the device in the normal case).

Now, if you have a PS driver, you could get the PS out on your disk which you can distill (using a paid software/Ghostscript) and see the output. Or, if you have a PDF printer you can get a pdf, and also, the different planes if you are interested.

Also, many printers generate tiff files (instead of generating PS or PCL or PDF). So, check with your vendor.

Your problem seems mostly like a tiff comparison problem. IMO, it'll be best to have a set of raster (tiff) to use as a benchmark, a raster comparison tool, and then you can fire anytime using any printer and run a diff.

Make sure that if the diff turns up to be huge to check the two files yourself. You might be even surprised that the difference is intangible.

However, printing to devices is also important. What you see on your monitor and what gets printed on a device varies a lot. Which is why they have things like color profiles. And calibration. So, take a look at those aspects as well. But I'm blabbering unimportant stuff, so ...

Answer 2

I would say this is a primary reason why many specialty software vendors require certain models of hardware whether it's bar code scanners or special printers. I've seen many instances where only certain models are supported and the client purchasing the software is required to use the recommended hardware, any other model is not supported by the software vendor.

One of the requirements of an accounting software I work with is that it requires a PCL5 complient printer. Most bargin bin printers do not have this support and I have told many clients that their $75 laser printer will not work with the software and that the need to buy a printer that is a little more expensive.

Due to the special nature of the of the printers I don't see why the manufacturers would not provide some kind of development machine given a deal to recommend their printers to your client base.

Answer 3

If you like, add a comment to this post and I'll update with a link to an app we developed a while back to capture data via LPR or 9100/RAW. This helps in instances where the queue you create doesn't work well with 'print to file' or it's an app on an OS where you have little control in capturing the output. Then, you could view the data yourself, or if it's PS you can use gsview or something like PCLWorks if it's PCL. That being said, if it's a specialty device it may have it's own language (ZPL on Zebra for instance) and you may have to simply diff the files and trial and error to see what's what.

Another option is to create a Windows queue (again, if print to file doesn't work), pause it, send your data through this queue and go and get the .spl file from c:\windows\system32\spool\printers. Just make sure your Windows printer's file processor isn't set to EMF (should be RAW)