Print submission (crop marks, PDF)

When a LaTeX submission goes wrong, the cause is usually nothing to do with typesetting. It compiles perfectly on your machine, and arXiv's build fails. The journal office writes back that the fonts are not embedded. The printer sends it straight back for want of crop marks and bleed. None of this touches the quality of the writing; you have simply run into the rules the receiving end needs in order to process files automatically. This page walks through what you can check for yourself before pressing send: the requirements arXiv states in writing, the package manifest \listfiles produces, font-embedding checks with pdffonts, flattening a manuscript with latexpand, arlatex and bundledoc, anonymising for double-blind review, and PDF/X for a commercial printer.

What to send when you submit LaTeX to arXiv

You send the source, not a PDF. arXiv rebuilds the .tex it receives on its own TeX Live installation, so what you upload is “a set of files that builds on their machine”. arXiv's own submission help is explicit on several points. For a file named foo.tex, do not include the associated auxiliary files — foo.aux, foo.log, foo.toc, foo.lot, foo.lof, foo.dvi, foo.pdf. Index (.ind) and processed BibTeX (.bbl) files are the exception and should be included; further, the name of the .bbl must match the name of the main .tex file or the references will not be processed. And: they do not provide any packages beyond what the TeX Live system provides — so a society's house class file, or a style file you have modified, has to travel with your submission.

FileInclude?Why
.texyesthe source itself; the build always runs from the root of the submission
.bblyesan explicit exception; its name must match the main .tex
.indyesthe index file is the same kind of exception as .bbl
.sty / .clsonly if home-made or modifiedanything not in TeX Live will not be found at the other end
.aux / .log / .tocnothey are regenerated by the rebuild and must not be shipped
.pdf / .dvinothe output itself — not to be confused with a PDF used as a figure

Figure formats are tied to the engine as well. arXiv's help separates them plainly: plain TeX and LaTeX in DVI mode take PostScript only (.ps or .eps), while LaTeX in PDF mode takes .pdf, .png and .jpg — and it states outright that arXiv does not perform “on the fly” figure file conversion during TeX processing. Send a mixture of .eps and .pdf and the build falls over. One more thing: compilation always runs from the root of the submission directory, so even if your main file sits in a subdirectory, check that a relative path such as \includegraphics{figs/plot} resolves from the root. Absolute paths will not work.

The usual reasons automated processing fails

Most failures come down to file names, paths, and something left behind. arXiv publishes a list of common mistakes that cause automated processing to fail, and what appears there is almost entirely one-line fixes. You wrote your own style or macro file (or modified a standard one) and forgot to include it. You used an absolute path where a relative one was needed. You put a space or a special character in a file name — these are converted to underscores on upload, so \includegraphics{my figure} loses its target the moment you submit. Your .bbl was produced by a BibLaTeX version that does not match arXiv's TeX Live. You are still loading an old dvips-era style file such as epsbox.sty. You mixed figure formats. And you used an unprotected macro inside a caption — write \protect\cite{}.

What all of these have in common is that an assumption that only holds on your own machine has survived somewhere. So the most effective countermeasure is not a tool but a procedure: make a fresh directory, copy into it only the files you intend to send, and confirm that the build succeeds from scratch with no intermediate files present. That single step exposes most absolute paths, most forgotten includes, and most builds that only worked because of a stale .aux. Submitting a last-minute change without testing it is, incidentally, another failure arXiv names explicitly.

terminal
# build the submission the way the other end will
mkdir -p /tmp/submit && cp paper.tex refs.bbl mystyle.sty figs/*.pdf /tmp/submit/
cd /tmp/submit && pdflatex paper.tex   # must succeed with no .aux present

# a caption calling a macro needs \protect:
%   \caption{Following the method of \protect\cite{knuth1984}}
# and a file name with a space will be renamed on upload:
%   my figure.pdf  ->  my_figure.pdf

Recording what you built with: \listfiles

Add the single line \listfiles before \documentclass and the tail of the .log will carry every file that was loaded, with its version. The head of an actual run reads: article.cls 2023/05/17 v1.4n Standard LaTeX document class, amsmath.sty 2023/05/13 v2.17o AMS math features, hyperref.sty 2024-01-20 v7.01h Hypertext links for LaTeX. The list runs to dozens of lines, and it makes “it only breaks on their machine” dramatically easier to narrow down. Six months later, when an editor writes that they cannot reproduce your build, having that version table sitting in the log is a decisive advantage.

log
*File List*
 article.cls    2023/05/17 v1.4n Standard LaTeX document class
  size11.clo    2023/05/17 v1.4n Standard LaTeX file (size option)
 fontenc.sty    2021/04/29 v2.0v Standard LaTeX package
 amsmath.sty    2023/05/13 v2.17o AMS math features
graphicx.sty    2021/09/16 v1.2d Enhanced LaTeX Graphics (DPC,SPQR)
hyperref.sty    2024-01-20 v7.01h Hypertext links for LaTeX
 ***********

For a more rigorous version of the same idea, use the snapshot package. Add \usepackage{snapshot}, compile, and you get a .dep file beside your .tex whose contents are a declaration for reproducing the build: \RequireVersions{ ... } containing entries such as *{application}{pdfTeX} {0000/00/00 v1.40.26}, *{format} {LaTeX2e} {2023-11-01 v2.e} and *{class} {article} {2023/05/17 v1.4n} — engine, format, class and every package, in machine-readable form. That same .dep file becomes the input to bundledoc in the next section.

Checking font embedding with pdffonts, and why Type 3 is rejected

One command does it: pdffonts paper.pdf. This tool, part of poppler, lists every font the PDF uses on its own line, with its type (Type 1, Type 3, TrueType and so on), whether it is embedded (emb), subsetted (sub), and whether it carries a Unicode map (uni). For direct PDF submissions arXiv states that it “may reject PDF submissions because of non-standard, non-embedded fonts” and asks that “outline (TrueType/Type1) rather than bitmap (Type3) fonts are used”. Journal production guidelines say much the same, so the pass condition is simply this: every row must read yes under emb, and no row may read Type 3 under type.

terminal
$ pdffonts paper.pdf
name                                 type              encoding   emb sub uni object ID
------------------------------------ ----------------- ---------- --- --- --- ---------
NLRVKI+SFBX1440                      Type 1            Custom     yes yes yes      9  0
LLYCJX+CMMI10                        Type 1            Builtin    yes yes yes     11  0
JHYTSG+CMR10                         Type 1            Builtin    yes yes yes     12  0

$ pdffonts bitmap.pdf     # the same document forced onto bitmap fonts
F28                                  Type 3            Custom     yes no  no       4  0

The second listing above shows the nastiest part of this story. A Type 3 font is also emb yes. The bitmaps really are embedded in the PDF, so the question “are all your fonts embedded?” can be answered honestly with “yes”. The difference is over on the right, in the uni column, which reads no: with no Unicode map, that PDF cannot be searched or copied from. The first symptom is usually a reviewer who cannot search the text for a word. You can force this state in pdfTeX deliberately by emptying the font map with \pdfmapfile{} — which is another way of saying that a broken font-map configuration, or a figure pasted in from an old plotting tool that emits Type 3, will do it to you without a word.

The PDF version itself is sometimes part of the requirements. pdfTeX in TeX Live 2024 writes PDF 1.5 by default, which you can confirm in the PDF version: field of pdfinfo. To match a specified version, put the pdfTeX primitive \pdfminorversion=7 at the very top of the preamble, or, with current LaTeX, write \DocumentMetadata{pdfversion=1.7} before \documentclass. Measured, both produce PDF version: 1.7. Producing PDF/A itself belongs to another page; see the link below.

Flattening a split manuscript: latexpand, arlatex, bundledoc

Splitting a manuscript into one \input per chapter is pleasant to write but submission systems often want a single .tex. TeX Live ships three tools with three different aims. latexpand main.tex > flat.tex expands \input and \include into one flat .tex. arlatex --document=paper.tex intro.tex --outfile=selfcontained.tex stores the auxiliary files inside a single .tex by wrapping each in a filecontents* environment — in an actual run that output compiled straight through pdflatex. And bundledoc reads the .dep file produced by snapshot and packs the whole set of required files into a tar.gz.

terminal
# one flat .tex (latexpand 1.7.2); NOTE: comments are stripped by default
latexpand main.tex > flat.tex
latexpand --keep-comments main.tex > flat.tex   # keep them if you must

# one self-contained .tex carrying its own auxiliary files
arlatex --document=paper.tex intro.tex --outfile=selfcontained.tex

# a tar.gz of exactly what the document needs, excluding TeX Live itself
pdflatex paper.tex          # with \usepackage{snapshot} -> paper.dep
bundledoc --localonly --manifest=MANIFEST paper.dep
tar tzf paper.tar.gz
#   paper/
#   paper/intro.tex
#   paper/MANIFEST
#   paper/paper.tex

One behaviour here matters for anonymity too. latexpand removes comments by default. Its own manual says that by default it outputs a single LaTeX file containing no comment; to keep them you must pass --keep-comments explicitly. Turn that around and it says something uncomfortable: ship a raw .tex and every private note you wrote after a % goes with it. Memos along the lines of “this paragraph is aimed at reviewer 2” do end up in submitted files. bundledoc's --localonly follows the same instinct: it excludes everything that came from TeX Live and packs only what you wrote — which is exactly the shape of arXiv's rule that standard packages need not be included but your own files must be.

Anonymising for double-blind review: metadata and comments

Deleting the author's name from the body text is not enough. PDF metadata and source comments are two separate checks. Measured: \title and \author do not by themselves leak into the PDF metadata — pdfinfo reported Title: and Author: as empty, and the only things written were Creator: LaTeX with hyperref, Producer: pdfTeX-1.40.26 and the timestamps. The leak happens when you (or a template) write \hypersetup{pdfauthor={...}, pdftitle={...}}, at which point your real name appears in pdfinfo verbatim. Running pdfinfo anon.pdf and looking at the Author: field before you submit is enough to prevent it.

terminal
$ pdfinfo anon.pdf | head -6
Title:
Subject:
Keywords:
Author:
Creator:         LaTeX with hyperref
Producer:        pdfTeX-1.40.26

# strip your own margin notes out of the source you upload
latexpand main.tex > anon.tex      # comments removed by default

Society class files often ship an anonymous mode of their own — ACM's acmart, for instance, declares anonymous as a boolean class option (it is defined as a boolean key inside the class file and logs Using anonymous mode when switched on). Where one exists, use it: the class takes care not only of the author block but of acknowledgements, grant numbers and the handling of \thanks. If you must anonymise by hand, do not forget acknowledgements, funding numbers, self-citations (“in our earlier work [12]”) and the affiliation logo baked into a figure. Information that pdffonts and pdfinfo cannot find is, in the end, only found by reading the paper again yourself.

Submitting to a commercial printer: crop marks, bleed, PDF/X

A commercial printer wants three things a journal does not: crop marks showing where the sheet is trimmed, bleed so that colour reaches the edge cleanly, and usually a PDF/X file in CMYK with fonts fully embedded. For Western typesetting the crop package adds the marks (\usepackage[cam,center]{crop}). The proper digital tombow used in Japanese self-publishing are drawn by texjporg's gentombow, which takes a default 3 mm bleed and sets the PDF /TrimBox (finished size) and /BleedBox (including bleed). The tombow class option of jsclasses only draws tombow-like marks, so pair it with gentombow for a real submission. Bleed means extending edge-to-edge artwork about 3 mm past the trim line, so that a slight cutting variance leaves no white slivers.

PDF/X (X-1a, X-3, X-4) is the print counterpart of PDF/A: it requires CMYK (and spot) colour, fully embedded fonts, an output intent (ICC profile) for the press, and correct TrimBox/BleedBox (with CropBox unset and ArtBox forbidden). From LaTeX, the pdfx package produces it; \usepackage[x-1a]{pdfx} gives X-1a, which permits only CMYK and spot colours. Image resolution is generally aimed at 300–350 dpi, and the colour space is whatever the printer specifies. Finish by validating conformance with a tool such as veraPDF, and ultimately follow that printer's own submission specification — passing the standard does not cover the extra requirements each shop adds.

latex
% Western: crop marks from the crop package
\usepackage[cam,center]{crop}

% Japanese self-publishing: jsclasses option plus gentombow for real tombow
\documentclass[tombow]{jsarticle}

% PDF/X-1a output (CMYK and spot colours only)
\usepackage[x-1a]{pdfx}

The pre-flight checklist

  • Delete the intermediate files and rebuild from scratch in a clean directory. A stale .aux can hide a fault that would otherwise show.
  • Build once with \listfiles enabled and keep the file list from the end of the .log. A snapshot .dep file is better still.
  • Run pdffonts paper.pdf and confirm that every row says yes under emb and that no row says Type 3 under type.
  • Read Author: and Title: from pdfinfo paper.pdf. For double-blind they must be empty; check the PDF version matches what was asked for.
  • Include your own .sty and .cls files; leave out .aux, .log and .pdf. Include the .bbl, and make its name match the main .tex.
  • Match figure formats to the engine (.pdf / .png / .jpg for the PDF route, .eps for the DVI route) and check that relative paths resolve from the root.
  • If a single file is required, use latexpand (comments are removed by default); to ship the whole set, bundledoc --localonly.
  • For a printer, confirm crop marks and roughly 3 mm of bleed, correct TrimBox/BleedBox, and PDF/X output via pdfx.