I am currently typesetting a book in ConTeXt and have been wondering how to get correct PDF Boxes when creating a PDF/X file for printing. According to a page on Context Garden this should be possible with current versions (I'm using 2017.04.27); alas, I noticed that especially the TrimBox doesn't seem to be exported correctly.

Please consider this MWE:




\input tufte


(Note that I used these definitions for the parameters cropoffset, trimoffset and bleedoffset just for testing.) The file that is created when running context looks like this, when opened in Acrobat Pro:

PDF file created by ConTeXt

Notice the green line: This is only visible, when activating "Show art, trim and bleed boxes" in the preferences and represents the TrimBox (normally equal to the CropBox). This should be showing the actual cropped page size (A4). In addition, although largely irrelevant in actual printing, there should also be the BleedBox (page size plus bleed), but there doesn't seem to be one in this PDF. What's more, the parameters specified don't seem to have any effect, at all. What I'm seeing is the paper size SRA4 give by the command \setuppapersize[A4][SRA4].

In contrast, here's a PDF file created by Adobe InDesign:

PDF file created by Adobe InDesign

Notice again the green line: This time it is correctly positioned (A4) and there's also a blue line that represents the BleedBox.

Can anyone offer any help? Is this a bug? Or am I missing some switch?

All help would be much appreciated.

  • 1
    You have to \setupinteractionscreen[width=max,height=max] to your document the enable the offset calculations. May 21, 2017 at 13:31
  • Thank you for the suggestion. I just tried it and that, indeed, changes a few things: Now, the parameters at least do have some effect at all. However, I also noticed that they do not behave as expected: For some reason, they have to be set to negative values to be applied. Will investigate further...
    – Marcus C.
    May 21, 2017 at 13:45
  • 1
    You have to set the differences from one offset to another and not the total value (cropoffset -> trimoffset -> bleedoffset -> artoffset). May 21, 2017 at 14:10
  • Hmm, yeak, I was kinda expecting that. But the values suggested on ContextGarden don't seem to work, as positive values seem to be completely ignored.
    – Marcus C.
    May 21, 2017 at 14:13
  • I would like to ask the same question about LaTeX and the crop package (which does not set TrimBox) -- should it be a spearate question?
    – eudoxos
    Jun 8, 2017 at 14:22

1 Answer 1


Sorry for answering that question myself, but after having done some extensive research and with the help of @metafox (see the comments above, thank you very much!) I found out how to come pretty close to a PDF file with correct PDF Boxes. And I suspect, the last missing piece might be a bug in the current version (I'm using 2017.04.27), so even that might become obsolete sometime in the future.

A few observations:

  • The parameter \setupinteractionscreen[width=max,height=max] is necessary for the calculations to be enabled.
  • \setupbackend[format=PDF/X-1a:2001], on the other hand, doesn't seem to have any effect. Nice to have, when exporting a PDF file for printing, of course, but not sigificant for the box calculations.
  • The media size (i.e. the size of the MediaBox) is taken from the second parameter in the command \setuppapersize. I'm not sure, if that's been a good choice, but anyway: It's the way it's currently done.
  • The first parameter cropoffset specifies the difference in size between the MediaBox and the CropBox. As it is usually suggested that the CropBox should be equal to the TrimBox, this might as well be set to something other than 0, so that MediaBox becomes the biggest "box". However, looking at how the Adobe software handles this (please refer to my original questions), I guess it is expected that the MediaBox and the CropBox are identical. So, I'll set this parameter to 0mm.
  • Next, the parameter trimoffset specifies the difference between the CropBox and the TrimBox. For achieving correct bleed, this is essential. However, in contrast to the example given on Context Garden, this parameter seems to be completely ignored, if it is positive. So, to get any bleed at all, I'll set this to -3mm (the value most often used here in Europe).
  • The parameter bleedoffset, then, gives the difference between the TrimBox and the BleedBox. And here's a weirdness: Setting this to -3mm yields a BleedBox that's smaller than the TrimBox, which is obviously not correct. The value 0mm yields the same size as the TrimBox, which is unusable, as well. Choosing 6mm for bleedoffset yields a BleedBox that's bigger than the MediaBox, which doesn't make any sense at all (and should probably be corrected by the compiler, but that's another story).
    So, taking all this into account: The correct value should be 3mm. However, trying this exact value yields a PDF file that doesn't have a BleedBox at all. This got me stumped for a while and I suspect it is a bug in the current version. But it is, after all, the only way for achieving something closely resembling the output by Adobe InDesign. And, while this might not be standards-compliant, it should work well in practice.

So, here's the complete MWE, just in case anybody else needs it:






\input tufte


Except for the missing BleedBox, the resulting PDF file is now equivalent to the one created by InDesign.

  • 1
    Nice answer! You should definitely bring this topic up on the mailing list ([email protected]). There seems to be room for improvement. May 21, 2017 at 21:46
  • Thank you very much, Marcus! Since I inquired several times about those box issues, I’m glad you found a partial solution. I copied your answer to the Wiki page: wiki.contextgarden.net/PDF_Boxes
    – Hraban
    Jun 14, 2017 at 8:13
  • A late response... The novel document class (LuaLaTeX only) is intended for fiction, rather than academic papers. It has PDF/X built in (does not rely on other packages), and it does provide the correct bleed box for cover artwork (not interiors). It has been used more than once for submission to print-on-demand.
    – user139954
    Apr 16, 2018 at 3:29
  • Is this possible to fix this issue in LaTeX (MikTeX 2.9)??
    – MadyYuvi
    Sep 26, 2018 at 9:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .