"The excellence of every art is its intensity, capable of making all disagreables evaporate from their being in close relationship with Beauty and Truth."

(John Keats)

The poet John Keats knew. He knew that the key to an excellent, artful solution was making disagreeables disappear. His thoughts on truth and beauty culminate with the last two lines of his Ode to a Grecian Urn: 

'Beauty is truth, truth beauty,'--That is all Ye know of earth, and all ye need to know.

Print service providers--in-house or within service bureaus--are familiar with object containers and the problems they can pose for production printers. Some of the object containers a printer might see during a regular workday include graphics, photos, logos and charts. They add color and break up the text. They add value to the presentation and make the document more comprehensible to the consumer.

As to how to work with object containers, IBM tells us:

Object containers are used to carry non-Object Content Architecture (OCA) objects in an Advanced Function Presentation (AFP) data stream. Some such objects are Graphics Interchange Format (GIF) and Tagged Image File Format (TIFF) images.

These non-OCA objects can be wrapped or unwrapped.

• Wrapped objects are carried in a Mixed Object Data Content Architecture (MO:DCA) envelope called an object container.

• Unwrapped objects are unaltered from their original form. If the object is to be carried in MO:DCA resource groups and interchanged, it must be wrapped.

Object containers, even though they contain non-OCA objects, are similar to other AFP resources in these ways:

• They can be mapped. A mapped resource is downloaded once per spooled file, irrespective of the number of times the resource is referenced within the spooled file.

• They can be included on a page.

• They can be captured in the printer.

Using object containers has several benefits:

• You can reference several types of MO:DCA objects in a spooled file without having to include them in an overlay or page segment. These image types are image data, bar code data and graphics data.

• You can scale and rotate these objects. With page segments and overlays, you need to create one copy of the object in each orientation needed.

• You can include images larger than 16 MB in your output. If an image exceeds 16 MB, the image cannot be stored as a page segment object.

• Print applications can specify the use of non-OCA objects which refer to other non-OCA objects, such as color mapping tables (which are printer-resident). These are called secondary resources.

• Applications can use color objects with Intelligent Printer Data Stream (IPDS) printers.

Note:

Print Services Facility (PSF) does not check an object container's contents. Therefore, it is up to the user to verify that the printer can handle the type of data in the object container. 

The bold part of that is mine: it is up to the user to make sure that the object containers contain elements that are printable and don't seize up your printer, flood your print queue with too much data and/or otherwise slow down or interrupt your process and your workflow.

It's just one of about 82 things that can go wrong when you are in production print, but at the end of the day, do you really need another thing that can go wrong? I don't think so. So, just when you bring carry-on baggage with you on an airplane, object containers need to be examined lest they contain any nasty hidden surprises.

And object containers are tricky. At their dreadful worst, they can clutch the printer and actually destroy the hardware over time. It's definitely something you want to think about.

Some of our competitors in the print preparation process convert all the objects in an object container to PDF. Sometimes, because the target printer can't process the contained object, they have to rasterize the data in order to keep the image nice and clean: in the print world this is OK, I guess, because the image is rendered nicely on the page. Job number one is to get the object in print. But the data is gone. That could have consequences.

For example, if you tried to convert it to PDF/UA to have the Acrobat reader audibly read the document to you, you might have a problem. The reader could get to the image and just say "Image" (or you can use a metadata tag to specify the content of the image). 

The approach of Compart is different. We don't transform the data directly into PDF; instead, we have our own proprietary format that keeps the components (what we call Docponents) intact. At that point we can output the data stream as PDF, PDF/UA, HTML5, IPDS, or AFP, PCL or what have you.

The key thing is that we keep the data and objects intact. We keep the metadata intact, too, but that is a story for another time. We're generally a bit more gentle on your hardware, which of course is a capital investment, and we make your life more easy.

To put it in the term used by John Keats, we render the disagreeable agreeable.