New Color Management Technology to be Released...

I think this will be of great interest.

follow it here...

The core technology will be discussed on Lone Wolf as it is not AFP specific.

Color in AFP

AFP has a number of interesting places that it hides color.

Most obvious from what I have posted so far are images. AFP does not support as elaborate a model as PDF but there are still many places you can put color.

In AFP there are some 150 or so types of records. Each type of record does something unique and specific. Within these record types there are several more sub-record types. I divide the main AFP record types up into different categories based on my goals. For example, for color processing Page Segments (PSEGs) are used to hold images, bar codes, and graphics. One Page Segement Begin/End record pair can bracket up to a few dozen or so other AFP record types - mostly related to specifying things about height, width, resolution, and so on. Within each sub category, e.g., graphics, there are record types that hold sub-records, e.g., for drawing a box, stroking a line, etc.

So in terms of color you need to be able to find the PSEGs in an AFP file and them delve into them to find their sub-parts. Only at that point can you then think about processing color.

Let's consider the GOCA sub-record type in PSEGs. Color is manifest in a couple of record types related to color, here we will consider GSPCOL because its the most general. This is basically a "set color" operator. It supports RGB, CMYK, LAB and a few other types of color.

So to find and change a GOCA GSPCOL here's basically what you have to do:

- Scan the AFP file until you find a Begin/End pair of Page Segment records. These two record types bound all GOCA - though there may not be any GOCA in them.

- Scan the AFP records in the PSEG and look for Begin/End Graphics. If we don't find any we are done.

- If we find some, then we have to find the AFP records containing the sub-record GOCA commands.

- We then have to scan these sub records looking for GOCA GSPCOL record types.

- When we find a GSPCOL when then check it for color to determine what we should do with in.

Images work in a similar fashion but all the different. In the case of image there are also the actual image raster to consider as well, i.e., in GOCA you can change the color of a box with GSPCOL in a GOCA AFP record. For images you have to do basically the same, but also change the actual raster.

Unfortunately each major color carrying AFP record type, e.g., PTX, has a similar yet unique process required for it.

The road to an AFP product...

So my customer has a very large license from a European AFP software vendor. They've had this license for at least 10 years and they use it to do both original mailing work as well as "convert" jobs.

A converted job is a job where they receive a set of pages from a customer along with mailing data. The use their AFP software to create "mailing labels" that overprint the page's original mailing information with new, presorted information. The converted jobs are discussed more in my PDF Outsider blog.

The in-house composition jobs involve receiving customer logos that must be processed in AFP. Fortunately or unfortunately the logo data arrives as "traditional" Mac file formats such as Quark, Photoshop, etc. As a result these logos must be converted to AFP via a conversion tool. The tool provides several options to convert PDF and PostScript to an AFP "Page Segment" - which is basically an image.

This customer suffers with a number of peculiar problems. First of all there are various versions of the converter software. Some create Page Segments (PSEGs) with certain types of compress, others with different types. Some versions use lossy compresion, others don't. Of course there are various options to control these things but either they don't work or the customer can't get them to work. At the end of the day they suffer constantly with bad PSEG files.

The customer has this all hooked up with various other tools from us and other vendors to create a series of PSEG files with various rotations (AFP lacks a general purpose rotation operator for PSEGs). So we were able to bypass all of the spit and bailing wire and create a single application to convert PDF and PS directly to the proper set of rotated PSEG files.

The critical issues for this tool where 1) convet with LZW compress (no data loss), 2) provide alpha channel data based on color (white in this case is white), 3) emit a series of TIF files (rotated at 0, 90, 180 and 270), and 4) emit a PDF with four pages having the same rotations as in #3. After some work I was able to create a tool to handle the AFP conversions for images and combine this with some of our existing technology to create a conversion product.

We gave them this tool, set up their hot folders, etc. and now they are starting to use it. Since we understand this entire process end-to-end now we are able to give them much better support than their other vendor. For example, they called up and said "the transparency is not working for this PDF". It turned out their other AFP application was using the wrong version and failed to emit transparency (this is hard to imagine for a mature product). Now they are calling us about all sorts of AFP problems...

So it occurs to me that they can't be the only ones having these problems and I start to sketch out an AFP product to help them.

Whate else makes AFP more interesting than PDF...

Historically it appears that APF constructs such as text positioning and images were much more closely tied to the resolution of the device. Early devices were 240 dpi with single on/off pixel resolution. It was not until the introduction of GOCA, for example, that true arbitrary text positioning became possible.

Modern AFP devices today have much higher resolution (360/720 dpi) and color. AFP color also supports a fixed OCA space containing what were probably single highlight colors, e.g., there is the notion of RED and BLUE with separate, non-CMYK/non-RGB/... color. These probably came into play when highlight color machines were popular in the 1990s.

I believe that early AFP was designed for speed over portability given the notions of device resolution bitmap images and raster fonts. All the RIP had to do was move bits around. However, as PDF and PostScript began to encroach in the AFP world these notions were sacrificed.

What is not discussed with AFP is RIP performance. The reason, I think, is that historically jobs are effectively RIPed by the AFP producer: fonts are raster and any images that were used were supplied as "ready to image" in the proper device resolution.

However, with GOCA the printing engine now has to do the same work as a PostScript or PDF RIP. (Further I believe that PDF and PS images can be embedded in MO:DCA or IOCA somehow - how I don't know yet - leading to potential future RIP performance issues).

AFP is not as "smoothly consistent" as PDF. For example, transparency masks appear to work with certain types of image compression but not others. There are a myriad of image compression options but each Function Set only supports certain types in certain situations. These issues are laid out in the various manuals but their existence does not make life easier.

There are also device issues. For example, certain devices cannot handle AFP files with mixed image resolutions.

On the other hand AFP got the notion of external job resources right. Like PPML or VDX (which I was personally involved with for a while during its birth) there is the notion of external assets referenced in a job. Assets can be attached to the job or called out from a pool on the print device. I would imagine that there is a lot of IBM software to support managing this - though I am not completely certain of this because I recall overhearing some comments to the opposite a few years ago. (Lexigraph sells a large, powerful system for managing RIPed assets call RMX.)

All this said if you take a step back from AFP you run into the next set of issues: tool sets. The PS/PDF world has long had Photoshop, Illustrator, etc. to provide a means to manipulate images, vector art, and so on. While there are many "mail merge" type tools for AFP there seems to be a significant lacking in this area which is why I got involved...

A little AFP background...

I don't know the full history of AFP but mostly it stems from the IBM 3800 printer days - basically this was one of the first laser printers for industrial use (another being the Xerox 9700). (In those days a "fuser-wrap" paper jam on the 9700 required an 18" crescent wrench to fix - but I digress.)

The most current information available for AFP, and, in particular, color AFP can be found at Output Links. This site contains most of the documentation you will need to understand to deal with AFP - though even "modern" AFP contains elements which I cannot find direct documentation for, e.g., IM Images.

From the perspective of a programmer or technician AFP is very different than PostScript or PDF. First and foremost AFP is record based. All of the commands and images are fit into variable length records up to 32K in length. Second, AFP uses a "wrapper model" to support extensions, i.e., an AFP X'5A' record "wraps" sub elements in their respective sub-records. So, for example, there is a sub language of records to describe images called IOCA. At the top level an AFP X'5A' record may contain multiple IOCA image sub-records.

To make life a little simpler for anyone following this have broken the AFP structure down below:

Image - AFP uses a sub-language called IOCA to describe images. Basically this is like image descriptions in PDF or PostScript - you have various color spaces (CMYK, RGB, LAB, ...), profiles, transparency masks, and the like.

Vector - AFP uses a sub-language called GOCA to describe this. GOCA has strokes, fills, winding, etc. along with full color specification.

Text - Things are a little more interesting here. AFP supports a variety of font types - some modern and some not. On the modern side there is support of Unicode and OpenType. On the not so modern side there are bitmap image fonts. To further complicate things there are multiple notions for placing characters on the page.

Text can be place via traditional line-printer-like commands, via PTOCA (Presentation Text Objects), or via GOCA. Of course, each of these models works differently.

The biggest difference between AFP and something like PDF is that characters cannot be directly and simply "outlined" nor "rotated arbitrarily". While you can "do" all the same things in AFP as you can in PDF - it can be (much) more complex to accomplish.

Another important issue is printer capability. All color AFP devices are designated with "Function Set 45". There are older, less capable printers which can do simply black and white images, and those with even less ability. We won't consider those other than Function Set 45 here.

There are many commercial tools to create AFP from most of the major mainframe-type software vendors. Some vendors support both PDF-type and AFP-type languages.

IPDS - This is a relative of AFP that is used by many high-speed inkjet devices. While the language is different IPDS supports AFP IOCA images so anything discussed here related to IOCA also applies to IPDS.

The road to being an AFP Outsider...

Since blog sites don't have nice neat ways to create categories I have created this blog to track my thoughts about AFP. AFP (Advanced Function Presentation/Print) was created by IBM for printing. It is being dragged into the 21st century as a color print medium. This blog is to relate my experience in creating an AFP product. (There is a companion blog at The PDF Outsider discussing my feelings about PDF.) This is also linked to my The "Lone Wolf" Graphic Arts Technologist blog.

I am applying my knowledge of PDF and color to AFP.

So why will I be the AFP Outsider?

Primarily because I don't prescribe to the associated AFP dogma, I tell customers the truth, and vendors of AFP products mostly don't like that.

When my customers have problems with AFP and AFP printers I want to solve them irrespective of any associated dogma.

I will document my journey here (which has only just begun since the beginning of 2010).

This blog is Copyright (C) Todd R. Kueny, Sr.