Advanced Function Printing (AFP) is an IBM proprietary protocol used for printing bulk documents such as bank statements. We have an application that takes as input user text messages, typically marketing messages in specific fonts and sizes, and generates the corresponding AFP overlays. These overlays are merged with the main customer documents, also in AFP form, and printed. This application used to be written in Visual Basic, and a third-party tool was used in the application for generating AFP overlays from the user input text.
Some time ago, we took on the task of converting this application to WebSphere with a Web interface. We could find a third-party text editor and spellchecker to integrate with the Java front-end, but we couldn’t find a Java Application Program Interface (API) for converting the given text to AFP either in rich text or XHTML format. We searched extensively and even approached IBM, but they weren’t interested. This was surprising because AFP is an IBM format and they are a big promoter of Java and Web technologies.
To solve our dilemma, we decided to build a proprietary converter. What follows is a description of how we converted the XHTML string from the front-end, Web-based editor to an AFP overlay, both of which are eventually stored in a DB2 database. The new application runs in WebSphere on z/OS and uses DB2 for storing data.
Figure 1 shows the overall application flow. At a high level, there’s a Web-based editor that lets a user create a message. The message is stored in a DB2 table in XHTML format. Insertion of the message into the DB2 table causes a trigger to execute. This trigger converts the XHTML message into AFP overlays.
The conversion from XHTML to AFP overlays occurs in the following steps in a COBOL-stored procedure invoked by a DB2 trigger:
1. Parse the XHTML to separate various text segments and their respective presentation properties. We used COBOL XML API for this; the extracted text data and corresponding presentation properties are separated and stored in a temporary table. The presentation properties are stored using the standard IBM font naming conventions.
2. The word wrapper algorithm takes the text and its corresponding properties to format it into fixed dimensions of the message box on the physical document to be printed.
3. The output of the word wrapper algorithm is in the form of Overlay Generation Language (OGL) commands. OGL is an IBM compiler that takes in formatting commands and generates an AFP overlay.
Figure 2 shows an example of how a given message undergoes the necessary conversions:
1. The user creates a message in the Web-based text editor (see Figure 3).
2. The editor stores the message, in the form of XHTML, in a DB2 table. Figure 4 shows the XHTML generated for the previous message.
3. This XHTML string is parsed and word wrapped to create OGL code (see Figure 5). The characters aren’t visible in the OGL code because the font selected uses EBCDIC code page T1001004.
4. This code is run through the OGL compiler to generate the AFP overlay, which is stored in the DB2 table. The stored AFP object can be viewed through an AFP viewer plug-in for the Web browser. The result (see Figure 6) matches the message the user entered into the Web-based text editor.
We solved our problem with a homegrown solution. If your site uses AFP for printing bulk documents and you need to handle user text messages as inputs and generate AFP overlays, you may want to follow our example. If you do so, let us know how it works for your organization.