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.

Advertisements

9 thoughts on “AFP versus PDF/VT

  1. Pingback: Twitter Trackbacks for AFP versus PDF/VT « Papyrus Platform Architecture [isispapyrus.wordpress.com] on Topsy.com

  2. Pingback: uberVU - social comments

  3. Are you a sales guy?

    “It means that a VERY specific printer is required.”

    No, depending on the vendor DFE’s will be updated. There is no requirement for new hardware.

    “From AFP it is very easy to print to any printer on the market including PDF.”

    No, ANY printer in this market? Doubtful, AFP has a healthy market share however it isn’t the only PDL for transactional/ transpromo printing.

    That being said though, most of the bureau/ service providers in transactional/ mailing business I’ve been involved with have been pushed into more DM and color offset transfer to keep up with declining transactional revenue ($$$, not volumes). PDF/VT and JDF offers better workflow options than AFP across the board.

    VIPP does transactional statements quite well by the way, unfortunately the composition tools for creating a good VIPP application aren’t really out there yet. VPS doesn’t have much over PostScript except for caching commands. Well written PostScript is just as efficient as VIPP or VPS (VIPP is written in PostScript).

    I guess if I worked for a bank or telco sending transactional letters to customers, I probably wouldn’t move from existing AFP processes in the near-medium term. BUT, if I worked for a service provider I would seriously be looking to improve my service offerings and workflow for optimal output and capabilities.

    And another thing, if you’re going to render AFP via browser on the fly, why would PDF/VT not be sufficient for this purpose…? Why would it have to be PDF/A. I could do this without buying your proprietry tool with PDF/VT.

    • Thanks for your comment. Are you an expert? It does not seem so. You have apparently absolutely no idea what kind of functionality Papyrus offers in terms of formatting and print management workflow and how limited PDF/VT, VIPP, VPS and PPML really are. There is a reason that the largest service provides in the US ALL use Papyrus and together produce 50% of American credit card issues (several billion pages a year) of Transpromo customer documents in B/W, spot color and full production color. While you are bemoaning the fact that there aren’t any composition tools for VIPP, our Papyrus Designer has been available since 1996, when we already did our first Transpromo applications in color for Citibank in SIngapore in mixed English and Chinese.

      I agree that our product is too expensive for a mom&pop service print shop in a garage, where I think the tools you suggest fit quite perfectly. Thanks again, but I recommend that you do your homework and learn something before making such statements.

      • The ignorance is on your behalf. I didn’t make any claims to having any knowledge of your product. I offered corrections regarding choice of a PDL platform, which was the main topic of this post.

        Expert? Yes, and as a successful analyst programmer in the production printing industry for the last 15 years. I’m not the sales guy here.

        “Googling” PDF/VT brought me across your post and noticing obviously wrong information I felt obliged to set the matter straight. You didn’t care to address and object to what I quoted you on (bait and switch is a typical sales approach).

        And to say service provider market is mom and dad/ garage operations… you should do your homework! I assume you don’t have any customers in this sector, it’s probably the other 50% of the market you’re missing out on.

  4. S_shakey, I apologize for having been ticked off by your unprofessional tone and having responded. It was late at night and I was tired. Sorry. But if you attack me personally again, I will simply delete your comment. You admit that you know nothing about AFP and what products like Papyrus do with it. You feel obliged to correct me and make statements without even bothering to go to our website and find out about Papyrus and maybe me, before you call me a ‘sales guy’. I have been in printing for 37 years and designed print streams for IBM, Xerox and others when you didn’t know yet that such a thing exists. I am the founder and current chief architect of a $100 million software business with 2000 large corporate clients. Your enlightening information about ‘the other 50% market I am missing’ shows that you also no nothing about a market focus, which is obvious as you hate sales guys. We provide solutions for a specific market and the smaller mail-shops have different needs and can’t justify the expense of a high-end solution. Your statements show that you did not even properly read my post and lack the knowledge to understand what I wrote. Thus I will try to elaborate:

    1) If a new printer micro-code or new formatting has to be loaded it means that you need a very specific printer. You can’t simply print to some other printer type. Papyrus prints from AFP TO ANY PRINTER and renders the printer features at runtime because it has to handle much more than just the page image. See below.

    2) VIPP has 10% of the functionality of the Papyrus engine and DOES NOT offer full pagination. (I can prove that in about five minutes!) As you say there are no sensible tools for VIPP. None of our customers would be willing to let hackers get into Postscript or PCL coding. They need to design a dynamic multi-page layout and have it printing guaranteed correctly millions of pages the next day. Papyrus enables also fully-dynamic, rule-driven marketing campaigns defined by non-technical marketing personal through the web browser. In fact in many cases 100.000 documents a day are individually created by thousands of business users with Papyrus Case Management (i.e. insurance claims) and centrally collected in our PrintPool and bundled, sorted and barcoded for printing and then archived, while ensuring HIPPA compliance.

    3) As an expert you should know that a PDF print stream that has been rendered for production printing is utterly unusable for Web display. It typically has huge CMYK color images embedded (or those are preloaded into the printer and as such not available for web-presentation), it may-be formatted for n-up, contains barcodes and is typically a huge number of pages that contains many documents. For Web display you need to send a single-customer Web optimized document in either PDF or AFP. The document mostly has to be encrypted. Our AFP Viewer is as free as Acrobat, so there is nothing to BUY!

    4) I made it very clear in my post that I view this through the large corporate lens of my clients and not through a small-time print-mail-shop programmer perspective like you do. All our customers have tremendous cost pressures and buy Papyrus because it saves them millions in programming print streams while still enabling Transpromo and fast turnaround times. PDF/VT and JDF offer nothing compared to what Papyrus does with AFP before and during printing. JDF job control is not a print stream issue and the same is true for AFP.

    Papyrus enables our customers to use our unmatched Papyrus Designer to create the most complex, multi-lingual, multi-colour, multi-target print jobs without needing a programmer. It does free-text-paginated, dynamic charting print stream creation at up 50 million pages per hour. The Papyrus ADF Automated Document Factory enables those print streams to be mail-sorted, postal cost and envelope size optimized, with just-in-time transform to multiple target print streams (PCL, PS, PDF, IPDS, IJPDS, and image-streams) while taking care of simplex, duplex, n-up wide-web printing, color rendering, envelope and inserter barcoding, backward-sequencing for roll feed, multi-target splitting to email-campaigns, web presentation and archiving. Any number of print jobs can be merged and then load-balanced and optimized to print with the least amount of paper changes across different printers allowing the lowest possible cost profile and match needed print quality and cost per recipient profile.

    It is impossible to execute all of that in PDF/VT, but it could be a printer target format of the above. That was the point of my post.

  5. Thank you for elaborating where you didn’t in your last post.

    No personal attack here, nor intended in previous posts. I was just offering a different opinion of the information provided (even in fear of censorship).

    Regarding points;
    1) Interesting, but I figure I will be able to print a PDF/VT file to any “device” in a similar way you print a rendered AFP file to any “printer”.
    2) Non-AFP based workflows are practical for transactional statement production, not all companies use the same process. Check with your competitors offerings.
    3) Yes, there’s a few considerations around this depending on the content of the file. I’m sure you have the same challenges with AFP.
    4) I’m sure you will end up supporting PDF/VT for output, just like your competitors. It will appeal to some more than others, and not only the small sectors either.

    I would further elaborate if this was not a public forum and I didn’t consider my anonymity important. Please delete my posts if you do not wish to continue this thread, I do ask you consider the points and add some clarity to your original article. I hope this seems fair to you.

    BTW, I don’t hate sales guys, or sales processes (generally), but I remain unapologetic for thinking this when I see vague, irrelevant or misleading information.

  6. Anonymity means that you cannot stand by your words with your name. It is that simple!

    PDF/VT offers no benefit to what we do and we know as we do support it and have not found substantial benefits over our Postscript output. Therefore my post was prompted by a customer question related to the AFP Viewer and their PDF viewing issues.

    For 22 years I have never looked at competitors because they have always been far behind. Simple formatting and printing is not our core business, but we are still the leading supplier in large corporations.

    Yes, anything can be coded and I feel fine to challenge you to deliver the same end-to-end workflow that Papyrus provides with PDF/VT or any other HW print stream in a way that would be practical to any size of business.

    My article is more than clear and I see no need to make any change at all. I simply stated that I didn’t see that PDF/VT would replace AFP anytime soon.

  7. Pingback: 2010 Blog Stats | Papyrus Platform Architecture

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s