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.
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.
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.
- Direct AFP support
- No IBM PSF or Infoprint
Manager required
- Output of print data in:
- Postscript
- PCL
- PDF
- Neutral GDI format
- Controller / server solution under UNIX / Linux or
embedded API for production printing
- Windows based server application for midrange, MFP or decentralized
office printing
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.
- Acceptance of AFP data via TCP/IP, LPR or file input
- Usage of individual Page def. / Form def. files possible
- Acceptance of external AFP resources possible
- Bi-directional printer monitoring
- Flexible and variable printer configuration via GUI
- Full color support (function set 45)
- Color management according to IBM specification
- Cut sheet & continuous feed support
- Enhanced 'n-up' support
- Double byte support
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.
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.
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.
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:
- Merging of PCL overlays
- Generation of OMR and barcodes
- Reprint & Cluster option
- Interface to an archive system
- Downstream PDF workflow with PDF signature
- Accounting of all print data
- Using other Mercury output management modules, like:
- PDF workflow
- Document Separator & Collector
- Postal Sort Module
- etc.
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.
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.
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.