An interesting requirement came from the project I’m working on right now: Print a PDF file programmatically, from a windows service.
In a first shot, it seems to be simple and obvious, but it’s not. From .Net you can’t print a PDF file directly.
Therefore, some solutions came up:
1. Use Windows SDK to extract the PostScript from the PDF document and then use .Net to send the postscript file to the printer.
Pros: Free and straight forward solution. If you have a postscript printer, it’s a great solution
Cons: Using Windows SDK will be using unmanaged code; If printer postscript feature is disabled (or printer doesn’t have postscript), this solution will fail
2. Use Adobe Reader to print the document using the command line (shell).
Pros: Free solution. Since we will be using an Adobe solution, the print out should be exactly expected solution.
Cons: There are some “crash” issues reported by users using this solution; Since this is a command line call, we have no control over the result, since no return value is reported by the print application (Adobe Reader); Also, in the Adobe Reader Licensing Agreement, it says “…Server Use. This agreement does not permit you to install or use the software on a computer file server…”. Is it legal to use in a server then?!?!
3. Use a third party component for PDF printing. I’ve found a great component built by the company PDFTron, called “PDFNet SDK”. It has all required features (merge, print, etc), and more.
Pros: Print the PDFs properly and provides a rich SDK api to control the print process; Provides also a rich set of features to manipulate PDF components (merge, acroforms, create, security, etc); The price is very reasonable, not requiring any license for the development boxes. Also, this component is a reliable solution. The component is very stable and no surprises were found; The support guys are quick (helped me a lot).
Cons: Some budget is required for this solution. The cost is about $900 per Server processor; The paper identification must be done manually (programmatically), since the component doesn’t capture this automatically; The API is a C++ look like (the documentation is based in C++), making the learning curve not so intuitive as it could if based in C#;
Based on the pros/cons from all three options, my vote was to go forward with the third solution (PDFTron component). Even having to pay some money to have the solution in place, since this is an enterprise solution, we shouldn’t “risk” our business because of couple thousand dollars. Hopefully we will have the component in place soon.
See you guys!