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...