HTML5: The End of the 8 ½ x 11 Era
Today, Web sites are being increasingly designed based on the principles of "responsive design," usually with a "mobile first" thrust. Hence Internet sites are fashioned for mobile devices with smaller displays and touchscreens first, and then for larger displays (like the PC, etc.). The CSS 3 (Cascading Style Sheets) design language certified by the World Wide Web Consortium (W3C) allows the layout to be adjusted to the given display size. While a large screen can accommodate information in multiple columns and with illustrations, the smartphone is limited to the most essential information displayed in a single column. This is accomplished via media queries (see below), which apply different style sheets to the HTML document based on the output medium.
For the first time, HTML5 now propagates scalable vector graphics (SVG) as the universal vector graphics format, yet another milestone in the retreat from pixel-perfect Web sites that do not always perform well in the age of mobile devices. A small pie chart, which requires 32 KB as a PNG bitmap, may need only 4 KB as an uncompressed SVG graphic, which in turn is scalable to any size without loss of quality. Supporting high-resolution displays is no longer a major challenge.
In sum, HTML5 and CSS 3 have contributed greatly to the presence of the Internet in everyone's pocket. We buy our train or movie tickets via smartphone more often. A steady stream of new payment systems that use Bluetooth or near field communication (NFC) is arriving on the market. We will probably use our mobile "companion" to make purchases more and more in the future. The EC card and our good old wallet are facing competition.
Slow retreat from the printed document
But what does this mean for high-volume document processing? The fact remains that billions of Letter-sized hard copy pages are still being produced every year. We send and receive invoices, delivery slips, dunning letters, insurance policies, notices, etc. in printed form. But B2B commerce is also turning more frequently to electronic document exchange, including document processing (e.g., using formats like EDI or UBL).
Things digital are advancing in Switzerland. Most banks there now support the receipt of e-invoices. They do not arrive in traditional letter form but are sent electronically directly to the bank's own e-banking system, where they just need approval for payment. The PDF of the invoice can be downloaded via a link. Some invoice preparers have already begun charging additional fees for paper invoices.
Many large firms offer portals that allow their customers to view their most recent invoices and download them as PDF files. The problem is that even when these portals are optimized for mobile devices, the customer has to request access to each. Besides navigating the inherent password jungle, this also entails a lengthy 'hunting and gathering' session for documents from all the possible sources.
Furthermore, as shown in the above examples, 8 ½ X 11 was and is the base format and hence hardly the best for mobile devices. Viewing a PDF file on a smartphone or a smaller tablet is just no fun, making HTML5 the ideal candidate for the document. Yet that would mean offering three possible format options for every document: XML for raw data, HTML5 for mobile devices, and PDF for traditional letter-sized formats. This, in turn, incurs additional development costs for HTML if print output needs to be accommodated. In certain cases, these costs can be reduced by converting PDF files to HTML, although that process does not always produce a satisfactory result. Not all layouts are amenable to automatic conversion to a lucid HTML display.
Will HTML5 replace PDF?
It's the content that counts
A digital signature plays best in this scenario, both to verify the sender but also check that the file has not been changed. The document also needs to be completely accessible to people with physical and cognitive limitations. The EPUB (electronic publication) format is one standard that already takes these requirements into account. Although it is seen primarily as an eBook format, it would be ideal for multi-channel display of any type and format of document. For instance the current EPUB 3.0 version supports the declaration of alternative presentations of one and the same document (e.g., visual HTML5 and raw data as XML). Though hardly a sensible alternative, even a PDF could be embedded in a ZIP-based container.
In the final analysis, the way documents are sent is not so important. An e-mail attachment suffices, although the sender cannot reliably determine whether the document has arrived. De-Mail, IncaMail or standardized HPPTS interfaces that can be made available from online archives are certainly alternatives. You would need to define only the invoicer's URL for your documents, e.g., "mailto:firstname.lastname@example.org" or "https://onlinearch.iv/john.smith".
This is just one scenario of how HTML5 could affect output management in the future. The fact remains that document exchange is more about content and less about presentation; ultimately it's the data that counts. Presentation is merely a means to an end, and HTML5 covers a lot of territory; so much so, that it will inevitably turn traditional print-oriented output management on its head.