Back to PD4ML Home
Documentation page: SVG to PDF Conversion. This page is also available as Markdown at svg-to-pdf-conversion.md.

SVG to PDF Conversion

PD4ML has parsed and rendered embedded SVG vector graphics since v3.8.5, covering the basic SVG shape model, matrix transforms, transparency, and stroke/fill styling. SVG can appear in a source document either referenced through an ordinary <img> tag or written inline as raw <svg> markup, and either form converts as part of the surrounding page like any other content.

DOCX output embeds SVG natively as vector graphics. The experimental v42 rendering engine does not implement SVG yet. Both are covered below.

Referencing vs. inlining SVG

An external SVG file behaves like any other image reference:

<img align=right border="1" src="chart.svg" width="300" style="background-color: tomato; page-break-inside: avoid">

Or the SVG markup can be embedded directly in the HTML source, mixed with ordinary content:

<svg width="200" height="150" xmlns="http://www.w3.org/2000/svg" version="1.1">
  <g fill="none" stroke="black" stroke-width="4">
    <path stroke-dasharray="5,5" d="M5 20 l215 0" />
    <path fill="none" stroke-dasharray="10,10" d="M5 40 l215 0" />
    <path stroke-dasharray="20,10,5,5,5,10" d="M5 60 l215 0" />
  </g>
</svg>

Two rendering backends

PD4ML ships two independent SVG renderers. If Apache Batik is present on the classpath, PD4ML uses it first, for Batik's broader SVG specification coverage; if Batik isn't available (or has been explicitly disabled), PD4ML falls back to its own bundled, lightweight SVG parser -- the one the support table below describes. Setting PD4ML.disableBatik = true forces the bundled parser even when Batik is on the classpath, which is worth doing deliberately for a smaller deployment footprint if Batik's extra coverage isn't needed.

What's supported

SVG element Support
<svg> Supported; nested <svg> elements are not.
<style> Supported; some complex CSS selector types aren't yet.
<text> Supported
<tspan> Partially supported
<defs> Supported
<g> Supported
<symbol> Partially supported
<use> Supported
<rect> Supported
<line> Supported
<circle> Supported
<ellipse> Supported
<polygon> Supported
<polyline> Supported
<path> Supported
<title> Ignored
<desc> Ignored
<metadata> Ignored
<linearGradient> / <radialGradient> / <stop> Partially supported: gradients render when converting to a raster image, but not yet when converting to PDF.
<pattern> Ignored
<clipPath> Supported

This table describes the bundled parser specifically; the Batik backend, when active, follows Batik's own (considerably broader) SVG support instead.

Output-format notes

  • PDF -- the primary, fully supported target, as above.
  • DOCX -- PD4ML embeds SVG images in a DOCX output as genuine vector graphics, via the same asvg:svgBlip DrawingML extension Microsoft Office itself uses (Office 2016+), rather than rasterizing them first.
  • RTF -- the original caveat here ("HTML+SVG-to-RTF conversion is planned for later") doesn't appear to have been superseded by anything comparable to the DOCX support above; treat SVG content in RTF output as not guaranteed to survive as vector graphics.
  • Raster images (renderAsImages()) -- supported under PD4ML's default rendering path, the same one used for PDF/RTF/DOCX. Separately, a newer rendering engine exists that's opted into explicitly via useHtmlRenderer(Constants.LayoutEngine.v42, ...); as of this writing it doesn't render SVG content at all (silently skipping it, the same way any other unsupported element would be) and doesn't yet implement PDF/RTF/DOCX output either -- relevant only to a codebase that has deliberately selected it, not to ordinary renderAsImages() usage.

Examples

Two worked examples from the original cookbook page, still hosted on old.pd4ml.com:

See also