Wow, did I read that right?

February 26, 2007 on 2:27 pm | In .NET Coding |

One of the most annoying, and most unnervingly frustrating things about dealing with web-applications in real life is dealing with printed documents. In my opinion printed documents are obsolete, but customers might disagree. You can’t rely at all on the browser to print using the File menu for you, because you can’t guarantee that everyone has the same settings. For me, this means that if I want to print real documents that are conforming to the standard, then I have to go PDF. Now, there are a ton of good PDF libraries out there to help you programmatically generate PDFs, just go search Sourceforge for them… There is a catch though, most of them are very adept at throwing out text and generated graphics, but if you are trying to replace an existing process which has a form already in existence, like something from the US Government, then you’re going to spend a LOT of time figuring out how to generate the document.

I have a solution which I used for this, but it cost me about 500 bucks. Not really a step-by-step HOWTO, but I’ll give you the long and short of how I handled it. I had to buy a copy of Adobe, which is OK. The Adobe Acrobat Pro software is worth the money (before you say anything, read the rest of this,) but the free Adobe Reader isn’t worth the time it takes to download it — get some other PDF reader because it won’t try to take over your web-browser, and eat all your CPU time like the adobe plugin does.
The trick is to leverage FDF - the Adobe forms components, to manipulate the annotations on the PDF document to ‘fill out’ data on the fly from your database. First, convert the document raw to PDF, you don’t need Adobe for that, most of the clone ‘PDF printer’ components you can download freely will do that, but for this next part you do need the real deal… You can design the form document in Acrobat, and place your form fields a la visio. Then, you can acquire some library (right now, they all cost about $200 - $500, Aspose PDFKit seems to be the standard, but pdftron’s PDF library is much more cost effective, and works well even under high load.) I created my own domain specific language to map from an XML configuration file the fields and properties of an object to the fields on the PDF form, but you can do it by hand, meaning hard code it, if you like. Either way, it’s still better than trying to machine the graphics out coordinate by coordinate in code alone, and even quite a bit simpler than XSL:FO (which to date is still a little sketchy in all of it’s current implementations: read Apache NFOP.)

Side note: If you have money to burn you can of course buy the Adobe FDF SDK, which will cost you just short of an arm, a leg, and a sizable portion of your reproductive organs, but there is a large set of available documentation if you go that route. Lets not lose site of what we’re actually trying to do here, we are filling out forms, not creating a clearing house for PDFs for their own sake, so the cheaper, more sparsely documented libraries will do the trick.

So there is a complete, cheap, and legal way to accomplish standardized printing from a web page. The neat thing, which actually prompts me to write here, is that a sourceforge project called PDFClown just popped up recently, and one of their goals is to support form filling. What this means is that eventually, you’ll just have to buy Adobe, or if we’re lucky, someone will use that library to make a PDF editor that can do all of the same things without the purchase. I’m checking into it to see if there is any way I can help, but at the moment, I don’t feel technically savvy enough with PDF format to try and do anything, and I’m not in possession of the time to learn, at least not right now. I will keep my eyes open though, because I don’t expect people just to write free stuff for me, and not consider the possibility that I might be able to help. I am, however, painfully aware of my current limitations, and on that note, it might be a while before I’d have anything of value to contribute.

Here’s to the future… and hoping that one day printing goes the way of the buggy whip anyway so all of this becomes obsolete.