DEV Community: decksmith

Which CSS variable made this color? Ask the browser three times instead of guessing from the value

decksmith — Thu, 05 Nov 2026 06:09:29 +0000

One of my color themes sets three CSS variables to the exact same value: --ink, --accent and the inverse background are all #1F2BE0. That was fine for rendering. It stopped being fine when I needed to go from a computed color back to the variable it came from.

The situation: I measure a page once, in a browser, and store the result. Later, a user swaps in their own palette, and I need to repaint the stored result without a browser (the code that does it runs on a server with no headless browser). getComputedStyle only gives you rgb(31, 43, 224). The variable name is gone.

I considered three ways to get it back.

Look the value up in the theme's variable table. With my cobalt theme that returns three candidates for every blue thing on the page, so it's a coin flip. It also can't see through color-mix(), because a mixed color matches nothing in the table.
Walk the CSS declarations and read which var() each element uses. That means reimplementing the cascade, inheritance, color-mix() and gradients. I decided I'd rather not own a second CSS engine.
Measure again with every variable set to a different marker color, and see which elements move with which marker.

I went with the third one. A minimal version of it:

const vars = ['--ink', '--accent', '--bg-inverse', '--paper'];
const markerSets = [
  ['hsl(7 72% 44%)',   'hsl(97 72% 44%)',  'hsl(187 72% 44%)', 'hsl(277 72% 44%)'],
  ['hsl(151 58% 62%)', 'hsl(241 58% 62%)', 'hsl(331 58% 62%)', 'hsl(61 58% 62%)'],
];
// run 1: theme as is. Runs 2 and 3: inject :root{ --ink: marker; ... } after the theme
// then read getComputedStyle for every element and for every variable

I ran this against a four-element page in Chrome 156: a heading using --ink, two boxes using --accent and --bg-inverse, and a box using color-mix(in srgb, var(--accent) 30%, var(--paper)). The first three all compute to rgb(31, 43, 224) in the untouched run, so a value lookup matches three variables for each of them. With markers, the heading follows --ink in both marked runs, the first box follows --accent, the second follows --bg-inverse. Each one is unambiguous after two extra runs.

The mixed box matches no variable in any run, which is the signal that it's a mix. Solving each channel against the two marker values gave a weight of 0.296 to 0.302 for --accent and the rest for --paper, which is the 30% I wrote in the CSS.

Two details that mattered:

Use two marker sets rather than one, so a coincidence in one run has to repeat in the next. My real code accepts an assignment only if it fits the observed colors in all three runs.
If the theme sets a variable to transparent, give that variable a transparent marker. An opaque marker makes a previously invisible box visible, the page changes shape, and the runs no longer line up element by element.

What I haven't handled: colors that aren't driven by a variable at all (an image, a hard-coded hex) simply never move, and I treat them as constants. I haven't tested anything outside Chromium.

Has anyone solved this without a browser, for example by parsing the stylesheet with something like postcss and resolving var() and color-mix() yourself? I'm curious how far that gets before the cascade bites.

This post was written with AI assistance. The claims about the code were checked against the project source and a small test run in Chrome.

Embedding a font in a PPTX: the file that LibreOffice used, and the two it silently ignored

decksmith — Wed, 21 Oct 2026 06:03:42 +0000

I've been writing a PPTX exporter, and I wanted the font to travel with the file. When the person opening it doesn't have the font installed, the text falls back to some default and the line breaks drift.

PPTX can carry fonts. The part is called a fntdata file, and from the spec and a few open source implementations I pieced together that it should be an EOT wrapper (Embedded OpenType) around the TTF. Before writing any real code I ran one slide through four variants to see which one the renderer would honor.

The setup: one chart slide that uses VT323, a font I did not have installed on this computer. I rendered each variant to PDF with LibreOffice 26.8.0.3 and ran pdffonts to see which font actually got drawn.

What I put in the file	Font in the PDF
Nothing	Fallback fonts (FrankRuhlHofshi-Bold, LinuxLibertineG)
EOT with Flags 0, plus `embedTrueTypeFonts="1"` on the presentation	VT323-Regular
The raw TTF as the fntdata, plus `embedTrueTypeFonts="1"`	Fallback, silently ignored
EOT with Flags 0, no `embedTrueTypeFonts` attribute	Fallback, silently ignored

Only the second row worked, the one where both pieces were present. In the other two attempts the text fell back to a substitute font, the same outcome as embedding nothing at all.

The same slide, converted to PDF by LibreOffice 26.8.0.3. Top: nothing embedded. Bottom: EOT with Flags 0 plus embedTrueTypeFonts="1".

A few details that cost me time:

The EOT header is the version 0x00020002 layout from the W3C submission. Flags 0 means no MicroType Express compression and no XOR. I couldn't find a public compressor for MicroType Express, so uncompressed it is.
LibreOffice's own PPTX export writes the same thing (EOT, Flags 0, TTF appended as is), and it also writes embedTrueTypeFonts="1". Its import code only reads the embedded font list when that attribute is true, and always treats the data as EOT. That matches what the table shows.
I opened a real fntdata from Apache POI's test data. Its header says Flags 0x5, which is subset plus compressed, so whatever Office writes is not what I'm writing. I can't prove that file came from PowerPoint itself, so I'm only using it as a header reference.
Variable fonts need care. I pinned the weight to make a static instance, then rewrote the name table so the family name in the font, the family name in the EOT header and the typeface attribute all matched.

On size, the font is the expensive part. Pretendard Regular after deflate, which is roughly what the zip does to it:

Characters kept	Size
Whole font	1,117,566 bytes
All 11,172 Hangul syllables plus ASCII and Latin-1	931,592 bytes
The 2,350 common Hangul syllables plus ASCII and Latin-1	233,993 bytes
Only the 30 characters used on the slide	4,619 bytes

I went with the 2,350 set. On a test over 41 themes with 177 layouts each, the subset lost zero characters out of 64,465 (font, character) pairs. The catch is that if the recipient types a syllable outside those 2,350, only that character falls back to the default font. Microsoft's documentation says the same about subset embedding, that it limits editing.

Here is what I did not check. I don't have PowerPoint on this computer, so everything above is LibreOffice behavior. I don't know whether PowerPoint accepts an uncompressed EOT. Comments in one open source project say a raw TTF makes Windows PowerPoint fall back to Calibri, and the same comments mention PowerPoint rejecting a whole file as corrupt after an XOR obfuscation attempt on a font part. Those are their observations, not mine, so I'm keeping the feature off by default until someone opens the file in PowerPoint on a machine without the font. Keynote and PowerPoint for the web are also untested.

If you've opened an uncompressed (Flags 0) EOT fntdata in Windows or Mac PowerPoint on a machine without the font, did it load the font, or did it quietly fall back?

This post was written with AI assistance and checked by me against my experiment notes.

Seven signs a slide deck was made by AI

decksmith — Mon, 14 Sep 2026 10:31:47 +0000

I render slide layouts at 1920x1080 and run automated checks on every one of them: content outside the canvas, text clipped by its container, content running into the footer, overlapping elements, and elements hidden behind others.

After a while I noticed the failures weren't random. The same patterns kept coming back, and they matched what makes a generated deck feel off when you sit through it. None of them are about taste. They are decisions made in the wrong order.

1. Everything is centered

Cover centered, body centered, closing centered. Centered text never tells the reader where to start. A cover with one line can stay in the center. Once there are two blocks of information, left align and make one of them clearly bigger than the rest.

2. Three cards, whatever the content

Two items become three cards. Five items become three cards. The layout got picked before anyone counted the items, and three across is the arrangement most templates lead with, so that is what comes back by default.

Count first, then pick an arrangement built for that count. Quick test: cover the slide and say how many things it compares. If that number isn't the number of boxes on screen, the form is wrong.

3. The title is a sentence

"We improved customer satisfaction through a data-driven approach" is not a title. It's the script, and it competes with the person speaking. Cut it to a noun phrase and lead with the number: "Satisfaction up 32%". If a title needs more than about 40 characters, two messages are probably sharing one slide.

4. Numbers arrive without a source

A market size in 90pt type, no year, no idea who produced it. Models are good at filling in plausible figures and just as good at leaving out where they came from. Put the year and source on the same slide, even in small type. A blank space is cheaper than a wrong number.

5. Decoration that means nothing

A gradient behind the text, an icon on every bullet. Decoration exists to pull the eye somewhere, so when everything is decorated, nothing pulls. Use one accent color per slide and spend it once. Gradients also shift the value behind text, so contrast stops being predictable and small type suffers first.

6. Text that clips or overflows

A title wraps to two lines and pushes the cards below it off the edge. This is a verification problem, not a design one. Generated slides usually look fine as code and have never been rendered at real size.

This is also the easiest one to catch with a script. Render the slide in a headless browser at the size you'll present at, then compare each element's bounding box with its container. For hidden content, document.elementFromPoint at the element's center tells you whether something else is sitting on top of it.

7. Slides drift from each other

Slide three and slide seven have different margins, and the body text changes size somewhere in between. Building one slide at a time means every decision is made fresh and lands on a slightly different value. Nobody in the audience names this one. They just remember the deck as careless.

The fix is the same one you'd use in a web app: pull spacing and type sizes into CSS variables and let every slide read from them, so the whole deck keeps one rhythm.

The order behind all seven

The usual sequence is to write everything, look for a layout, then shrink the text or stretch the box when it doesn't fit. Reverse it. Decide the one thing the slide has to say, count the items, pick an arrangement for that count, then write to the space you have. Most of the list above never gets a chance to happen.

What else do you keep seeing in generated decks? I built this list from render failures, so it leans toward things a script can detect. I suspect the tells that matter most are ones no checker would catch.