How to format a CS conference or workshop paper in LaTeX

Every venue has its own instructions, and they always win. But the instructions follow a common pattern: a document class, a page limit, a particular shape of front matter, standard theorem environments and a bibliography style. Get these right and the paper looks like it belongs; get them wrong and it may be returned without review.

Start from the venue’s document class

The single most important rule is to use the class the venue gives you, unmodified. A class file (.cls) fixes the page size, margins, fonts, heading styles and front-matter layout. Widely used classes for computer science include:

TeX Live and MiKTeX already include the CTAN classes, so \documentclass{llncs} usually works out of the box. Check the version against the one the venue links to anyway. If you are starting from scratch, the template guide has a minimal article template and explains how to move it into a venue class.

Page limits

Read the limit carefully. Typical forms are “12 pages in LNCS format excluding references”, “15 pages plus an unlimited appendix that reviewers may ignore”, or “10 pages including everything”. A few rules of thumb:

• The limit applies to the PDF produced by the official class at its default settings. Measure your own output, not a page count from a different class.
• An appendix, if allowed, is for proofs and details a reviewer might want. The main text must stand on its own, with the key ideas of the proofs.
• Short papers and extended abstracts are not cut-down full papers: say what the result is, why it matters, and how the proof goes.

The front matter

Title, authors, affiliations, abstract and keywords go at the top, in the form the class expects. They differ more between classes than anything else, so copy the structure from the class’s sample file.

\documentclass{llncs}
\begin{document}
\title{Least Fixed Points of Continuous Maps on Streams}
\author{First Author\inst{1} \and Second Author\inst{2}}
\institute{University One, City, Country \email{first@example.org}
  \and University Two, City, Country}
\maketitle
\begin{abstract}
One paragraph: the problem, what you did, and the main result.
\keywords{Domain theory \and Streams \and Fixed points}
\end{abstract}

• Title. Specific and informative: say what you prove, not that you study something. Follow the venue’s capitalisation.
• Authors. Full names as you want them indexed, with ORCID identifiers if the class supports them. Agree the order before submitting.
• Abstract. Plain prose without citations, macros or displayed maths, because it is also pasted into the submission system and indexing services.
• Keywords and classification. Some classes require keywords, and ACM venues require CCS concepts generated from the ACM’s classification tool.

Structure of a theory paper

1. Introduction with the problem, why it matters, and a bulleted list of contributions with forward references to where each is proved.
2. Preliminaries: notation and the definitions you rely on, with citations for standard material.
3. Main results, one section per idea, with theorems stated precisely before they are proved.
4. Related work, comparing results rather than listing papers.
5. Conclusion and open problems, followed by references and any appendix.

Theorems, proofs and cross-references

Use theorem environments so numbering and formatting stay consistent. Some classes (llncs, acmart, LIPIcs) predefine theorem, lemma, definition and proof; with plain article, load amsthm and declare them yourself. Never number results by hand.

\begin{lemma}\label{lem:chain}
If $f$ is monotone then $(f^n(\bot))_{n}$ is an increasing chain.
\end{lemma}
\begin{proof}
By induction on $n$. \dots
\end{proof}
By \cref{lem:chain}, \dots

Label everything you refer to and use \ref or, better, \cref from the cleveref package, which writes “Lemma 3” for you. Load hyperref last (cleveref after it) unless the class already does, so references become clickable links in the PDF.

Notation and macros

Define notation once with \newcommand, for example \newcommand{\den}[1]{[\![#1]\!]} for semantic brackets, and use the macro everywhere. Changing notation late then takes one edit. Use \newcommand rather than \def, which silently overwrites existing commands, and never redefine commands the class uses. Keep your macros in a separate file and \input it; editors tend to combine files from several authors, so prefix any names likely to clash.

Figures, tables and algorithms

• Use vector graphics: PDF figures, or diagrams drawn in TikZ (pgf/TikZ, with tikz-cd for commutative diagrams). Bitmaps should be at least 300 dpi.
• Captions go below figures and above tables in most styles. Refer to every float from the text.
• For tables, booktabs rules (\toprule, \midrule, \bottomrule) and no vertical lines look far better than a grid.
• For pseudocode, use one package consistently, such as algorithm2e or algorithmicx, checking first that the class doesn’t forbid it.
• Make sure figures are readable in black and white and by colour-blind readers: vary line style and marker shape, not only colour.

The bibliography

Use BibTeX (or biblatex if the venue allows it) with the style the venue specifies: splncs04 for LNCS, ACM-Reference-Format for acmart, IEEEtran for IEEE, plainurl for LIPIcs. Don’t switch style to save space.

• Include DOIs. Most styles print them as links. doi.org resolves any DOI.
• Check entries copied from the web. Exported BibTeX is often inconsistent: abbreviated and full venue names mixed, missing pages, preprints cited when the published version exists. dblp exports are clean for computer science.
• Protect capitals in titles with braces, title = {Fixed Points of {Scott}-Continuous Maps}, because many styles lowercase titles.
• Cite preprints with their arXiv identifier, for example arXiv:1706.03762, and the version you read.

Pre-submission checklist

After acceptance

The final version has its own rules: fonts embedded, a copyright or licence form, often a source bundle and sometimes PDF/A. The camera-ready checklist covers them.

History. ENTCS (1995–2020) used its own macro package; see ENTICS for the current series.

Further reading

• LaTeX documentation from the LaTeX Project, including the official guide for authors.
• Overleaf’s LaTeX documentation, a good practical reference organised by task.
• CTAN’s list of journal and publisher classes.