Programmatic PDF Generation Without the Coordinate Math

Every developer who has generated a PDF programmatically knows the moment.

The first version goes quickly. Paragraphs, a table of line items, a page size, some margins. It looks like a document. Then someone asks for the company logo in the top corner, page numbers in the footer, and a link to the terms of service, and you discover that the friendly API stops right about there.

What comes next is the part nobody plans for. You drop to low-level PDF operations and start managing coordinates. You calculate where the footer sits on a page whose content height you do not know until the content is laid out. You work out that page five is the last page so the total count can be printed on page one. You reposition everything by four points because the logo pushed the table down.

None of this is your product. It is the cost of admission, and it is the part of the codebase nobody wants to touch a year later.

This release is about removing that work.

The Document Creation API already let you build a document from code: paragraphs with text, tables, lists, page size, and margins. That is a reasonable foundation, and for simple output it is enough.

The gap was everything between "a page with text on it" and a document you would actually send to a customer. Business documents are not paragraphs. They are branding, repeating headers, numbered pages, logos, signature blocks, links, and metadata. All of that lived below the high-level API, in coordinate space.

This release adds them:

An invoice needs a logo, a line-item table, a footer, and page numbers before it is recognisably an invoice. That set is now available without leaving the high-level API.

Headers and footers are built through a reusable content container, so they hold the same elements as the rest of your document: paragraphs, lists, tables, and images. A footer is not a special-cased string. It is content.

You can define them separately for first, odd, and even pages, and combine those categories. A title page with no header, a different treatment on left and right pages of a bound document, a disclaimer that appears from page two onward: all of that is a configuration rather than a workaround.

Page numbers are added as fields rather than as text, which is the detail that saves the most time. A field for the current page and a field for the total page count both resolve after layout, when the document knows how long it is. You never compute a page count yourself, and adding a paragraph in the middle does not invalidate the numbering.

Images are applied as a shape background rather than through a separate image element type. One model covers both, and it means an image inherits the same sizing, rotation, and outline controls as any other shape.

Shapes cover lines, lines with one or two arrowheads, rectangles, rounded rectangles, ovals, and arrows. Each supports width, height, rotation, background colour or image, and outline colour and thickness. Each also has a text box that can hold layout elements, which is how a callout box or a signature block gets built without positioning its border and its label separately.

Floating elements handle the content that does not belong in the main flow. A float can be positioned relative to the page, the paragraph, or the character, and you control how surrounding text reacts to it: flowing behind, in front, squared around, tightly wrapped, or broken above and below. Sidebars, watermarks, positioned logos, and pull quotes all come out of the same mechanism.

Hyperlinks attach to text runs, so a link is a property of the text rather than a rectangle you place over it and hope stays aligned. Links survive layout.

Charts cover pie, bar, column, line, and radar, with a title, axis names, categories, and data series. Enough for the summary visual at the top of a report, without exporting an image from a separate charting library and placing it by hand.

Metadata is set as part of document creation: title, author, subject, keywords. It is easy to skip and expensive to retrofit, because metadata is what makes a generated document findable once it lands in a content management system, and what compliance workflows read first.

The launch sample puts the whole set together: a branded, multi-page invoice with a logo in the header, customer details, a line-item table that runs across pages, a footer with a disclaimer and a resolved page count, a hyperlink to payment terms, custom margins, and document metadata.

Built entirely with high-level APIs. No coordinates.

That sample is the proof point, and it is the thing worth reading first if you are evaluating this.

The low-level PDF APIs are untouched. They remain available and unchanged. This is a higher-level layer over the existing layout engine for common document workflows, not a replacement. If you have precise, unusual output requirements, that path is still there, and code built on it keeps working.

Template-based generation still works as before. Generating documents from Office input files such as DOCX templates is unaffected.

The two approaches solve different problems. Templates are right when a designer owns the layout and code supplies the data. The Document Creation API is right when the document's shape is determined at runtime, by the data itself.

The API is available across C++, C#, Java, Go, Python, PHP, Ruby, JavaScript, and Objective-C. If your backend is Go, PHP, or Ruby, this is the same document creation workflow, not a reduced version of it.

Available in the 2026 Fall release, with updated code samples and documentation shipping alongside. It requires Template add on.

Read the documentation

See the code samples

Get the full Fall Release details