Nick Hodge's Blog

Visit the new InDesign Prepress Section: Adobe InDesign: Prepress Techniques

Generating Composite, Trapped PDF from InDesign

Well created, Composite PDFs are the most commonly requested format for printers in this part of the world. So, how exactly do you generate a composite, trapped PDF?

InDesign 1.5.x and 2.0.x have support for Application Built-in trapping. The trapping engine inside InDesign matches many of the features of Adobe’s InRIP trapping engine; usually found in higher end RIPs from Creo, Heidelberg, Agfa etc.

Trapping is the process of changing the shapes of certain objects in a printed output to reflect the way the ink will run when printed. Each of the inks are laid down on the paper by different cylinders of the press. As the paper (substrate) are impressed by these cylinders, there might be a misregistration – where the inks don’t quite line up. In this instance, the plates contain extra overprinted areas of dots to cover up any unsightly gaps that may be left in the final output.

Highend PDF workflows today are bedevilled by the “Who is trapping this?” question. In controlled workflows, this is easy to coordinate. Prepress know which press a job is running on, and apply some visual checks on the job and may make trapping changes to the source file prior to output. However, when there is a hand-off to an unknown press and printing environment, the creator will not know the press conditions. Today’s digital workflows largely assume that the final RIP (imagesetter/platesetter) will trap the document.

In some workflows, this trust may not be enough. We need to make composite PDFs for onscreen viewing, simplicity and size; yet trap them so there are no ugly white patches at print time.

With InDesign 1.5 and 2.0, the Adobe trapping engine takes InDesign created object (text and vector objects) and traps them to placed images, text and vector shapes. InDesign does not trap placed PDF or EPS objects. These are assumed to be trapped. InRIP trapping solutions will trap the entire page stream. To use Adobe In-RIP Trapping, you must use In-RIP separations. Built-in trapping limits trap widths to 4 points, regardless of the value you enter for the trap widths. For larger trap widths, you will need to use Adobe In-RIP Trapping.

From QuarkXpress, the trapping information as setup by the Trap palette only comes into play when printing separations. With QuarkXpress 4.0 and above, overprinting and knockouts as set by the palette are retained in composite Postscript output. Saving Pages as EPS from QuarkXpress 3.32 and higher does result in overprints/knockouts being retained. (see QuarkXpress, PDF, Trapping and Overprint)

InDesign 1.5.x and 2.0 preserve knockout/overprint attributes in Composite Postscript output. As you would expect, Adobe’s Applicaton Built-In trapping works when printing separations.

Back to the topic at hand: A significant workflow difference with InDesign is that it can also apply Application Built-In traps when printing InRIP separations.

What are InRIP separations? Essentially, programs like InDesign send composite Postscript to the RIP with some extra commands telling the RIP to take a completed page and produce n-plates based on the colourants on the page. For simple process jobs, this would result in a page each for C, M, Y and K.

The implementation of the Postscript showpage and copypage operators have the capability of producing pages for each colourant. If the output device doesn’t have this colourant, then the alternativeSpace colourant is used; failing this, DeviceCMYK is used. There is a Postscript engine inside the Distiller, and it yields DeviceCMYK colourant output.

Acrobat Distiller has a Postscript engine inside: what does it do with InRIP separation-marked Postscript? Distiller 4.0x and 5.0.x ignore the operators for producing pages for each colourant, and produce a composite PDF. The colours stay as CMYK (or spot colours if used) if the Distiller options are left to “Leave Colour Unchanged”

Now InDesign 1.5.x and 2.0.x allow you to apply Application Built-in trapping to the composite Postscript when printing as InRIP separations. Yes, I know its a little mind bending! If you then send the resulting Postscript to Acrobat Distiller, the Distiller discards the commands to separate, but it does retain the extra “trapping” Postscript commands. The final PDF holds these trap commands, and they can be viewed in Acrobat 5.0 by turning on Overprint Preview.

The final outcome is a Composite, Trapped PDF.

Steps

1. Ensure that your Trapping settings are correct. Please consult the InDesign CS Printing Guide, the manual and your Prepress/Printer before assuming the defaults are correct.

2. Assign a Trap Style to the page. In this instance, I am using InDesign’s [Default] Trap style as viewed above.

3. Here is the File>Print dialog box. In Output, Color is set to In-RIP Separations, and Trapping is set to Application Built-In

4. To make it easier to use the same settings on the next document, you can save a Printer Style for later use.

5. This is the source document in InDesign 2.0

6. The final PDF inside of Acrobat 5.0, (available here: Example CompositeTrapped PDF)with Overprint Preview turned on. The darker areas around the type etc. display where overprinted strokes have been applied based on the inking requirements.

7. Using Quite Revealing from Quite Software, I can also reveal the overprinted strokes separately.

For more information about Trapping, and specifically the Adobe trapping engine:

Adobe Trapping Technology (white paper)

Adobe In-RIP Trapping Workflow

How to Trap Using Adobe Trapping Technologies

Thanks to Steve Amerige, Matt Phillips for their assistance with some of the finer details.

Fixed up two of the issues in regards into cross-browser compatibility with CSS positioning. It seems that Netscape and Opera take the width property as a starting point, then add the padding and border to this width; whereas MSIE reduces the content by these amounts. The end result is that each of the browsers rendered the page differently from the same content. On the front page, the main content box that this text appears in was about 12 pixels wider and overshot the edge of the topmost image.

The first possible way of solving this is to write some client-side Javascript to change using document.write or leverage some preexisting code in the mungenetengine. This code permits me to have PHP interpretted from within the MungenetCMS and rendering content conditionally. I look at the browser and render the CSS entry differently for the different browsers.

As a side result of this, Netscape 6 and Opera 6 users will also see PNG-24 graphics with transparency (check out the menu text to the left between the two browsers.)

In another subtle way, this is another reason to use server-side scripting and dynamically generated content. All it took to implement were some extra content holders with PHP to read the $HTTP_USER_AGENT.

Netscape seems stricter in its interpretation of the CSS positioning. For instance, in the original navigation box to the left I had placed a height: 430px; command. MSIE ignored this when the content grew larger than 430 pixels. Netscape didn’t expand the box and closed the box (resulting in a bogus looking clip). This is an advertisement for looking at sites with more than one browser to ensure you are writing clean code.

Another issue is that Opera seems to render my footer very differently and interpreting the offset from the content area wrong. Netscape and MSIE get it correct. So I’ve written a visible: hidden; for Opera. Sorry, no footers for Opera.

Small clean ups on the CSS to further remove tables, and reduce the size of the CSS download. Apart from some mis-written URLs (which I think are valid according to RFC1738) this site also passes the W3C Validation for HTML4.01 Transitional.

From what I can ascertain, MSIE is wrong in its calculation of ‘content width’ and NS6 and Opera are correct. (If you are really, really interested in reading specification documents: W3C on CSS content width) Either way, it’s still the designer’s responsibility to ignore the incompatibility (and upset Netscape/Opera users? wrong answer) or workaround/fix using server or client side scripting (correct answer).

---

Update: Opera 7 correctly renders the CSS margins and relative positioning. Fixed my code to catch this, server side. This fix breaks old Opera; but I suspect Opera users will upgrade. Safari seems to be close, at least in their build 48. From what I have read, it will get way better in the release version.

The database

There are three basic tables in the MySQL database. One contains content, and referenced by mcid. The second contains any binary content (images, PDFs) and is referenced by an miid The final contains sections referenced by msid, which are a mechanism for organising and classifying content and images.

Around these three tables live some utility tables that contain basic logging information (a simple page count per fragment) and caching. Each page, when first rendered, is cached to a separate table. This enables faster response on the second and subsequent hits. To ensure that only current pages are cached, there is a simple cachetree implemented such that when a change or deletion to a record is made, the cache is pruned. (the page cache is presently disabled)

These sections provide the underlying hierachical structure of the site. This structure is tightly bound to the navigation through the site. As this is in the database, it is very easy to change the underlying navigation structure without changing how individual pieces of content are referenced. Usually, the structure is defined as a folder hierachy on the server. As soon as you start moving the folders around, the references from one piece of content to another breaks – forcing a mass update of the site. External search engines that may have the links stored in their database get 404 style errors. In the mungenetengine, each content, image and section is referenced individually without relationship to its place in the navigation structure.

Each fragment of content or image belongs to a section. These sections are the hierarchy behind the site – so each section can belong to another section, and a particular section can have multiple child-sections. A section can only have one parent. As you move to another section or page within another section, the mungenetengine (renamed to mne.php) can generate a navigation fragment; which is a template driven hierarchy containing links to the parent section, sibling content pages or sections, and any children.

In fact, each content entry is just a fragment of html. A whole page may actually comprise of other referenced contents elements, each inserted into the final html that you seen in the browser. The process of building one page from another is a process called templating. Its not as simple as one page referencing another; this process is recursive – one page refers to another until the final page is built. The concept here is to only enter data only once into the database. Each content can insert other fragments (or images) into the html output.

There are different types of content fragments. For instance, one is an external link – these contents are resolved, and wrapped into an HREF style link.

Images are in fact binary objects. They are wrapped into the final html – except they refer back to the mungenetengine – which grabs the images out of the database and serves them up. html fragments that are generated automatically add the width/height, alts and hrefs normally associated with images – if they are in the database. PDFs and other non-image content can be linked to so the user can download them, or embedded into the HTML fragment.

SWF and SVG can also be stored in the database. When rendering out these elements, the engine generates object embed tags. The width and height are not read from either format as yet. Whilst it is possible to read the ‘twips’ from a SWF, it seems overly complex to do – just yet

The engine can also generate what are known as breadcrumbs (next and previous links) — this is easy as the structure and relationship between objects are known and map to the navigation

PHP, the server side scripting language, munges the data together from the MySQL database and serves it up. As at early February 2003 this code is about 1870 lines long. I am testing this on WindowsXP and transferring it here to a Linux box for production. I really only have a choice of three server side scripting systems (PHP, Perl or Python). Learning PHP has been a great experience.

The next stage is to transfer the experience here into using a better language that has more object orientation. I have chosen Python as the langauge to accomplish this task. How long this takes, only time will tell!