More than a dozen copies of the logo turned up in my one-file pitch deck

Flow

Current build versus a build that checks itself

1. 1Missing image⌄

   Now: skipped, success message anyway. Checked: build stops and names the file, with a flag for drafts.

2. 2Repeated logo⌄

   Now: a full copy per slide. Checked: one copy in a style rule, used by every slide.

3. 3Missing font folder⌄

   Now: the build already stops. Checked: same.

4. 4Reference to nothing⌄

   Now: nothing looks for it. Checked: a scan after the build fails on any id that points at nothing.

5. 5Unused heading painter⌄

   Now: defined, never called, points at a missing gradient. Checked: wired up properly or deleted.

The pitch deck is one HTML file, and the logo is in it more than a dozen times. Those aren't links to one image; they are full copies, each one a long block of base64 text.

Two decks came in with one commit, a short pitch and a longer one built for printing. Each has slide files, a template, a big stylesheet and a small script that joins everything into one file. The script reads fonts and images from disk and pastes them in as data URIs, so the finished file doesn't need a folder of pictures next to it. A second script prints each deck to PDF. I like this setup, because one file is exactly what you want to send someone.

Then I read the build scripts and the output files, and I found three problems that never show up in the build log.

One logo, one copy per slide

The image step finds each path that points to an image, reads the file, and replaces that path everywhere in the page with the full encoded bytes. The short deck adds the logo to almost every slide while it builds, and the long deck has the logo typed into almost every slide by hand. Either way, one small image becomes a full copy per slide, and by my rough math close to a third of each file is just that logo. So the file grows with how often an image is used, not with how many images there are.

A catch block with nothing in it

If an image can't be read, the build skips it, leaves the old relative path in place, and still prints its normal success message. On your own machine the picture still shows, because the folder is sitting right there, but on anyone else's machine it's a broken image.

Both files in the commit are clean today, and the risk is smaller than I first thought. The short deck's folder is a link to the long deck's folder, and I guessed that a lost link would leave holes everywhere. It wouldn't, because the font step reads that same folder without any catch, so the build fails before it reaches the images. What slips through is a single renamed or deleted image, which is exactly the one nobody spots.

A heading painter nobody calls

The long deck's build also has a function that turns headings into SVG text with a gradient color. Nothing calls it, which is good, because the gradient it points at is never defined anywhere. I'd expect blank headings if anyone switched it on.

Fail on a missing image, store each one once

If you're building the same kind of thing, these are the checks I'd want in place:

• Stop the build when an image is missing, with a flag that allows gaps while drafting.
• Put each repeated image in the file once, as one style rule, and point every slide at it.
• After the build, scan the output for any leftover relative path or any #id that points at nothing.

None of that is in the commit yet. The heading painter I'd probably just delete.