Getting Started With LaTeX for Math Slides
LaTeX isn't the most intuitive way to make a presentation if you're coming from PowerPoint or Keynote, but it becomes the right tool the moment your slides contain more than a few equations on a page. The learning curve is real, but once you understand the pipeline, it saves enormous time compared to trying to get math to line up in a visual editor. The core workflow is straightforward: write the source in a .tex file, compile it to PDF, and run it through the projector. For something simple, that might be a single \documentclass{beamer} preamble and a handful of frames. For something that actually looks good under time pressure, you need a bit more structure. Most advanced math presentation setups share a common backbone of packages. You need amsmath for the standard equation environments, amssymb for the extended math symbols, and amsfonts for proper blackboard bold and Fraktur. Graphics come from graphicx, and if you're pulling in TikZ diagrams or animations, that package has to be loaded too. xcolor lets you override the default theme colors without fighting the class options. And geometry is there when you need non-default margins on the slides themselves. There are others you might see recommended—empheq, mathtools, siunitx—but those are situational. The core set gets you through 90% of what shows up in a graduate-level or research presentation. When people search for a specific format, they usually mean a clean beamer setup with properly spaced multi-line equations, aligned derivations, and readable frame titles that don't eat into slide real estate. That format exists, it just takes a little deliberate configuration rather than a single command. The default beamer behavior leaves too much whitespace around displayed equations and doesn't always number them the way a lecture expects you to. A few adjustments to the preamble and frame layout fix most of that.
Let me show you what a typical frame looks like when it's actually working right, then I'll explain the choices. The equation environment handles standalone numbered formulas. The align environment from amsmath is where the real control lives—you use & to mark alignment points and \\ to break between lines. The \nonumber tag suppresses the equation number on the intermediate step, which matters when the final result is what the audience needs to see. Without it, every line gets a number and the frame looks cluttered within a couple of seconds. A few years ago I was putting together a talk on spectral graph theory with roughly forty frames containing large adjacency matrices and eigenvector derivations. The problem wasn't the math—it was the layout. Beamer's default vertical spacing compressed some of the longer align blocks so tightly that the equations overlapped visually on the slide. It only became obvious when I projected it in the actual room, not when I was previewing on the screen. The workaround was two-fold. First, I added a small global setting: \setlength{\jot}{8pt} in the preamble. That single command adds eight points of extra space between every row in any array-like environment, which includes align. Second, for the frames that still overran, I wrapped individual display equations in a \vspace{-4pt} before the offending block. It's not elegant, but it's precise. You can tune it frame by frame instead of rewriting the whole layout engine.
One thing that catches people off guard is how mode-aware beamer is by default. If you write something like \textcolor{red}{important} inside a frame and then change the theme later, the color definition might not behave the way you expect because beamer layers colors on top of theme settings. The safer path is to define your colors explicitly in the preamble with \definecolor{myred}{RGB}{200,50,50} and reference that name everywhere. You save yourself a debugging session where a highlight that looked fine on your laptop disappears on the projector. Another one: the \alert{} command looks convenient for highlighting key steps during a live presentation, but it changes the font shape to italic bold in most themes. When you're presenting densely notated equations, that visual change can make it harder for the audience to track the flow of a derivation because their eyes keep landing on the alert fragments instead of following the alignment columns. I usually reserve \alert for textual emphasis and let the math stand on its own structure.
Get the Full Details
Common Pitfalls With Specific Workarounds
Special characters outside of math mode will break your compile. Ampersands, hashes, percent signs, and tilde characters all have special meanings in LaTeX. If you're writing about modular arithmetic and need a literal % in a frame title, you have to escape it as \%. A missed escape on a single character stops the entire compilation, and the error message points you at the wrong line half the time because the parser gets confused before it reports the fault. Long equation numbers can overflow the right margin, especially in narrow frame layouts. The fix is \numberwithin{equation}{section} in the preamble, which resets the counter per section and keeps the label short enough that it doesn't crash into the equation text. You also get automatic section-based numbering for free, which is useful when the talk spans multiple sections. Large matrices defined with the pmatrix or bmatrix environment often exceed the text width on a standard 16:9 slide. You can shrink them inline with \scriptsize or \tiny wrapped around the environment, but that makes the surrounding text too small by comparison. A cleaner approach is \resizebox{\textwidth}{!}{...} from the graphicx package, which scales the entire matrix proportionally without touching the rest of the frame.
Building a Minimal Working Example From Scratch
If you're starting fresh, here's a template skeleton that covers the essentials without unnecessary baggage: This compiles cleanly and gives you a functional base. The 16:9 option matches modern projectors. The custom color and font settings give the frames a consistent look without relying on a theme that might clash with your content. The geometry setting ensures you aren't wasting the full width of the slide on empty margins. It's worth stating plainly where this approach breaks down. If your presentation relies heavily on animated diagrams that change color or shape in response to speaker interaction, beamer's animation support is limited and can become fragile across different PDF viewers. The same applies if you need to embed live computational notebooks or switch between code execution and static slides in a single file. In those cases, reveal.js with MathJax or Jupyter export gives you interactivity that LaTeX simply doesn't provide. Also, if your audience includes people who need screen reader access, a pure PDF presentation from beamer has worse accessibility support than an HTML-based deck. The math renders as images or annotated PDF content rather than structured semantic markup.
Another honest limitation: the compile time grows non-linearly with the number of TikZ figures. A presentation with twenty hand-drawn diagrams can take anywhere from thirty seconds to several minutes to compile, depending on your machine and how many external packages you pull in. If you're making rapid edits during a dress rehearsal, that becomes a real bottleneck. The workaround is to separate figures into their own .tex files and include them with \includeonly, so you only recompile the frames you're actually changing rather than the whole deck.
Practical Workflow Advice
Keep your source organized. I use a directory structure where the main .tex file sits in the root, and everything else—figures, custom styles, bibliography—goes into subdirectories. That makes version control cleaner and stops your project folder from becoming a scattered mess halfway through a talk series. Compile early and often. Don't wait until you've written ten frames to check that the equations render correctly. Build one frame, compile it, verify it, then move on. The cost of catching a bad \nonumber tag on frame three is zero. The cost of catching it after you've written twenty frames is proportionally higher. Test on the actual display when possible. Colors shift, fonts render differently, and text that looked perfectly readable on a 15-inch laptop screen can become illegible on a 10-foot projection. I keep a low-resolution copy of every frame as a PNG and review it on a phone at arm's length. That approximates the viewing distance well enough to catch sizing problems before the talk. For the source code itself, stick to English comments. The LaTeX compiler ignores them, but anyone who inherits your file or helps you debug will thank you if the notes aren't in a language they don't read. A two-word comment at the top of each frame explaining what that frame is supposed to demonstrate takes five seconds and prevents an hour of re-reading when you come back to it six months later.
