# PyMuPDF for all PDF access, accepting AGPL

All PDF work — rasterizing at a chosen DPI, exporting SVG, and inspecting page
content to classify a source as bitmap or vector — goes through **PyMuPDF**. It
is a single wheel with MuPDF bundled, so the tool needs no system packages. Its
licence is **AGPL-3.0**, which we accept.

## Why not the permissive combination

The obvious permissive stack was `pypdfium2` (Apache/BSD) for rasterizing plus
`mutool` or `pdftocairo` shelled out for SVG. Both of those are **system
packages** — `mupdf-tools`, `poppler` — and a system package on the vector path
is precisely the failure the language choice was made to avoid: the tool is
supposed to install once and run from any directory on any machine.

The SVG step can't simply be skipped, either. Music glyphs come from a notation
font (Emmentaler, Bravura, or Sibelius/Finale's). An SVG that *references* a font
renders as garbage on a device that lacks it, so text must be converted to paths
at export. PyMuPDF does this **by default** — `page.get_svg_image(text_as_path=1)`,
verified to emit `<path>` elements and zero `<text>` — so the font risk is closed
with no extra tooling.

Mixing the two (pypdfium2 for raster, PyMuPDF only for SVG) is the worst option:
two libraries with overlapping responsibilities, and AGPL linked in anyway.

## Consequences

- **The AGPL propagates only if the slicer is published.** For a local personal
  tool it costs nothing. A future permissive release would need the rasterizer
  swapped back to `pypdfium2` — a contained change, since PDF access sits behind
  the renderer-agnostic geometry model.
- **Source-type detection comes free** from the same library: `get_images()` plus
  a full-page-image area check distinguishes a scan from an engraving.
- The SVG export path is present and working even though the SVG *renderer* is
  deferred — see
  [ADR 0002](0002-raster-only-svg-renderer-deferred.md).