dxpdf — Fast DOCX to PDF Converter in Rust

Convert Microsoft Word DOCX files to PDF without Microsoft Office, LibreOffice, or any cloud API.

dxpdf is an open-source, standalone DOCX-to-PDF conversion engine written in Rust and powered by Skia. It reads .docx files and produces high-fidelity PDF output — preserving text formatting, tables, images, headers, footers, hyperlinks, and page layout. Available as a CLI tool, a Rust library, and a Python package.

Built by nerdy.pro.

Key Features

• Fast — business documents convert in 55–170 ms depending on how their fonts resolve, a 171-page document in about 420 ms
• High fidelity — parse → resolve → layout → subset → paint pipeline with pixel-accurate baseline positioning
• Compact output — embedded fonts are subsetted to the glyphs actually used, so PDFs stay small
• Type-safe — compile-time dimensional type system (Twips, Pt, Emu) prevents unit mixing bugs
• Standalone — no Office installation, no LibreOffice, no external services needed
• Cross-platform — runs natively on macOS, Linux, and Windows
• Three interfaces — use as a CLI tool, Rust library (use dxpdf;), or Python package (import dxpdf)
• Unicode-aware — grapheme-correct segmentation, plus full-color emoji including ZWJ, skin-tone, keycap and flag sequences shaped through Skia's HarfBuzz
• Internationalised — UAX #14 line breaking (including Thai, Lao, Khmer and Burmese), UAX #9 bidirectional text, and CLDR-driven numbers and dates that follow the document's own w:lang
• Packaged — cargo install, pip install, or a .deb for Debian and Ubuntu
• ISO 29500 compliant — validated against the Office Open XML specification

Installation

Command-Line Tool

cargo install dxpdf

Debian / Ubuntu

Every release ships a .deb for amd64 and arm64:

curl -LO https://github.com/nerdy-pro/dxpdf/releases/download/v0.5.0/dxpdf_0.5.0-1_amd64.deb
sudo apt install ./dxpdf_0.5.0-1_amd64.deb

Installs dxpdf to /usr/bin with a dxpdf(1) man page, and recommends fonts-liberation2 — metric-compatible with Arial, Times New Roman and Courier New, so documents that ask for them lay out the way Word does.

Built on Debian 12, so it installs on Debian 12 and 13, Ubuntu 24.04 and newer, and their derivatives. Not yet in the Debian archive itself (#92): that needs a Skia that Debian packages, and there is not one.

Rust Library

Add to your Cargo.toml:

[dependencies]
dxpdf = "0.5.0"

Python Package

pip install dxpdf

Usage

CLI — Convert DOCX to PDF from the Terminal

dxpdf input.docx                  # produces input.pdf
dxpdf input.docx -o output.pdf    # specify output path
dxpdf input.docx --image-dpi 300  # embed images at 300 DPI (default 220; range 1–2400)

Embedded raster images are downsampled to --image-dpi pixels per inch (default 220, matching Word). Raise it for print-quality output (e.g. 300) or lower it for smaller files (e.g. 96); images are never upsampled past their source resolution.

Rust — Convert DOCX to PDF Programmatically

let docx_bytes = std::fs::read("document.docx")?;
let pdf_bytes = dxpdf::convert(&docx_bytes)?;
std::fs::write("output.pdf", &pdf_bytes)?;

To customize rendering — e.g. the embedded-image resolution (default 220 DPI) — use convert_with_options:

use dxpdf::RenderOptions;

let options = RenderOptions::default().with_image_dpi(300.0);
let pdf_bytes = dxpdf::convert_with_options(&docx_bytes, &options)?;

You can also inspect or transform the parsed document model before conversion:

use dxpdf::{docx, model, render};

let document = docx::parse(&std::fs::read("document.docx")?)?;

for block in &document.body {
    match block {
        model::Block::Paragraph(p) => { /* inspect paragraph content */ }
        model::Block::Table(t) => { /* inspect table structure */ }
        model::Block::SectionBreak(props) => { /* inspect section properties */ }
    }
}

let pdf_bytes = render::render(document, &dxpdf::RenderOptions::default())?;

Python — Convert DOCX to PDF in Python

import dxpdf

# Bytes in, bytes out
pdf_bytes = dxpdf.convert(open("input.docx", "rb").read())

# File path to file path
dxpdf.convert_file("input.docx", "output.pdf")

# Customize embedded-image resolution (default 220 DPI)
pdf_bytes = dxpdf.convert(open("input.docx", "rb").read(), image_dpi=300)
dxpdf.convert_file("input.docx", "output.pdf", image_dpi=300)

Supported DOCX Features

dxpdf handles the most common DOCX features found in real-world business documents, reports, and forms:

Performance Benchmarks

Measured on Apple M3 Max with hyperfine (30 runs, 5 warmup) at v0.5.0, against fixtures committed in test-files/ so the numbers are reproducible. Times are rounded to 5 ms — run-to-run spread on a normally loaded machine is around ±10 ms, so smaller differences are not meaningful:

Font resolution, not document size, decides what a conversion costs. Notice that the 9-page fixture converts in a third of the time the 3-page one does, though it carries forty times the input. The difference is entirely in how its fonts resolve.

The font registry is built in tiers and lazily. A document whose every font is embedded or already present on the host never reaches the expensive tier — sample1 spends ~4 ms there. One that has to fall back to the host metadata index, matching on PostScript and style names, pays ~120–185 ms, once, and that then dominates everything else it does: on sample3 the registry is roughly five times parse, layout, subsetting and painting put together. (Per-phase figures from RUST_LOG=debug, single runs with logging on, so read them as proportions rather than as timings.)

So the useful question for a batch workload is not how large the documents are but whether they name fonts the host has. Documents written by Word normally embed or name available faces and land on the fast side; the slow side is worth measuring for yourself before sizing anything.

To measure your own workload, run cargo bench for the Criterion suites, or use the release binary with RUST_LOG=debug for a per-phase breakdown of parse, resolve, registry, layout, subset and paint.

dxpdf is designed for batch processing, server-side conversion, and CI/CD pipelines.

Building from Source

Prerequisites

• Rust 1.95.0 — pinned via rust-toolchain.toml, so rustup selects it automatically

• clang (required by skia-safe for building Skia bindings)

• Linux only: libfontconfig1-dev and libfreetype-dev

  sudo apt-get install -y libfontconfig1-dev libfreetype-dev
  

Build

cargo build --release

The release binary will be at target/release/dxpdf.

The subset-fonts feature (font subsetting) is on by default; build with --no-default-features to skip it.

Run Tests

cargo test --all

Architecture

dxpdf follows a parse → resolve → layout → subset → paint pipeline, with a measure-then-position model inspired by Flutter's rendering approach:

DOCX (ZIP) → Parse → Document Model → Resolve → Layout → Subset → Paint → PDF
             Twips/Emu/HalfPoints        ←──── Pt throughout ────→      Skia

Type-safe dimensions flow through the entire pipeline: OOXML units (Twips, Emu, HalfPoints) are i64-backed in the parsed model so they round-trip losslessly, layout works in Pt (typographic points), and raw f32 appears only at the Skia rendering boundary.

1. Parse — declarative serde schemas over the DOCX XML parts, producing an immutable document model
2. Resolve — flatten the style cascade, split sections, pre-load images, generate shape geometry
3. Layout — measure text, fit lines, and position content into pages; runs first so total page count is known before headers/footers resolve PAGE/NUMPAGES
4. Subset — reduce each embedded typeface to the glyphs actually painted
5. Paint — emit draw commands in order (shading → content → borders) through Skia's PDF backend

Module Overview

OOXML Feature Coverage

Validated against ISO 29500 (Office Open XML). 74 entries fully implemented, 11 partial, 12 not yet supported.

Dependencies

Frequently Asked Questions

How do I convert a DOCX file to PDF?

Install dxpdf with cargo install dxpdf, then run dxpdf input.docx. The PDF will be created in the same directory. You can also specify an output path with -o output.pdf.

Does dxpdf require Microsoft Office or LibreOffice?

No. dxpdf is a standalone converter that reads DOCX files directly and renders PDF output using Skia. No Office installation or external service is needed.

Can I use dxpdf as a library in my Rust or Python project?

Yes. In Rust, add dxpdf as a dependency and call dxpdf::convert(&docx_bytes). In Python, install with pip install dxpdf and call dxpdf.convert(bytes) or dxpdf.convert_file("input.docx", "output.pdf").

What DOCX features are supported?

dxpdf supports text formatting, paragraphs, tables (including nested, merged and floating tables with conditional formatting), inline and floating images, shapes and text boxes, styles with inheritance, headers/footers, multi-level lists, hyperlinks and a navigable PDF outline, footnotes and endnotes, section breaks, and automatic pagination. See the full feature matrix above.

Notable gaps: Indic reordering, mirrored tab stops under w:bidi, automatic hyphenation, tracked changes and comments, and SmartArt and charts.

How fast is dxpdf?

On an Apple M3 Max the committed fixtures convert in 55–170 ms, and a 171-page, 14 MB document in about 420 ms. Document size matters less than you would expect: what dominates a small conversion is how its fonts resolve, since a document naming faces the host has to look up in its metadata index pays roughly 120–185 ms once, where one whose fonts are embedded or already present pays about 4 ms. See Performance Benchmarks for measured figures and how to benchmark your own workload.

What platforms does dxpdf support?

dxpdf runs on macOS, Linux, and Windows. On Linux, you need libfontconfig1-dev and libfreetype-dev installed.

Used By

• nerdy.pro
• formtastic.de

Contributing

Contributions are welcome. Please open an issue before submitting large PRs.

Build commands and project conventions are in AGENTS.md.

Before opening a PR, run what CI runs:

cargo fmt --all -- --check
cargo clippy --all-targets -- -D warnings
cargo test --all

Built by nerdy.pro.

License

MIT