Generate PDFs in Docker with .NET
A plain .NET runtime image is enough to generate PDFs with DocToolkit. This guide names the image to use, the one to avoid, and why the PDF is smaller in a slim image with no fonts installed.
FROM mcr.microsoft.com/dotnet/runtime:8.0Nothing extra to install
- The library needs no native binaries, so a plain .NET runtime image is enough.
- There is nothing to
apt-get installand no LibreOffice layer.
Use runtime, not runtime-deps
- Use
runtime, notruntime-deps. - The
runtime-depsimage carries the native dependencies of the .NET runtime but not the runtime itself. It is for self-contained publishes. - A framework-dependent app copied into
runtime-depsfails at startup, not at build time.
Fonts in a slim image
- A slim image has no fonts installed, and that changes the PDF you get.
- On a dev machine with system fonts, the font is embedded in the PDF. The same invoice is about 167 KB, carrying Arial-Regular and Arial-Bold.
- In a slim container with no fonts, the PDF falls back to the base-14 standard fonts (Helvetica). The same invoice is about 1.5 KB, embedding nothing.
- Both are valid PDFs and both render. Arial and Helvetica are metric-compatible, so line breaks do not move, but the glyphs are not identical.
Checked with no network
- The Container sample is built and run in CI with
--network none. - That is how the offline claim stays true rather than remaining an assertion in a README.
What it will not do
- A PDF built in your container will never be byte-identical to one built on your laptop. Do not assert on PDF byte size or hash across environments.
- If you need a specific typeface, install it in the image.
- Non-Latin text depends on the host's fonts unless you supply them.
PdfFontOptionscovers DOCX, HTML, XLSX and PPTX to PDF; Markdown to PDF does not accept it.