Engineering

For most of its life, GraphCompose could lay out text and structure very well, and draw very little. It produced invoices, reports, CVs, and proposals — documents that are mostly typography, spacing, and tables. That was the point. But real business documents are not only words. They have a revenue chart, a sparkline next to a KPI, a logo, a divider shape, a coloured panel with a soft gradient. Up to now, every one of those meant rasterizing an image somewhere else and pasting it in. ...

Most backend systems eventually need to produce documents: invoices, reports, offers, letters, CVs, certificates, export packs. The business treats those documents as serious output. They are sent to customers, attached to applications, used by operations teams, and archived for compliance. The code that produces them often does not get the same respect. This is the companion to What Drove Me to Build GraphCompose — that post was the personal story of how GraphCompose started. This one is about a claim I now believe after living inside that code: document generation is backend infrastructure, and it pays off when you build it like infrastructure instead of like a one-off script. ...

Building a PDF engine in Java is a useful way to meet a lot of hidden complexity at once. Text measurement, pagination, styling, rendering order, reusable components, API design, testing, and performance all become visible very quickly. This is not a tutorial about drawing text into a PDF. It is a reflection on what I learned while building the layout engine behind GraphCompose: the hard part is rarely one isolated algorithm. The hard part is making many small rules work together until the final document feels reliable. ...