Workflow 8 min read 20 October 2026

Variable Data PDF: Personalised Printing, VDP Workflows, and PDF 2.0 DPart

Variable data printing (VDP) generates personalised PDFs at scale — each copy has different names, addresses, offers, or images. This guide covers VDP architectures (PPML, PDF/VT, PDF 2.0 DPart), the fixed vs variable content split, personalisation tools, and common pitfalls in high-volume personalised PDF production.

Variable data printing (VDP) is the production of personalised documents at scale: direct mail pieces where each recipient gets their name, offer, and imagery; event tickets where each has a unique barcode and seat assignment; financial statements where the figures are different for each account holder. PDF supports VDP workflows at several levels of sophistication — from basic mail-merge via template tools, through to the dedicated PDF/VT standard (ISO 16612-2) and the /DPart document part hierarchy introduced in PDF 2.0. This guide covers VDP architectures, the fixed versus variable content distinction that is central to efficient PDF-based personalisation, the PDF standards designed for VDP, the toolchain options at different production scales, and the common pitfalls in high-volume personalised PDF production.

Fixed vs variable content: the VDP architecture principle

The performance architecture of any VDP system is built around the fixed/variable content split: Fixed content — Elements that are identical across all output instances: the background image, the company logo, legal boilerplate text, the overall layout. In PDF-based VDP, fixed content is typically stored once and referenced by all output instances — either as a page template (in PDF/VT's resource dictionary approach) or as a shared object stream. Variable content — Elements that change per instance: the recipient name, account number, personalised offer, QR code, photograph. These are generated individually for each output record. Why it matters — In a traditional print-PDF-per-recipient approach, a mailing of 100,000 recipients produces 100,000 PDFs, each containing the full fixed content duplicated. At 200 KB per record, that is 20 GB of data — most of it identical. A properly structured VDP workflow stores the fixed content once and generates only the variable content per record. The output file is dramatically smaller and RIP processing time is significantly reduced because the RIP can cache the fixed content. The PPML approach — PPML (Personalized Print Markup Language, a PrintXML standard) separates reusable object libraries from per-record variable data. The output document references shared objects by ID; the RIP renders the shared objects once and combines them with per-record variable data at print time. PDF/VT takes a similar architectural approach using PDF's resource dictionary and reference XObject mechanisms.

PDF/VT and PDF 2.0 DPart

PDF/VT (ISO 16612-2) — Published in 2010, PDF/VT defines a PDF profile for variable and transactional printing. Key concepts: Document Part Metadata (DPM) — Metadata associated with each document part (each personalised instance) within a multi-record VDP PDF. DPM entries describe the job, recipient set, document, page set, and page for each record — enabling selective processing, extraction, and tracking. Reference XObjects — In PDF/VT, shared fixed content is stored as Form XObjects that can be referenced via a reference XObject mechanism (pointing to a resource in an external PDF). This allows the RIP or downstream processing system to cache fixed content independently of the variable records. PDF/VT-1 — A self-contained single-file format suitable for digital delivery; all content in one PDF. PDF/VT-2 — Multi-file format where fixed-content resources are in separate files referenced by the variable content file. PDF/VT-2s — Streaming variant using PDF 1.x incremental update structure for streaming delivery. PDF 2.0 /DPart hierarchy — PDF 2.0 (ISO 32000-2:2017) introduced the /DPart (Document Part) tree as a native PDF 2.0 mechanism for VDP document structure. The /DPart tree is a hierarchy of document part dictionaries (each with its own metadata and page range) that describe the logical structure of a multi-record VDP document — who each instance is for, what set it belongs to, and what metadata applies to it. The /DPart approach in PDF 2.0 is simpler and more integrated with the core PDF model than PDF/VT's separate DPM mechanism. It also integrates with the /AF (Associated Files) mechanism — each document part can have associated data files (e.g., per-recipient XML, barcode data, address CSV) embedded as associated files.

VDP toolchains and production considerations

Low-volume template tools — For hundreds to low thousands of personalised PDFs, template-based approaches are practical: PDF form population — Create a PDF with AcroForm fields and populate them programmatically. Python pypdf: writer.update_page_form_field_values(). pdftk: pdftk template.pdf fill_form data.fdf output output.pdf flatten. This approach is simple but not optimised for fixed/variable content efficiency — it duplicates the entire PDF per record. Reporting tools — JasperReports, Crystal Reports, SSRS — generate personalised PDFs from data sources. Suitable for financial statements, invoices, reports. Output is typically non-VDP PDF without document part structure. Mid-volume workflow tools — For tens of thousands of records, dedicated VDP tools are appropriate: Adobe InDesign Data Merge — Generates personalised PDFs from a CSV and an InDesign template. Simple but limited to InDesign's typesetting capabilities and not optimised for large volumes. PrintVis, EFI Fiery, Creo — Production-level VDP tools targeting commercial printing environments. Generate PDF/VT output with proper fixed/variable content separation. High-volume production — For millions of records (direct mail, statements, bills): Dedicated composition systems (HP Exstream, Thunderhead, Sefas) generate PDF/VT or structured multi-part PDFs optimised for RIP performance. The fixed content is pre-processed and cached; only variable content streams are generated per record. Output rates of millions of pages per hour are achievable. RIP considerations — PDF/VT and DPart-structured PDFs require a VDP-capable RIP. Most production digital print controllers (EFI Fiery, Xerox FreeFlow, Konica Minolta JDF) handle PDF/VT. Verify RIP capabilities before choosing a VDP PDF format.

Frequently asked questions

What is the difference between PDF/VT and a standard PDF with personalised content?

A standard personalised PDF (generated by filling an AcroForm or running a template tool) contains all content — fixed and variable — for one recipient instance. It makes no structural distinction between what is shared and what is unique. PDF/VT is a PDF profile that adds structural metadata (Document Part Metadata) identifying where each recipient's content begins and ends, and uses reference XObject mechanisms so that fixed-content resources can be stored once and reused across all instances. The practical difference: a standard personalised PDF is simple to create but inefficient at scale; PDF/VT enables RIP caching of fixed content, selective document processing (print pages 3–7 for recipient group B only), and job tracking by recipient.

Can I generate personalised PDFs with Python?

Yes, at different levels of sophistication: (1) Simple field filling: use pypdf or pdfrw to populate AcroForm fields from a data source. (2) Template composition: use ReportLab to generate fully programmatic PDFs with variable content positioned on a fixed background. (3) Document merging: generate variable content PDFs and merge with a fixed template using pypdf or pikepdf. (4) For VDP-structured output with DPart metadata: PDF 2.0's DPart structure can be built with low-level PDF object construction using pikepdf — but there are no high-level Python libraries specifically targeting PDF/VT output as of 2026. For small-to-medium volume (under ~100K records), Python-based approaches are practical; for production VDP at scale, dedicated composition tools provide better performance and reliability.

What is an FDF file and how does it relate to PDF forms?

FDF (Forms Data Format) is a lightweight file format for transmitting PDF form data — just the field names and values — without the full PDF document. An FDF file contains a /FDF dictionary with a /Fields array of field-value pairs and optionally a /F entry pointing to the source PDF. PDF viewers can import FDF data into a matching PDF form, populating all named fields. XFDF (XML FDF) is the XML-based equivalent with the same functional purpose. The workflow: (1) user fills a PDF form; (2) form is submitted as FDF/XFDF to a server endpoint; (3) server stores the data without storing the entire PDF; (4) the original PDF can be populated with the FDF data at print time. This reduces server storage (FDF is kilobytes, not megabytes) while preserving the ability to reconstruct the filled form.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Fill PDF form Edit PDF Open editor