AFP and IPDS Printing Data


These are data formats from within the IBM world which are used for processing and printout on IPDS capable printing systems. These data formats are most common within IBM Host and AS/400 environments.

What is the difference between AFP and IPDS print data?

AFP (A)dvanced (F)unction (P)resentation consists of data information that has not yet been prepared for printing. Variable print data, layout and resources are still separated here. With these, data print data streams can be generated with the help of further processing applications. The rules for the generation of print data are stored within so called Page.def and Form.def files. The so created print data stream is called IPDS (I)ntelligent (P)rinter (D)ata (S)tream.

AFP and IPDS


What is the advantage of IPDS printing?

For successful IPDS printing, it is necessary that the printing systems process IPDS print data. While processing those IPDS print data, a bi-directional communication is established between the host or AS/400 application and the printing system, means the printing systems sends information about successful printed pages back to the application. This bi-directional communication guarantees a complete and secure printout. It furthermore allows a page exact reprinting of print jobs.

What are the disadvantages of IPDS printing?

Beneath the already listed advantages, IPDS printing has one crucial disadvantage: Already at creation time of the print data from the AFP templates, the decision has to be made, about which physical printing system should print those data. This is necessary, because the IPDS print job data must contain all hardware specific information like commands for controlling of printer specific functions like finishing, etc. This does not guarantee the flexibility any more, that is postulated in today's markets.

Today's requirements for a print and document workflow:

Within the framework of persistent rationalization, today more and more computing power is outsourced to data processing centers and more and more printing systems are outsourced to print service provider. This destroys a continuous workflow. The print data, provided from the data center, have to be adjusted from the print service provider to the requirements of his print hardware. The data center often provide only the hardware independent AFP data. Therefore the print service provider needs a high performance software package for making these data 'printable', or alternatively he needs digital printing systems that directly can understand and process AFP data.

Why Mercury?

The Mercury Print- and Output Management system is able to receive and process AFP, as well as IPDS print data, beneath various other print data formats. These AFP or IPDS print data are converted to PCL, PostScript or PDF for printing them to standardized printing systems. The salient feature of the Mercury system is, that for usage of PCL data streams, the the bi-directional communication between application and printer is kept, as requested from IBM. This allows the usage of Mercury, depending on customer requirements, in three different cases.


Top


 

Mercury AFP Product Placement


The Mercury AFP controller solution is an enhancement of the Mercury server. This enhancement allows the Mercury server a direct processing of AFP print data from AS/400 and mainframe environments and to generate PCL, PostScript, PDF or common GDI output. The Mercury AFP package is available as Windows server solution, as UNIX / Linux controller solution, or as embedded solution.


Top


AFP Function Overview


The guidelines for the range of functions of the Mercury AFP solution, are the specifications of IBM itself. Both, full color support and enhanced 'N-up' functionality for fanfold printing systems are part of the Mercury AFP solution. Also the newest IBM specifications about 'color management' are integrated according to the demands of the AFP consortium.


Top


Homogenous AFP Printing Solution Embedded API (Unix / Linux)


For high volume AFP printing a solution for Unix / Linux is available. This is available as server, as also as an embedded API for OEM controller solutions. Especially with continuos paper feed this solutions allows performance result of far more than 1000 ipm.

Embedded AFP API

Top


Midrange, MFP and Office Environment


Beneath the high volume solutions for UNIX / Linux, the AFP solution is also offered as a standalone Mercury AFP server for Microsoft Windows within the framework of Mercury server solutions. In contrast to the embedded or controller solution, here an unlimited number of midrange, MFP or office printing systems can be driven from the Mercury AFP server. Hereby it is completely independent, whether these printing systems support PCL, PostScript, PDF or GDI printing. All of these output data formats are supported from the Mercury AFP server.

With the possibility of integrating an unlimited number of printing systems, this solution is also a very attractive alternative in terms of price.

AFP Environment

Top


System Design Of The AFP Software


The Mercury AFP software solution itself is designed according to a modular concept. Page def. and Form def. declarations, that are delivered from the host, can be processed 'on the fly', as well as individual Page def. and Form def. declarations can be merged with an existing data stream. This allows the easy replacement of existing solutions with the Mercury AFP solution.

The software design is illustrated within the following graphic.

AFP System Design

Top


Unique Features In Combination With Mercury


Of course, the Mercury AFP solution can be integrated into the complete Mercury print- and output management solution. Thus allows, beneath of the actual AFP support, the use of all additional modules of the Mercury solution. So an optimal workflow consisting of print data post processing, process chain control, barcode printing, forms merging, can be realized very easily with Mercury in combination with Mercury AFP.

Postprocessing of print data possible:


Top


The customer prints IPDS data,
but does not want to use IPDS printing systems


As described above, the customer receives ready setup IPDS print data, where all printer hardware specific printer control commands are already included. Mercury receives these data and converts them, among others, to PCL. The Mercury output management allows the flexible dispatching of these originally IPDS print data to any desired PCL printing system, without loosing the bi-directional communication between application and printer and without loosing the streaming mode. With the usage of Mercury, the customer gets back the flexibility within his output management, which has been lost by using a printer integrated IPDS processing as static 1:1 solution.

Host with "embedded" AFP conversion to IPDS


Top


The customer receives AFP data and wants to
print them to a non AFP capable printing system


By using Mercury as "embedded" AFP solution, the customer can directly process his AFP data and print them to one or multiple printing systems. Here Mercury works, e.g. under Unix/Linux, as a prefixed or integrated AFP controller solution. The Mercury server, as a controller, manages the specific controlling of the printing systems. This solution is especially suitable for continuous feed printer and works for the user nearly as a "plug & play" solution.

Homogeneous Mercury AFP print solution as embedded API (UNIX/Linux)


Top


The customer receives AFP data and wants to
dispatch them flexible to various standardized printing systems.


This is an enhancement of the pure IPDS solution, as described within the definition of case 1, but now the AFP data are received directly from the Mercury print management. The customer now has a maximum of flexibility, because, in addition to the pure IPDS printing, he also is able to modify the correspondent AFP data. All further advantages of the definition of case 1 are still valid.

Host with target address (Hardware) independent AFP transmission to Mercury


Top


All statements without engagement. Errors and changes excepted.
All logos, trademarks and tradenames are the sole property of the respective companies.