PDF "Trouble"

I like Jeff Atwood's Coding Horror blog. I use it as fodder for many posts at my internal work blog. It covers a lot of "looking forward" topics for my group, but it doesn't hit home as much as it could. Some of those topics are so far out that my coworkers just aren't thinking about these things yet.

That changed today.

Jeff's post on PDFs is directly relevant to things that I do on a daily (or monthly) basis. In it, he argues against PDF and for HTML, which 99% of the time is fine. The user experience is better with HTML, it can do neat things by interfacing with the browser.

However, it doesn't allow the user to save their content. PDF does. Why is this important? Because you need to save a legal document.

An aside, my work currently consists of producing electronic statements for large companies. Your monthly cable bill, your wireless bill, your credit card bill...you name it...online. I have produced many HTML based statements, which are great. They interface with the end user, can allow them to sort transactions in some cases, or download CSV files to import into a spreadsheet. So why is it, that I argue against Jeff and for PDF? Because you can save PDF and get a file that looks and feels like that paper document I get in the mail.

Look and feel is important for large companies. They have spent loads of cash on print document authoring software. They spent even more cash on print vendor contracts or large print shops. It is important that the document they produce for paper looks the same or very similar then the one on the web. It reduces customer care costs if they are the same. PDF allows for that. You can do it with HTML, and some forward looking companies and utility startups are doing so.

I believe Jeff is simply ignorant of some of the uses for PDF, and probably doesn't know about the world I interface with.. But read the comments and you see a lot of users who just don't understand the advantages of PDF when it comes to statements. They overestimate the client and their legal team, as well as the end user.

As companies try to get more "green", they will try to reduce paper costs which means turning paper off for customers. As this occurs, HTML (well, actually the browsers) will have to come up with a better way to save a statement. Obviously IE can package a statement in an mht file. But Firefox, Opera and Safari can't. And we all know the holy wars that are unleashed when you limit your audience to one browser.

Using TestNG to drive "eyeball" testing

Second of my Best of Internal Blog (BoIB) series originally posted on 9/6/2007 and updated 11/14/2007

In my daily job, I do something that NBC would consider "green". I digress, but wasn't that an awful promotion last week? I help large companies save paper (and money) by presenting documents they would normally send to their customers through the mail. 99% of these documents are bills.

During my time working with various documents, I developed a tool based upon the testing framework TestNG. This tool allows us to look at a "cycle" of documents and test various things on each of them. We need to be sure that we're presenting each item to the user as it looks on their paper statement. It is most useful when we have a client who cannot generate an edge case test file for us due to the legacy nature of the billing system.

I had an opportunity to dredge it up again. The code for this tool is over two years old, but works relatively well with little fanfare. It grabs a list of identifiers from the database for each document, generates a URL to each document and then browses the HTML document using HtmlUnit. However, I recently found it has a new use.

The latest use is PDF testing. Some of our clients use a document format from IBM known as AFP. It's a high speed printer format, but it is similar to PDF in many ways in that it describes where on a page to display text. It is possible to generate a PDF document from and AFP document using a number of tools.

So how can the document tester help? Simple, create a special test class that is setup to archive the PDFs for each statement to disk.

Here's the test method inside TestNG (obviously I'm not repeating all of the bootstrappy type stuff that gets the URL to the document)

@Test(parameters = {"filePath"})
public void testGetPDF(String filePath) {
 List formList = theDocument.getForms();
 Iterator formIterator = formList.iterator();
 // 1st Form gets the PDF
 HtmlForm myForm = (HtmlForm) formIterator.next();
 HtmlInput myInput = myForm.getInputByName("viewDocument");

 try {
   Page newPage = myInput.click();
   WebResponse resp = newPage.getWebResponse();
   ByteArrayInputStream pdfStream = (ByteArrayInputStream) resp.getContentAsStream();
   ByteArrayOutputStream baos = new ByteArrayOutputStream();
   File pdfFile = new File(filePath + this.theDocumentID + ".pdf");
   FileOutputStream fos = new FileOutputStream(pdfFile);
   int count = 0;
   int data = pdfStream.read();
   while (data > -1) {
     count++;
     baos.write(data);
     data = pdfStream.read();
   }
   baos.flush();
   baos.writeTo(fos);
   baos.close();
   fos.close();
   pdfStream.close();
 } catch (Throwable t) {
   org.testng.Reporter.log("Throwable: " + t.getMessage());
   t.printStackTrace();
 }
}

Pretty neat! Now you get a directory full of PDFs that you can archive and ship off to your customer, or browse yourself. It sure beats a manual process of click and reload, and assures a proper test of using the actual application to generate the document. You could obviously save HTML or CSV files as well, but they can be tested using classes within the testing tool, which is obviously more efficient. This is simply making "eyeball" testing a bit faster.