When it came time to brainstorm for features in ColdFusion MX 7, many ColdFusion team members wondered what we could give developers, so that you would get even more use out of ColdFusion. One theme we heard consistently was how hard it is to create portable rich document from web pages. We thought, wouldn’t it be nice for developers to be able to add a button to any web page, which would convert rich HTML content into easily printable PDF or FlashPaper documents?

Your request resonated with the team. We thought about a ColdFusion tag, one that consumes HTML content and converts it to rich documents. Last year, during the MAX 2003 conference, we demonstrated this idea in the sneak-peek session. We heard a resounding approval from you when we told you the possibility of providing this functionality in the next version of ColdFusion—it was that approval that helped us decide to make it part of ColdFusion 7.

The development team faced many challenges during the design and implementation phase. Foremost, HTML is a very lenient language. HTML writers can get away with broken syntax on modern browsers. This factor created an enormous challenge for parsing data and converting it to PDF/FlashPaper-specific “language.” During our research, we found that there are some products out there already trying to address this issue. However, most of them either require an extra installation procedure, such as a C++/native solution that is not platform-friendly, or require an expensive add-on OEM with ColdFusion.

One technology that came close to adoption was Apache FOP, which converts XML to PDF by relying on XSL (style sheets) masking. The main advantage of FOP is that it deploys on top of Java, the technology that ColdFusion MX standardized upon. However, the ColdFusion team found that the Apache FOP engine only consumes parsed XML content. It applies the XSL style sheet for layout information and then translates it to native PDF content. Adopting FOP would have required ColdFusion developers to edit their HTML into XHTML, which would have increased the difficulty of their using this feature and the learning curve for developers. This was out of the question. We researched the idea of autogenerating XHTML from HTML but that was extremely error-prone and raised other issues.

Therefore, we settled on our own solution—one that allowed us to consume regular HTML 4.01 and CSS 1 and 2 without requiring any modification by the developer. This greatly enhanced the developer experience, increased the value of this feature, and—at the same time—met all our original goals.