The main benefits expected from this FPDF4ZOS component are listed below:
Very cost effective solution to produce PDF documents directly from MVS, Windows or Unix platforms:
- No product to buy and no additional external component,
- Easy learning curve: no need of complex and specific AFP expertise to acquire and | or to maintain
- Does NOT need a lot of CPU to run,
- Production of high quality and relatively light PDF files in terms of size.
A tighter integration between core applications and PDF files generated:
- Possibility of controlling PDF file metadata: Author, Subject, Title, Creator, Producer, Keywords. Besides, MVS specific informations such as Job Number, Job Name and Job User Id are automatically inserted into Producer metadata.
- Possibility of generating XML and | or CSV files beside PDF documents in order to specify the attribute of each and every page for printing or further processing by a recipient to make sense of a mass of PDF if archiving or electronic document management is required.
- Possibility of encrypting the PDF files for sensitive documents at both user and owner levels. For the latter, several permissions combinations are handled: modification, printing, cut and paste and comments.
- A set of hierarchical bookmarks may also be generated from within the application.
- Possibility to insert internal or external links, embedded data, miscellaneous annotations, etc.
A wider range of graphical possibilities which are no longer limited by AFP constraints:
- Handling widespread “JPG” image format instead of being limited by PageSegments ones (IBM proprietary, somehow outaged image format) [1]
- Slanted text or images, rounded rectangle, circle, ellipse, polygon, sectors, rotations, color transparency, etc.
- Using widespread character fonts into office workstations instead of IBM supplied ones which by the way are required to be systematically embedded into the PDF files, thus mechanically increasing significantly file weight.
- Dynamical tables spanning several pages [2]
NB: in an attempt to be exhaustive, there are still arguments in favour of AFP usage over FPDF4ZOS which may be raised and one should carefully weight benefits before picking up a solution. Indeed, AFP is a format dedicated to printing while PDF’s goal is more electronic documents oriented. For instance, one cannot specify in PDF various features which are have been handled for decades by mainframe mass printers:
- Paper handling: which feeding tray to pick up paper sheet from and toward which target tray to route those sheet once printed,
- Printing proper: both sides printing, margins which can dynamically be specified in AFP data flow thanks to FORMDEF parameter and its COPYGROUP instruction while these features are handled by printer drivers in case of PDF, regardless of documents being processed.
- Post print processing: stappling, folding, micro-punching, etc.
- Printing tracking which is native in AFP production chains and, as of now, is somehow lacking in PDF-Postcript printing environments. This last shortcoming is one of the main reasons why many companies as well as printing houses still stick to AFP for their mass printing activities.
However, it seems there is an overwhelming trend toward electronic documents and PDF, especially at a time when most companies seek for ways to reduce systematic printing and turn to electronic archiving, thus reducing the importance of the few counter arguments just listed above – not to mention current orientations toward less and less paper in our world of ever shrinking resources.
[1] In fact, there are possibilities to include object containers in AFP features but it requires additional processing to transform them into AFPDS objects.
[2] There are features in AFP to obtain dynamic tables by using RECORD FORMATTING options in PAGEDEF but documentation is rather scarce and it seems that usage of these features has not yet taken off in AFP world, although those have been available for years …