Writing AFP

Modification of existing AFP data or composition from PDF content

acrobatAs documents, AFP data sometimes need to split or merged. Such operations do not involve parsing the page contents, thus can be done at physical level, leaving atomic data blocks intact while the focus is the selection, extraction, and reassembly of such blocks. Our system design supports extracting data from original input at various levels: page, container, even individual data block.

When page contents do need to be parsed and modified, the concept of “colorification” can be a very good example — typical the AFP pages are composed in black and white, with raster fonts, one-bit images, black lines and pattern fills. When converted to PDF, although content can be faithfully converted so that the resultant PDF look identical to AFP page, this may not be the most desired outcome. Rather, some beautification needs to be done: smooth shadings can be add to the background, logo image can be replaced with a full-color one, decorative or promotional contents can be added to the white spaces, tiling patterns can be replaced with colors, etc. These colorification operations can be readily done within the DocEvents framework using XML tags that specify selection and modification rules.

Under some other situation, PDF also needs to be converted into AFP. For example, some customer may want to run a set of customer data records against several PDF AcroForm files as templates, generating filled and flattened pages and converting all the pages into AFP for batch printing. For most convenient and reliable results, our facility can rasterize all PDF pages into images of given DPI, then overlay the dynamic text after being properly formatted by the PDF handling module. The latter is particularly important in the CJK world where custom areas of Unicode range are frequently used to display non-interchangeable glyphs.

Our AFP / PDF technology foundation enables workflow involving any of the above use cases.

About the Author: Cyphia