BPMN/XPDL Execution in Papyrus

December 18, 2009

Those who follow my blogs might already be bored with my frequent bickering about process management. That I am not the only one to criticize the BPM market you can read in Terry Tschurter’s paper on the BPM State of the Nation 2009.

The worst thing I could do is to complain about something that I do not know much about. Therefore I would like to show to you that we at ISIS Papyrus are no strangers process management concepts, as easily proven by this announcement of the BPMN/XPDL Editor of our Papyrus Platform. I will not go into the details of either BPMN and XPDL here.

Keith Swenson is the authority on XPDL and BPMN and covers the relationship in this post: The Diagram is the meaning.

Let me just say that BPMN is a modeling notation for designing processes and XPDL is a superset that also contains graphical features of the actual drawing. Therefore we decided to cover both in the Papyrus Platform. Why did we do that if I am so opposed to BPM? As you might know, my opposition is mostly related to the huge, disconnected analysis and optimization process bureaucracy. Therefore we defined standard BPMN/XPDL to be used as execution engine:

BPMN/XPDL in the Papyrus Platform can be created and edited while you work and executed AS-IS.

It is fully executable by linking with the UML data models, content artifacts and Natural Language Rules defined in our Papyrus WebRepository. Also BPMN/XPDL is stored in the WebRepository using Papyrus’ change management and automatic, distributed deployment capability. All additional logic necessary is cleanly encapsulated in those classes and is not created during BPMN conversion into BPEL or by expansion with Java. BPMN in Papyrus is mostly used to define sub-processes in our Adaptive Process concept. The user interface is handled by our Papyrus EYE widgets so there is no XSD/XSLT mapping and Ajax forms programming. The business data are simply accessed through the UML classes linked to our Service Adapters (SOA and others). Finally, BPMN can be used in an Adaptive Process environment and allow 100% runtime editing.

Here is the Papyrus Platform BPMN/XPDL 2.0 Designer:


AFP versus PDF/VT

October 25, 2009

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

October 24, 2009

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).