I counted every element in 11,176 slide renders: 0.54% got baked into images

When you turn HTML into a shape-based document like PPTX, anything you can't map to a shape or a text box ends up as a cropped screenshot. The user can't edit that picture as text, and it goes soft when zoomed. I wanted to know how much of my own converter's output is like that, so I counted.

Short version: across 11,176 renders of my own slide layout library (254 layouts times 44 themes), there are 408,267 measured elements, and 2,200 of them (0.54%) become pictures. The list is identical in all 44 themes, so it is 50 elements per theme, in 12 layouts.

What I measured and how

A script opens each layout in headless Chromium at a fixed 1920x1080, walks the DOM, and writes one JSON file per (layout, theme) pair. Every element gets a kind: shape, text, svgShapes, arcs or decoration. Decoration is the picture bucket: pseudo-elements with content, background images, radial, repeating and conic gradients, filter, backdrop-filter, mask, non-trivial clip-path, and SVG it can't translate. Each one carries a reason string.

To recount, I read all 11,176 files and grouped by kind, then grouped the decoration ones by reason.

1. The markup decides, not the theme

I built a list of (layout, element name, reason) for each of the 44 themes and compared them. There was exactly one distinct list. Themes change colors and fonts, but which elements need a picture never changed. If you want fewer pictures, you fix layouts, and the theme count doesn't matter.

2. Compare the number from grepping source with the number from measuring

59 of my 254 layout files mention ::before. After stripping HTML and CSS comments, 7 still do. The other 52 only mention it in comments. In one theme, those 7 files hold 4, 5, 12, 5, 6, 4 and 9 measured pictures, which adds up to 45, the same as the measured ::before count. ::after is mentioned in 40 files and used in none, and the measurement has zero ::after entries. Two independent counts agreeing is what made me trust the table.

3. A reason name can point at the wrong cause

Two elements are labelled conic-gradient. I opened them. In the blue theme they are a 696x3px timeline line and a 1413x2px road centerline, and both are drawn with repeating-linear-gradient dashes. The classifier catches conic-gradient and repeating- in one regex (/conic-gradient|repeating-/) and returns a single label. If I had read the label and tried to fix a conic gradient, I would have gone looking for something that isn't in those files. I haven't renamed the reason yet.

A scene from the counts

The SWOT layout is the biggest single contributor: 12 baked elements in the blue theme, three list items in each of four quadrants. The reason says ::before, and the CSS rule is a 6px circle. I expected 12 tiny dots. The measured size of every one of those 12 elements is 755.2x24px, which is the whole list row. So the unit that becomes a picture is the row that owns the pseudo-element, not the dot. I did not open the baked images, so I can't say what is inside them, and I haven't changed the layout and re-measured to see whether a real element in the li would make them shapes.

Limits

One browser (Chromium), one viewport (1920x1080), one library. The viewport is fixed on purpose: my page margin is clamp(40px, 4vw, 80px), which is 57.6px at 1440 wide, 76.8px at 1920 and 80px at 2560, so measuring at another size quietly changes coordinates. The measurement files were last regenerated on 2026-10-27, and I recounted them on 2026-11-13. I did not open any exported file in PowerPoint for this post, so I am not saying how pictures look there.

What do you do with decoration done through pseudo-elements when you export to a shape-based format: leave them as pictures, or put a rule on the markup side so they are real elements?

Written with AI assistance. The claims about the code and the counts were checked against the project source and the measurement files by the AI agent on 2026-11-13; I haven't independently recounted them.