# pdfx , trim size and margins

I'm using scrbook with forced margins and pdfx to produce PDF/X-1a compliant documents for the publisher.

pdfx resizes the document and puts the trimed document in the bottom left corner. I'm not sure how the margins are kept or how the publisher will trim the printed document eventually.

Can you shed some light on this subject?

Here is a simple example of what I'm doing:

\documentclass[paper=6in:9in,pagesize=pdftex,
headinclude=on,footinclude=on,11pt]{scrbook}
\areaset[0.50in]{4.5in}{8in}

\usepackage{lipsum}
\usepackage[x-1a]{pdfx}

\begin{document}

\chapter{My first chapter}

\section{A section here}

\lipsum

\chapter{My second chapter}

\end{document}

• I can't directly answer your question, but I can tell you that pdfx is a rather fragile package. It can even break depending on your local timezone (seriously). I wouldn't be surprised if it were incompatible with koma-script/scrbook. See what you get if you use the standard latex classes. – Lev Bishop May 2 '11 at 6:19
• @Lev: thanks for the input. Do you know any other way to produce PDF/X-1a:2001 compatible documents? – ℝaphink May 2 '11 at 6:34
• I have heard that ConTeXt has very good support for PDF/X, but I have no personal experience. In the past I've copied pdfx into my local directory and edited it to be compatible with the particular document (and timezone, phase of the moon, etc), but I woulnd't call this a good solution. – Lev Bishop May 2 '11 at 6:37
• Is switching to ConTeXt straightforward? Is Koma-Script compatible with ConTeXt ? – ℝaphink May 2 '11 at 6:39
• Another possible approach is to do nothing special with tex, and then use a tool like Adobe Acrobat Professional to try to fix up the results into a PDF/X document. Acrobat certainly has a bunch of features for solving various issues relating to this, but I don't know how easy this is or whether it would actually work. – Lev Bishop May 14 '11 at 4:44

## 2 Answers

I've only had experience producing PDF/A documents, but the issues should be similar. What I've found is that the best approach is to forget about the pdfx package, and convert the normal output of pdftex to a conforming document using ghostscript. See the documentation. Among other things, make sure you use a modified version of PDFX_def.ps and include an ICC profile.

• I highly agree that this should be handled external. One thing which seems to be important is to use CMYK colors, so I would say to load xcolor with the appropriate options to avoid conversation issues later. – Martin Scharrer Jul 4 '11 at 1:49

My 2 cents to the question. I had the same problem with a thesis template, but I solved this issue by loading the geometry package (which is required in my document to get a B5 paper size) after the pdfx package and I had to do it in the template class. It may be useful to load a color profile (e.g. FOGRA39) in the metadata. See the pdfx manual for details.

Compiling with pdflatex failed because of the § symbol, since the command \S has no corresponding ASCII code. I solved by using \textsection instead of \S.

I also had problems with pictures: it seems that .png files have no CYMK colors and pictures appeared as black rectangles, so I converted them in .pdf.

Anyway a compliance check with an external software, and probably its conversion tool, will be necessary.

Minor issue: the € symbol of the eurosym package has a glyph that may fail the compliance check to the PDF/X standard. I solved by using the € symbol available on the keyboard (as I did to write this answer).