AFP versus PDF/VT

Immediately when we published our free Papyrus AFP Viewer the question arose why we are still so committed to AFP and do not for example rather use PDF.  While we do support PDF in all its variants, let me explain our reasons for supporting AFP:

There are currently five different ISO Standards for PDF in different stages of coordination. Until a few years ago there was no official PDF documentation but Adobe Acrobat defined what was acceptable PDF functionality. AFP is not an ISO standard but has been fully published by IBM over 20 years ago. AFP evolved from transaction printing needs and PDF from Postscript rendering for offset printing. AFP was designed to create high-volume variable documents and Postscript/PDF was designed to produce the highest print quality for an offset print press. AFP will never be as flexible for the highest quality of graphic arts and PDF will never be ideal for variable data printing. The question is not one of document rendering language abilities but one of overall needs for a business.

Task Force 3 of ISO TC130 Working Group 2 is the committee responsible for specifying and advancing PDF requirements and developing the ISO 16612-2 (PDF/VT) standard. The standard is entering DIS balloting stage. Adobe announced middle of 2008 the PDF Printing Engine 2 that will support it. PDF/VT will support the graphics model of PDF 1.6, which includes transparency, ICC-based color management, and layers.

In a PDF/VT workflow, conversion to Postscript is no longer required as the variable-data-printing software will generate output in PDF/VT format, and a Raster Image Processor (RIP) that is capable of interpreting the PDF/VT format has to be used for print production. It means that a VERY specific printer is required. Once you are in PDF/VT you have to print to such a printer. From AFP it is very easy to print to any printer on the market including PDF.

Variable-data-printing workflows based on PDF/VT are HOPED to be able to produce output that is more predictable than output generated by variable-data-printing workflows that are in use currently. Current workflows require that PDF transparency must be flattened, fonts converted to outlines, device-independent colors converted to device-dependent colors, spot colors are converted to process colors. Converting an RGB digital photograph to CMYK constrains the color for output to a device.

So PDF/VT solves some problems of PDF/Postscript but what about the complex variable-data issues? Like VPS and VIPP, PDF/VT will enable for one-time rendering and caching of the static text & graphics in the RIP for a variable-data print run. This allows documents to be produced faster than would be possible if the code for the static text & graphics were sent to the RIP/DFE over and over, once for each document in the print run.

PDF/VT is not practical for high-volume variable data printing for financial institutions with or without Transpromo because one has to generate an archive copy of the document at the same time. I have not been able to find exactly what kind of positioning logic is available in PDF/VT but I am pretty sure that it is in the area of VPS and VIPP, which are basically just forms fillers but do not support dynamic page breaking with complex tables. Therefore the complex document has to be created in the print file PDF and the variable Transpromo elements have to be stored in the printer. That means that a full document formatting run is required before print rendering as for AFP. No advantage there.

One further key requirement of a financial institution is Records Management and that requires that the SAME document that is sent to the customer is kept in the electronic archive. Courts require that businesses prove that IT processes guarantee that it is the same. Using a PDF/VT print workflow with rendering inside the printer and PDF/A rendering outside would make that VERY difficult. PDF/VT is necessary to reduce the problems that PDF/Postscript create. It does not provide more features or substantially higher quality than AFP Transpromo does. PDF/VT enables a few more options around object and layer transparency and that is all.

Using Papyrus with AFP output a large business can create any layout formatting quality needed without the limitations of PDF/VT formatting – including highest print-quality of embedded Transpromo elements – and store the same file to the archive. With the Papyrus AFP Viewer the same document print file can now even be sent to the customer on the web, which before required a conversion to PDF. In case that the business chooses PDF to be sent to customer, Papyrus DocEXEC produces the AFP and PDF file in the SAME PRODUCTION RUN from the internal formatted page structure. Therefore documents printed, sent or archived are guaranteed to be the SAME!

We are working with the AFP Consortium to standardize document encryption and digital signing for AFP documents which is important for archiving and Web distribution.

All in all, I do not see PDF/VT to make inroads in high-volume Transpromo or variable data printing beyond direct marketing applications in the near future.

Free ISIS Papyrus AFP Viewer

I am truly happy to be able to share the news with you that ISIS Papyrus in cooperation with the AFP Consortium (AFPC),  has released its AFP Viewer V7.00 – a browser plug-in  that enables Web viewing of documents created or stored in AFP, or Advanced Function Presentation – on Windows as freeware for individual business users. As a founding board member, ISIS Papyrus played a strong role in the formation of the AFP Consortium and is committed to support of the AFP standard for printing, archiving and presentation.

When most document production vendors were still formatting to native printer formats (and most still do), we have decided 20 years ago that a stable and well-defined printing standard such as AFP – which was originally defined by Brian Platte of IBM – is of benefit to a business. My critical position to the XML based ‘open standards’ comes from their lack of timely, practical and realistic functionality. AFP was always way ahead.

AFP has been there for over 20 years and thus much longer than PDF and is still much better suited for high-volume document applications. Because of the PDF history of the Postscript graphics language it has to be rendered and therefore has a number of drawbacks. PDF/A was created only recently as a subset to resolve some of the issues.

For TransPromo, e-discovery and the electronic delivery of business documents such as bills, statements, and policies, AFP has powerful advantages over PDF as it supports very high print speeds, output integrity and centralized, automated server-based management. With advanced functionality, the Papyrus AFP Viewer provides superior accuracy and speed of presentation including embedded AFP resources, making it ideal for business and production environments that demand superior user interface and presentation of colors, as well as reliable and efficient archiving.

Individual users can now enjoy the professional features of the AFP Viewer for free, enabling businesses to send and present documents in the original AFP format to their customers without conversion. Software vendors who want to embed the viewer into their products can do so through OEM agreements.

As a V7 product it is based on the same powerful, platform-independent GUI technology that is also the base for Papyrus EYE and thus tremendous presentation speed advantages over previous versions have been achieved. Support for Chinese, Japanese, Korean, Thai, Arabic and Hebrew and all other complex languages is integrated. The AFP Viewer does not substitute fonts but loads them from a defined location or from embedded resources.

Papyrus AFP Viewer Features & Capabilities

  • View AFP files from any system (z/OS, Unix, Windows)
  • 100% WYSIWYG on any output channel
  • View any AFP document from online archive or file system in the browser
  • Fast navigation, search and zooming the AFP File
  • Broad support for AFP functionality
  • Print on any laser printer with highest fidelity
  • Full usage of the original AFP resources (Fonts, Images, Formdef, etc.)
  • Linux and Mac versions will be available soon.

The ISIS Papyrus AFP Viewer is available for free download by visiting the ISIS Papyrus Web site (http://www.isis-papyrus.com/e/pages/forms/2/afpviewerdlrequest.html).

Copying is the most sincere form of flattery!

It is quite easy to prove that ISIS went out in 2001 to talk to businesses and analysts about the idea and implemented concept in the Papyrus Platform to merge inbound and outbound communications around the related business processes. At that time everyone shrugged their shoulders. Then the IT world got bogged down by ECM, CRM, BPM, SOA and a lot of other complex environments that had to be managed by expensive and slow governance.

I have spent the better part of the last ten years to fight rigid BPM and the idea that business and economy can be expressed – and worse – executed by rules. But finally the concepts of dynamic workflow, collaboration, case management, and most importantly social networks are validating my approach. I have not been alone. Keith Swenson proposed in 1994 similar ideas of dynamic workflow. I am not saying that I was first with everything, but I was first to propose the merging of inbound/process/outbound into a consolidated case.

Finally these ideas are taking hold despite the fact the most large businesses are still not that much interested. How do I know? Very easy, because large vendors such as EMC are now (as of 2009/10) starting to propose and market exactly that concept. Do they have the software to actually do it? Yes and no.

They have the software because EMC and others have gone on a shopping spree for fitting SW vendors: BPM, ECM, CRM, CCM, XML storage, search engines and portal products were acquired. That in itself does not yet offer a solution because at first you have to make it all work together. If and when these vendors will even come close to Papyrus remains to be seen. Some integration they do via SOA, other is via Eclipse-based Java coding but all in all a complex configure-develop-assemble-deploy process is necessary to get something up and running. The promise of zero code processes is very far fetched to say the least, especially when the process inludes the terminology develop!

With EMC for example you need a lot of coding for an AJAX front end, merge it with the Archive Portal, link it with Digital Asset Management, add Web Publishing, analyse, develop, map and manage the processes into web based queues, or create a fairly complex case management scenario, SOA/Java integrate a dedicated, independent Capture suite with a different front end technology, do the same with the independent document creation suite – all just to get anywhere close to what the Papyrus Platform does out of the box!

Yes – I hear you say – but EMC is the leading vendor! Yes – I say – that much is true, but that does not make it a better product. Their technology is much older than the Papyrus Platform, that also has a good maturity of ten years development and use. Our Papyrus Objectspace has the lightweight objects from the outset that they are now marketing as an innovation. EMC and others have a huge support legacy from ten different customer bases to consider. So they have a much harder time to coordinate ten different software labs and efforts than our centralized architecture effort. And it shows. Look, I am not saying that EMC has poor products. I admire them for having gone down that road and first step up from hardware to buy Documentum and then to build their large software portfolio. But that’s all it is. A portfolio that YOU or a partner has to integrate to get a working solution.

And that is the key difference between Papyrus and all other vendors. Papyrus is a truly consolidated platform with a single application repository, a distributed database and transaction engine for archiving and execution, fully enabled for SOA and XML (despite my lack of enthusiasm about it) and certainly supporting everything you might want to call an ‘open standard’. Where EMC is struggling with the migration from ‘eRoom’ to Centerstage Ajax widgets with additional FLEX programming, Papyrus is offering the revolutionary EYE technology that maps a user defined GUI function to our QT based desktop, as well as a FLASH frontend and Ajax and Java engines in the works. Managed by the WebRepository, the business user can change the GUI without touching the process or application.

Papyrus Case Management is much more advanced than its competitors with the User-Trained Agent automated process discovery, the NLR Natural Rule Language and the Activity Recorder/Player. It makes every BPM product of this planet look old and does away with the immense BPM analysis, implementation and maintenance effort. Machine Learning based document and text classification defines the ‘State-of-the-Art’ of information capture.

Add to that the Social Networking capabilities (chat, wiki, blog) embedded in Papyrus EYE and a business suddenly no longer needs three to four different BPM products. Each business unit (process owner) can implement the way they see fit without technology restrictions or a huge project workload.

Last and certainly not least there is the deeply embedded and watertight security functionality of the Papyrus Platform, which in difference to any other vendor and product is not just a layer with outer shell protection. Papyrus does not just lock the wrong people out, but it requires each user to be authenticated with a role, policy and privilege for any action at any point.

Let me close right here and say that I appreciate the flattery, because finally it is easy to see that they are all copying our long range approach.