The Transparency Flattening Disaster / PDF/X

Whenever overlapping objects using transparency are rendered, the resulting colors must be calculated from all input colors. This can happen in two different situations: one when the PDF is output on a monitor or in print, and the other when it is converted into a result PDF that does not use transparency (transparency flattening).

In the first case, calculations occur on a pixel-by-pixel basis within the resolution of the output device and in its color space. That process can be complex but is mathematically well-defined in the PDF Specification.

The second case is quite different: in this instance, the result is a transparency flattened PDF file. A straightforward method, similar to the first case, would be to convert the entire page – or at least all areas utilizing transparency – into images. However, doing this on the entire page either results in very large files or degrades quality. If the engine would just rasterize the areas that use transparency, visible borders would appear between flattened and non-flattened areas. Therefore, an advanced transparency flattening engine aims to avoid rasterization and preserve as many vector objects as possible, often creating new vector objects when the original objects partially overlap. This process is much more complex than what happens on an output device and requires the flattening engine to decide whether it is better to rasterize in smart ways to limit complexity or to create new objects.

Here is a very simple example illustrating how new objects are created. In this simple example six new objects are derived from three original objects.

Input file: 0.5 transparent blue circle in front of 0.5 transparent yellow triangle in front of red square

Result of transparency flattening: the red square is kept, the two other objects are converted into 6 new objects, one for each color

In a design PDF that extensively uses transparency, the result can have several thousand new objects.

In other words, flattening of transparency-rich pages will result in either a fully rasterized area or a much more complex internal structure. The latter will degrade rendering performance, complicate preflight or color conversions, and similar processes.

In conclusion, we can state that transparency flattening in a PDF file should always be avoided, and transparency calculations should only happen in the output device.

Unfortunately, there are situations where something or someone forces you to flatten transparency. For instance, PDF/X-1a or PDF/X-3 do not support transparency because, when they were published (at the beginning of this century), transparency was not yet defined. If someone forces you to convert to one of these standards, you have to flatten. Since PDF/X-4 is the first PDF standard that allows for transparency, earlier standards should not be used.

Data loss

But introducing complexity is not all. When flattening derives new objects from originals (vector or images), information is lost:

The most obvious case is text. Characters are typically converted into outlined vector objects (or images), so that you can no longer copy text from the PDF, search for it, or use text-to-speech functionality (unless OCR is applied to the result).

All object level metadata that is associated with e.g. an image will no longer be available if that image is converted into a new image due to transparency flattening.

Markers in the content stream that are used to associate page objects with other structures – mainly tagging for accessibility, layers and bookmarks – will no longer work because maintaining these markers in the content stream during transparency flattening is impossible.

Partial Transparency Flattening / Processing Steps

Losing tagging and bookmarks is not ideal but may be acceptable for PDFs intended for printing. But it is usually even worse for layers. Layers are the building blocks of the Processing Steps standard. Since the markers (in the content stream) are removed during transparency flattening, page objects are no longer associated with the layers (as layers are defined on the document level). As a result, you can still see the layers in the document using a viewer, but since the connection to the objects on the page is broken, they are essentially useless.

Processing Steps files, which identify a lot of information for post-print operations using layers, become useless after transparency flattening. For example, cut lines are merged with other page content.

Partial help

There is a solution for the Processing Steps problem in pdfToolbox 16, though. The new version of our software allows for partial flattening: The built-in transparency flattener now allows you to filter out objects from the input file, e.g. all objects on a Processing Steps layer, flatten the remaining objects, and then place the filtered objects back on top of the pages. Especially for Processing Steps, where all objects on these layers need to be on top of the page content and shall not have transparency anyway, this is a very valid approach.

Let us have a look at one of the Processing Steps sample files:

1. Original with working layers
A few objects use transparency. Content can be separated using layers and their visibility can be changed interactively.

2. Result after normal transparency flattening, the layers no longer work

3. Result with pdfToolbox 16 transparency flattening – Processing Steps objects remain untouched, layers still work – but the PDF does not use transparency anymore