PD4ML: HTML/CSS to PDF, RTF, and DOCX, from Pure Java

Generate PDF reports, invoices, statements, and other documents on the fly — from ordinary HTML and CSS, no browser or native dependencies required.

PD4ML is a document-generation engine that treats HTML and CSS as a page-layout language: you author content the way you’d author a web page, and PD4ML paginates and renders it as a production-quality PDF (or RTF/DOCX). It’s written entirely in Java — one self-contained jar, no OS-native libraries, no headless-browser process to manage — so it drops into any JVM environment: a web app, a batch job, a desktop tool, or a bare command line.

Where it fits

• Web applications. Generate PDFs on demand from HTML, JSP, or templated content in any Java web app, via the plain Java API or the built-in JSP tag library (pd4tl: prefix). A PHP wrapper (shelling out to the command-line tool) covers non-Java web stacks that still need PDF output.
• Desktop and batch tooling. Add reporting or “print to PDF” functionality to a desktop application, or run large batch conversions from the command line the bundled Pd4Cmd tool needs nothing but a JVM.
• Command-line / scripted use. java -jar pd4ml.jar [format] [flags…] converts a single document with no code at all; the same tool doubles as a lightweight PDF post-processor (page extraction, merging, metadata inspection) for one-off tasks.
• IBM Notes/Domino. DXL export can be piped through a bundled XSLT and converted to PDF — worth noting: this integration path is current-generation code, but the vendor only actively supports and exercises it against the older v3 line; treat it as v3-specific rather than assuming parity with the current v4 API.

What it actually does

Rendering fidelity

• A real CSS engine — not just headline properties: flexbox and CSS Grid are genuinely laid out (not merely parsed), along with CSS media queries (min-width/max-width), multi-column layout, and writing-mode for vertical text (CJK-style top-to-bottom columns).
• Full bidirectional text support — correct Unicode BiDi resolution for mixed Latin/Arabic/Hebrew content, not just a blanket left-to-right or right-to-left mode.
• SVG is rendered as genuine vector output (not rasterized to a bitmap first), and MathML formulas render as real typeset math via an embedded formula engine — both are first-class content, not placeholders.

Pagination control, beyond plain CSS

• Page-break rules (before/after/inside), widow/orphan control, and multi-column pages.
• Repeating headers, footers, watermarks, and full-page backgrounds — each independently scoped to a page range (“1”, “2+”, “3-7,odd”, …), settable either through the API or with inline -style tags in the source HTML.
• Automatic PDF bookmarks and a generated table of contents (), built from the document’s own headings.
• Footnotes and endnotes as a first-class authoring feature (/), with automatic numbering and page-aware placement — not something you have to fake with manual positioning.
• Mid-document page format changes: switch page size, orientation, or column width partway through a single document.

Standards and compliance

• PDF versions 1.4 through 2.0, plus PDF/A (archival, levels 1 through 4) and PDF/UA (tagged, accessible PDF) — accessibility structure tagging (headings, tables, lists, figures, links) is generated automatically from the source markup, not bolted on afterward.
• ZUGFeRD and Factur-X: produces the hybrid PDF/A-3 container these e-invoicing standards require, with the embedded structured invoice XML attached correctly.
• PDF encryption: RC4 (40/128-bit, legacy) and AES (128/256-bit), with fine-grained permission flags (print, copy, form-fill, assemble, etc.).

Fonts and text

• TrueType/OpenType embedding with glyph subsetting (embed only the glyphs actually used, not the whole font), kerning, and ligature substitution.
• Broad out-of-the-box Unicode coverage, so most multilingual content just works without supplying custom fonts.

Beyond PDF

• The same parsed document can also be written out as RTF or DOCX, or rasterized to PNG/TIFF images — one parse, multiple output formats, without re-parsing the source for each.
• A separate PDF post-processing toolkit (distinct from the HTML-to-PDF conversion path, each with its own manual and CLI tool): a low-level PDF object-model/editing API, digital signing (PKCS#12/PKCS#11/HSM, RFC 3161 timestamping, PAdES long-term validation), merging pages from multiple source PDFs with accessibility-tag reconciliation, size-optimizing/cleanup, and XFDF annotation/form-value import-export. None of this requires re-rendering from HTML, it operates on existing PDFs directly.
• Interactive PDF forms: HTML form controls (<input>, <select>, <textarea>, etc.) can be converted into real, fillable AcroForm fields rather than flattened static graphics.