DEV Community: letx app

7 Advanced LaTeX Hacks Every AI & CS Researcher Needs Before Submission published

letx app — Tue, 18 Aug 2026 18:30:56 +0000

It is 3:00 AM, twelve hours before the NeurIPS or ICLR submission deadline, and your double-column floating figure just jumped three pages downstream, turning your tight 8-page draft into a 10-page layout violation. If you have ever spent more time debugging ! Package tikz Error: Memory full or hunting down orphaned citation numbers than fine-tuning your model's hyper-parameters, you know the quiet desperation of academic typesetting under pressure.

LaTeX remains the undisputed gold standard for technical publishing, yet most computer science and machine learning developers rely on basic templates and legacy workflows copied from decade-old StackExchange answers.

Here are 7 advanced, field-tested LaTeX hacks that will optimize your compilation pipeline, save your layout under strict page limits, and shave hours off your paper writing workflow.

1. Reclaim Lost Page Space with `microtype` Sub-Pixel Optimization

When you are 6 lines over an 8-page conference limit, cutting meaningful technical content feels like amputating a limb. Before you delete a crucial baseline description, enable font expansion and margin kerning via the microtype package.

microtype adjusts font kerning, letter spacing, and hyphenation at a sub-pixel micro-typographic level. It subtly stretches or shrinks line widths to eliminate awkward word wraps ("widows" and "orphans") without altering font sizes.

% Add to your preamble (works with pdfLaTeX, XeLaTeX, and LuaLaTeX)
\usepackage[activate={true,nocompatibility},final,tracking=true,kerning=true,spacing=true,factor=1100,stretch=10,shrink=10]{microtype}
% Micro-adjust spacing between characters
\microtypecontext{spacing=noninclusive}

Result: You typically gain 10–25 lines across an 8-page paper without any perceptible change to visual readability or reviewer compliance.

2. Fix Floating Figure Chaos in Two-Column Papers with `stfloats`

Double-column templates (such as IEEE, ACM, or NeurIPS) frequently misplace full-width environment floats (\begin{figure*} or \begin{table*}). By default, LaTeX pushes full-width figures to the top of the following page, often throwing your figures several sections out of order.

Include stfloats to enable bottom placement ([b]) for two-column floats and force strict ordering:

\usepackage{stfloats}

% Enables double-column floats at the bottom of the page
\begin{figure*}[b]
  \centering
  \includegraphics[width=0.95\linewidth]{figures/architecture_diagram.pdf}
  \caption{Overview of our proposed Transformer architecture with attention visualizer.}
  \label{fig:architecture}
\end{figure*}

Quick Float Placement Cheat Sheet

Float Specifier	Intended Behavior	Common Gotcha
`[h]`	Place float approximately here	Silently ignored if page capacity is full
`[t]`	Top of the current or next page	Default preference for most LaTeX engines
`[b]`	Bottom of page	Requires `stfloats` or `dblfloatfix` for `figure*`
`[p]`	Dedicated page of floats	Triggered automatically when floats pile up
`!`	Override internal layout constraints	Forces placement; can disrupt text flow

3. Externalize TikZ Graphics for 10x Faster Compilation

Vector graphics generated via TikZ produce gorgeous, scalable diagrams, but re-parsing complex geometric nodes on every document save slows compilation to a crawl.

Use the external library to compile TikZ graphics once into cached PDF snippets. LaTeX will automatically reuse the compiled PDFs unless the underlying TikZ code is edited.

\usepackage{tikz}
\usetikzlibrary{external}
% Enable caching in a dedicated subfolder
\tikzexternalize[prefix=figures/compiled_tikz/]

Compilation Speed Benchmarks (50-Page Manuscript with 12 TikZ Diagrams)

Pipeline Configuration	Cold Compile Time	Hot Re-Compile Time	Memory Usage
Standard Inline TikZ	42.4 seconds	41.8 seconds	High (480MB RAM)
Standalone `.tex` Subfiles	38.1 seconds	37.9 seconds	Moderate (310MB RAM)
TikZ Externalization (Cached)	43.1 seconds	3.2 seconds	Low (85MB RAM)

4. Create Publication-Grade Tables with `booktabs` + `siunitx`

Default LaTeX tables look amateurish when cluttered with vertical lines (|c|c|) and misaligned numbers. Top-tier conferences expect clean, professional typography with numeric alignment centered around decimal points.

Combine booktabs for formal horizontal rules with siunitx for automated decimal alignment:

\usepackage{booktabs}
\usepackage{siunitx}

% Configure decimal alignment precision
\sisetup{table-format=2.2, table-auto-round}

\begin{table}[t]
  \centering
  \caption{Top-1 Accuracy (%) on ImageNet-1k across baseline models.}
  \label{tab:results}
  \begin{tabular}{l S S}
    \toprule
    \textbf{Model Architecture} & \textbf{Baseline (\%)} & \textbf{Ours (\%)} \\
    \midrule
    ResNet-50                   & 76.13                  & 78.45              \\
    ViT-Base/16                 & 81.80                  & 84.12              \\
    ConvNeXt-Large              & 84.30                  & 86.91              \\
    \bottomrule
  \end{tabular}
\end{table}

5. Automate Cross-Referencing with `cleveref`

Stop manually writing Figure~\ref{fig:arch} or Section~\ref{sec:methods}. Hardcoded prefixes waste time and introduce inconsistencies when moving sections around during peer review.

The cleveref package automatically detects whether your target reference is a figure, table, equation, algorithm, or section, applying the appropriate capitalized label automatically:

\usepackage{hyperref}
\usepackage{cleveref} % MUST be loaded AFTER hyperref

% Usage in body text:
As demonstrated in \cref{fig:architecture} and detailed in \Cref{sec:methods}, our model outperforming prior baselines (\cref{eq:loss_function}).

6. Trim Unwanted Bibliography Metadata to Save Page Space

Massive BibTeX files exported from Google Scholar or Zotero often include irrelevant metadata like location, isbn, issn, url, or doi fields that spill over onto extra pages in the references section.

If using biblatex, suppress secondary fields directly in your preamble rather than editing hundreds of .bib entries by hand:

\usepackage[backend=biber, style=numeric-comp, sorting=none]{biblatex}

% Suppress non-essential reference fields automatically
\AtEveryBibitem{
  \clearfield{issn}
  \clearfield{isbn}
  \clearfield{doi}
  \clearfield{url}
  \clearfield{note}
  \clearlist{language}
}
\addbibresource{references.bib}

7. Standardize Math Notation with Centralized Custom Macros

When collaborating with multiple developers across institutions, inconsistent mathematical notation (e.g., one author writing \mathbf{x}, another writing \vec{x}, and a third writing \bm{x}) creates an unpolished paper.

Establish a single macros.tex file defining standard semantic shorthand for vectors, matrices, expectation operators, and loss functions:

% --- Math Shorthand Definitions ---
\newcommand{\R}{\mathbb{R}}                  % Real number set
\newcommand{\E}{\mathbb{E}}                  % Expectation operator
\newcommand{\mat}[1]{\mathbf{#1}}           % Bold matrices
\newcommand{\vec}[1]{\boldsymbol{#1}}       % Bold vectors
\DeclareMathOperator*{\argmax}{arg\,max}     % Argmax with proper limits
\DeclareMathOperator*{\argmin}{arg\,min}     % Argmax with proper limits

Take Your Developer Workflow to the Next Level

Mastering macros and preamble tricks helps eliminate layout bottlenecks, but local compilation failures, environment mismatches between co-authors, and merge conflicts during paper sprint weeks remain major productivity drains.

If you are looking for a modern, browser-based LaTeX environment built from the ground up for real-time developer collaboration, check out LetX.

Unlike legacy editors, LetX offers:

Sub-second real-time co-editing without lockouts or file-saving lag.
Instant preview compilation powered by optimized cloud container infrastructure.
Built-in GitHub sync and native BibTeX reference management.
Pre-configured conference templates (NeurIPS, ICML, IEEE, ACM) ready out of the box.

Try LetX for free today and make your next paper submission deadline completely stress-free.

We built a free collaborative LaTeX editor. Here's the part that was actually hard.

letx app — Sat, 08 Aug 2026 19:20:29 +0000

The deadline was nine hours out.

My co-author was in another timezone, editing the same main.tex I had open. We were passing the file back and forth over a shared drive like it was 2020. At some point we both hit save. A results section disappeared, and neither of us could say with confidence which copy was the real one.

That night didn't make me want to start a company. It made me want to throw my laptop in a river.

It's also why we built LetX — a free, real-time collaborative LaTeX editor that runs in the browser.

This post is about the engineering, not the pitch. Specifically: the part that took four times longer than we estimated, and why the obvious solution doesn't work.

First, the question every developer asks
"Why not just use git?"

We did. For a while it was great. Then it stopped being great, for a reason that has nothing to do with git being bad.

Git works when everyone editing the document understands git. In a research group, that's usually one or two people. The rest are statisticians, chemists, and supervisors who have a paper to write and no interest in learning what a rebase is.

I once watched a genuinely excellent statistician spend forty minutes resolving a merge conflict in a .bib file. That's not a workflow. That's a tax on someone whose time is worth considerably more than the tooling that consumed it.

There's also a structural mismatch. Git operates on line-level diffs, and LaTeX prose doesn't respect line boundaries. Reflow one paragraph and you've "changed" every line in it. Two people editing different sentences of the same paragraph produce a conflict git cannot resolve, because from git's point of view they rewrote the same line.

You can mitigate this — one sentence per line, latexdiff, semantic linefeeds. Every mitigation is a convention you now have to enforce socially across a group of people who did not agree to it.

Social solutions to technical problems don't survive contact with a deadline.

The actual hard part
Real-time collaborative editing is one of those problems that looks solved from the outside. Google Docs did it in 2006. There are libraries. How hard can it be.

Here's the shape of the problem. Two people type into the same document from different countries on different network conditions. Their edits arrive out of order. You need every participant to converge on an identical document, without a central referee deciding who wins, and without ever showing anyone a "someone else is editing, try again" dialog — which is just a merge conflict wearing a nicer outfit.

There are two established approaches.

Operational Transformation (OT) is what Google Docs uses. Every edit is an operation, and operations get transformed against concurrent ones before being applied. It works, and it's notoriously difficult to implement correctly — the transformation functions have to be right for every pair of operation types, and getting them subtly wrong produces divergence that only shows up under specific network timing.

CRDTs (Conflict-free Replicated Data Types) take a different approach: design the data structure so concurrent operations commute by construction. If operations commute, order stops mattering, and convergence is a property of the type rather than something you have to prove about your transformation logic.

We went with CRDTs, using Yjs. Same algorithm class Figma uses for multiplayer.

The tradeoff is honest: CRDTs carry metadata overhead. Each character effectively needs identity so the structure can order operations deterministically. Yjs is very good at compressing this, but "very good at compressing overhead" is not "no overhead."

For a 300-page thesis, that's a real consideration.

Why LaTeX makes this harder than it looks
Here's what a generic collaborative text editor doesn't have to worry about.

LaTeX is not prose. It's a markup language with strict structural requirements, and it fails loudly and completely on violations. One unmatched brace doesn't degrade the output — it kills the compile.

Consider two users editing this concurrently:

\begin{theorem}
Let $f: X \to Y$ be a continuous map.
\end{theorem}
User A wraps the statement in \textbf{...}. User B, at the same moment, edits inside the same line. Both edits are individually valid. The CRDT converges — that's guaranteed, that's the whole point of the type.

But converging on a consistent document and converging on a compilable document are different properties. The CRDT promises the first. It has no opinion whatsoever about the second.

Now scale that to environments:

\begin{align}
a &= b + c \
d &= e + f
\end{align}
If one user deletes \end{align} while another is typing inside the block, you get a document every client agrees on and no compiler will accept.

Generic text editors don't have this failure mode, because generic text doesn't have a compiler that rejects the entire file over a single missing token. A missing in HTML renders badly. A missing \end{align} in LaTeX produces nothing at all.

Reconciling CRDT convergence with LaTeX's structural requirements is where our estimate went wrong. Not by a little.

Estimates are like that.

The compile loop is a latency problem, not a throughput problem
Second architectural thing we got right early, mostly by accident.

Writing LaTeX is a loop:

edit → compile → look at the PDF → edit again
You run that loop hundreds of times a day. It's not a batch job — it's an interactive feedback cycle, and it should be measured like one.

This distinction matters more than it sounds. Optimizing for throughput means asking how many documents you can compile per minute across all users. Optimizing for latency means asking how long this user waits for this compile.

A queue is the clearest expression of the difference. Queuing is excellent for throughput and terrible for latency, and worse, it makes latency unpredictable — your compile time now depends on how many strangers happen to be compiling right now. Unpredictable delay breaks concentration in a way that consistent slowness doesn't. You can adapt to a compile that always takes three seconds. You can't adapt to one that takes one second or eleven depending on the time of day.

We target roughly a second, no queue. The interesting engineering question — how you isolate arbitrary user-supplied LaTeX, which can execute shell commands under the wrong configuration, while keeping cold-start low enough for interactive use — is a whole post on its own.

Note to author: dev.to readers will ask about compile sandboxing in the comments. Have a real answer ready — container per compile, gVisor, seccomp profile, -no-shell-escape, whatever you actually do. Don't hand-wave it. This is the single most likely technical question on this post.

Three constraints we set and refused to relax

The free tier has to be genuinely usable, not a demo.

Unlimited projects, unlimited collaborators, unlimited compiles. No per-seat charge for adding your advisor or the undergrad doing the figures.

This is a real constraint on the business and we took it deliberately. Existing cloud editors solved collaboration and then metered it — compile timeouts, caps on how many people can be in a document, version history behind a paywall. Version history is the one feature you need most on the day something goes wrong.

The people who most need LaTeX to be free are the people most likely to hit the paywall. Students, early-career researchers, labs outside well-funded institutions.

As an engineering constraint, "unlimited compiles on the free tier" is a much more interesting problem than it sounds. It means compile cost per user has to be low enough that the free tier doesn't scale into a fire.

Compiles are fast and unqueued. Covered above.
Unpublished work stays private.

Researchers hand an editor unpublished results, grant applications, and blind-review submissions. That's not ordinary user data and it shouldn't be treated as ordinary user data.

What we got wrong
We assumed people would come for the collaboration. Collaboration was the entire thesis of the product.

What people actually asked for, repeatedly, was templates.

Not because they couldn't write a preamble — because starting is the expensive part. Nobody wants to spend the first two hours of a submission hunting for the right IEEE class file, or reverse-engineering a department thesis format from a PDF a senior student emailed them.

So we built the library out to 600+ templates: IEEE, ACM, Springer, Elsevier, theses, CVs, posters, grant applications.

The lesson generalized further than templates. We'd been optimizing the middle of the workflow. The friction was concentrated at the very beginning of it.

If you're building a tool, it's worth asking which part of the workflow you've actually instrumented. We were measuring the part we found interesting.

Where we are
1,300+ students and researchers, across 90+ universities and research labs in 35+ countries.

That's a real number and a small one. I still read every piece of feedback, and a single well-argued complaint can change the roadmap in a week.

Free, browser-based, nothing to install. Real-time collaborative editing, live PDF preview, version history with rollback, SyncTeX, and ZIP import for moving an existing project across.

Next up, both early: an agentic LaTeX editor that can refine a section or insert a table without you leaving the document — LaTeX is unusually well suited to this, because the source is text and the output is verifiable, so you can actually check whether the model's suggestion compiled. And QuantumSketch, which turns a paper into slide decks.

If you write LaTeX with other people
letx.app — free tier, no install, import an existing project as a ZIP.

If the compile loop doesn't feel faster, I'd genuinely like to know why.

And if you've built collaborative editing on CRDTs and hit the structural-validity problem from a different angle, I want to hear how you handled it. That's the part I'm still least satisfied with.