Flutterfrog
← Journal

30 May 2026 · 4 min read

By Gokul Kumar

We let two versions of the same document fight

We had two ways of turning a proposal into a finished PDF and no honest way to choose between them. Both looked fine in isolation. Preferences were being argued from taste.

So we ran them against each other on a real document that was going to a real client.

The rule that made it useful

Both versions rendered to PDF. Both PDFs converted to images, page by page. The scoring then happened on those images — on what a reader would actually see — and never on the source that produced them.

Judge the artefact, not the thing that made it. Source that reads beautifully and renders badly is the normal failure, not the exotic one.

One version won, and not narrowly. It is the one still in use.

Four things we only learned by doing it

  • Page numbers have to come from the renderer's own header and footer mechanism — the obvious approach of pinning an element to the bottom of the page silently stops counting
  • Margins belong in the render call, not the stylesheet
  • A document that looks correct on screen can paginate badly, and you will not find out from the source
  • The comparison is only fair if both sides render the same content on the same day — rebuild one and the result is worthless

The honest scope

The transferable part is not the tooling. It is that a preference between two ways of working can usually be settled in an afternoon by producing both and comparing the output, instead of by arguing from taste in a meeting. Almost nobody does it, because it feels like a detour. It is faster than the argument.

Have a system worth building?

Start a project