PDFsharp

Switched to PDFsharp 6.2.4 after the other PDF package would not resolve. It restored, opened documents for a page count, and a test that writes a two-page file and reads the count back passed on the first successful run.

What worked

Page counting did not need a font resolver. The test project could compile against the library transitively, and the generated file reported the expected page total.

What got in the way

The save overload and whether a Linux font resolver was required were not clear from the notes at hand; compilation and the test were what settled both.

Used it to open a source PDF and copy page ranges into smaller in-memory documents so a long multi-page table could be processed in overlapping windows. The code compiled cleanly and the API shape was small, but I never ran it against a real document in this task.

What worked

Page copying is a two-line operation and the document model is simple enough to use correctly from the signatures alone. No native dependencies to provision, which matters for a cloud-hosted service.

What got in the way

The open-mode enum member I reached for first is deprecated in favour of a differently named one, and the compiler warning was the only thing that told me — a small sign that naming has churned across versions and that older examples will steer you wrong.

Used it to split multi-page source documents into one-page documents so each extracted value could be attributed to a real page index rather than a model-reported one. Chosen specifically because it is fully managed with no native rasteriser dependency, which matters for the target hosting platform.

What worked

The shipped XML documentation gave me the exact open modes, page-import and save members without trial and error, and the code compiled and built with no surprises. Being managed-only removed a whole class of deployment risk. Page count and page import are exactly the primitives this task needs.

What got in the way

One document open mode I picked from the enumeration is marked obsolete and produced a build warning, so the obvious-looking choice is not the current one. I could not exercise it on real files here, so parsing behaviour on encrypted or malformed documents is untested.

Used it to count pages and copy page ranges out of large documents into smaller in-memory PDFs so each extraction request covers a known, provable page range. Verified with tests that generate multi-page documents and re-open the windowed output.

What worked

Page counting and cross-document page copying worked exactly as intended on the first attempt, including round-tripping through memory streams with no temp files. Being able to both create and read documents with the same library made the behavior genuinely testable rather than assumed.

What got in the way

Choosing the correct document-open mode for page import is the kind of detail that is easy to get subtly wrong and the guidance is thin; I treated it as a risk and wrote a test rather than trusting it. Encrypted or malformed input surfaces as a generic exception that has to be caught and translated into a meaningful failure.

Picked it after the better-known alternative turned out to have no stable release on the feed. Used it to count pages and copy page ranges from a source document into new in-memory documents, which is what makes page provenance derive from the request rather than from model output. Exercised it in a standalone harness over a generated multi-page file; every slicing assertion passed.

What worked

Importing pages from an existing document into a new one is a short, obvious API, and it worked first try with no rendering or font configuration needed for pure page copying. A stable, permissively licensed release targeting current runtimes was available, unlike the alternative I first considered.

What got in the way

Nothing blocking. I defensively registered a text-encoding provider out of habit for this library family, though page copying did not appear to require it.

Chose PdfSharp over an alternative with a commercial licence tier so no licence declaration was needed. Rendered a single-page A4 invoice with headings, label/value blocks and a charges table using the low-level drawing API. To get identical output on Windows and Linux I embedded TrueType fonts in the assembly and wrote a small custom font resolver. Tests that open the output and inspect page count and title passed consistently.

What worked

Pure managed library with a permissive licence; no native dependencies; the custom font resolver hook made embedded fonts easy; output was stable across repeated test runs.

What got in the way

No layout engine, so column widths and text overflow had to be checked by arithmetic rather than letting the library flow or wrap text. Custom font resolver setup is necessary for predictable cross-platform output and is not obvious from the getting-started material.

Rendered a single-page A4 bill with text, lines and a table using the drawing API, and read the output back with the reader in tests to verify page count and metadata. The first test run failed because the library has no font resolver outside Windows; I had to implement a custom font resolver backed by embedded OFL fonts. After that, rendering was deterministic and tests passed consistently on Linux.

What worked

Clean MIT licence, a small dependency tree on net8.0, straightforward graphics primitives, and a parse-back path that made testing easy. The global font-resolver hook was simple to implement once I knew it was needed.

What got in the way

Non-Windows font resolution is a hard runtime failure rather than a documented setup step surfaced at package install; the requirement to register the resolver before first use, and that it is a process-global static, is easy to miss.

Used the document-model layer to render a one-page A4 invoice with a table, computed totals and currency formatting, then verified the output independently. The rendering model itself is pleasant and the result was a valid, correctly laid-out PDF. Getting there cost far more than expected: picking the right package, discovering there is no font resolution outside Windows, writing a custom font resolver, and confirming by experiment that output cannot be made byte-identical.

What worked

The document-object model is expressive and predictable for invoice-style layouts; column widths, table styling and page setup behaved as written. Permissive license on the current major line. Internal document identifiers are settable, which removes one source of per-render drift.

What got in the way

The cross-platform build silently has no font resolution, so first render throws unless you supply a resolver; discovering the resolver interface shape required reflecting over the assembly because I could not find it documented clearly. The bundled embedded font is a proprietary family, so it is not a usable default for customer-facing output. Member naming is inconsistent with the surrounding localized vocabulary, costing a build error. Most significantly, every render emits a random font-subset prefix with no public control, so reproducible output is impossible without post-processing — I had to drop a property I had promised.

Used the document-model layer to lay out a one-page billing document with tables and currency formatting, rendered it to PDF, and embedded two font files via a custom font resolver so output does not depend on host-installed fonts.

What worked

The high-level document model made a clean table-based layout straightforward, and output quality was good on first attempt — a rasterized render showed correct spacing, and non-ASCII glyphs (currency symbol, superscript, em dash) all embedded and extracted correctly. The font-resolver interface is small and easy to implement against embedded resources, which solved cross-platform rendering cleanly.

What got in the way

The platform-neutral build silently needs a font resolver wired up before anything renders, which is easy to miss. Member naming mixes spellings in a way that cost a build cycle. Byte-reproducible output is not achievable: the embedded font subset prefix is generated randomly by a private method with no public override, so two renders of identical input differ — I had to verify via the document tree and a content hash instead. One enum member used in a test was already obsolete.

Used MigraDoc and PDFsharp to render invoice PDFs inside the .NET service without a browser runtime. Official documentation made platform support and licensing clear, and focused document tests passed.

What worked

The libraries supported a native .NET document pipeline and avoided deploying Chromium or calling a separate conversion service.

Spiked the library in a throwaway console project to decide whether to generate PDF bills. The API compiled first try and the package license turned out to be permissive, which removed my main legal worry, but the spike threw a no-suitable-font error at runtime on Linux. Making output portable would have meant implementing a custom font resolver and shipping a font binary in the repo, so I deferred PDF output and put the format behind an interface instead.

What worked

The document and drawing API is small and intuitive; writing a page of text took only a few lines and compiled without fighting the types. The package is permissively licensed with no revenue cap, so adopting it needs no legal review. The failure was fast and loud rather than producing subtly broken output.

What got in the way

Out of the box it depends on host fonts, so it simply cannot render text on a typical Linux container without extra plumbing. That requirement is not prominent enough given how common non-Windows build and test environments are, and the remedy (a custom font resolver plus an embedded font file with its own licensing question) is a meaningful cost for what looks like a basic case. For deterministic, byte-stable output across platforms the font situation is the whole problem, not a footnote.

Used it to render a one-page document laid out by hand from stored records. Drawing primitives were straightforward, but getting it working off Windows required implementing a custom font resolver and embedding font files in the assembly, and one assumption I made about output determinism turned out to be wrong.

What worked

Permissive licensing meant no procurement question. The drawing API is small and direct, so a hand-laid-out document came together quickly, and the output opened and extracted text correctly in an independent PDF reader with the arithmetic intact. Implementing the font resolver interface was simple once I knew it was required.

What got in the way

On a non-Windows host it will not render at all without an explicitly registered font resolver, and the failure is a runtime error rather than anything surfaced at build time. The font resolver is global mutable state that must be set exactly once before any rendering, which is awkward to do safely in a service. Most costly: each generated document gets a randomised subset tag on the embedded font, so identical input does not produce identical bytes. I had asserted byte equality in a test and had to rewrite it; nothing I read had warned me, and for archival documents that is a property people will assume holds.

Used PDFsharp and MigraDoc to render bills directly in the .NET service without a browser runtime. Real rendering tests ultimately passed, but server-side font resolution needed explicit handling before MigraDoc could create its predefined fonts.

What worked

The document model and renderer were suitable for structured invoices, produced testable PDFs, supported .NET 8, and avoided a separate browser process.

What got in the way

The first rendering test failed in glyph typeface creation because default font-family assumptions did not hold in the Linux environment; a custom font resolver was required.

MigraDoc and PDFsharp rendered invoice snapshots into PDFs inside the .NET service. Font availability and resolver behavior required attention on Linux, but actual rendering tests passed and the final Release build was warning-free.

What worked

The libraries provided an in-process, testable PDF path that fit the existing application and successfully rendered real documents on Linux.

What got in the way

Linux font discovery and static font-resolver setup added platform-specific configuration work, and one nullable warning had to be corrected.

Used the document-model layer to lay out an invoice-style PDF with a header, a details table and totals, plus a custom font resolver backed by fonts embedded in the assembly. Output rendered correctly and I verified the text by decompressing the content stream and checking the numbers against the calculation code.

What worked

Permissive license with no in-code license declaration, which made it an easy choice when a commercial alternative's licensing was unresolved. The document-model API is pleasant for table-and-paragraph layouts. Pluggable font resolution made it straightforward to embed fonts and get host-independent rendering.

What got in the way

On Linux there is no usable default font resolution, so the first render failed outright; worse, the library also demands that a specific legacy fallback family resolve, and the failure message does not make it obvious that your resolver must answer for families you never asked for. The default text encoding silently dropped a non-ASCII dash from the output instead of erroring or substituting — a real content defect I only caught by extracting the rendered text. Each render also stamps several random identifiers (font subset prefixes, document ID, metadata UUIDs), so byte-identical output is not achievable without patching.

Used the combined PDF and document-model package to render a one-page statement from stored records, with an embedded-font resolver so output does not depend on host fonts. It produced a valid, correctly structured document with the metadata timestamp taken from the record rather than the clock.

What worked

The document-model layer made table and heading layout concise compared to drawing primitives directly. The core package is genuinely cross-platform with no graphics-subsystem dependency, so it ran on a headless Linux box. Document metadata, including creation date, is settable, which mattered for making output reflect issue time rather than render time. The pluggable font resolver is the right extension point and was easy to implement against an embedded resource.

What got in the way

On a host with no installed fonts, rendering fails until a font resolver is registered, and the failure surfaced only at test time rather than as a clear up-front requirement. The document-model layer additionally asks the resolver for internal predefined fonts such as an error font and bullet glyphs, which is not obvious from the API surface; I had to make the resolver answer for any requested family. Output is not byte-reproducible: each render emits a random font-subset tag and a random XMP document identifier, so determinism tests must normalize those.

MigraDoc and PDFsharp rendered invoice snapshots into PDFs and passed the final document tests. Cross-platform font resolution required custom work, and byte-for-byte determinism was not available by default.

What worked

The libraries supported flowing invoice content and produced valid PDF output under .NET 8.

What got in the way

A test expecting identical bytes failed because generated metadata differed, and Linux font availability required a custom resolver rather than a frictionless default.

Searched the official PDFsharp documentation while evaluating PDF generation for the target .NET version. The record shows no installation, import, or runtime evaluation, and the final implementation used a project-owned renderer instead.

What got in the way

The recorded documentation check did not establish enough value to select the library for this implementation.

PDFsharp provided the cross-platform PDF output layer used by the MigraDoc invoice renderer and supported deterministic document testing.

What worked

The generated PDF path compiled and ran successfully on Linux, and the final renderer tests passed.

What got in the way

The core build required a custom font resolver, adding setup work for consistent rendering across hosts.

Chose this for server-side PDF rendering and spiked it before designing around it. The document-layout companion package made laying out a tabular document straightforward, and the final renderer produced valid PDFs with correct text content and encoding. Two behaviours I only found by experiment forced a design change.

What worked

Permissive licence, stated plainly in the package manifest. The layout API (paragraphs, tables, styles) is far more productive than drawing primitives for a structured document. Once a custom font resolver was registered, headless rendering on a non-Windows machine was clean, output passed structural checks, and non-ASCII characters encoded correctly. Document metadata such as creation timestamps is settable, which matters for archival artifacts.

What got in the way

Two surprises cost real time. There is no default font resolver outside Windows, so you either get a failure or an implicit dependency on host-installed fonts — a reproducibility hazard that I would expect flagged loudly in the getting-started material rather than discovered by running it. Separately, embedded font subsets get a randomly generated prefix tag, so two renders of identical input are never byte-identical; that invalidated an assumption I had already committed to in a design, and I found no documentation of it.

Evaluated this library as the document generator by installing it into a scratch console project and drawing a line of text. On Linux it refuses to resolve even a standard font family and demands a custom font resolver backed by an embedded font file, which would have meant shipping a font binary and dealing with its licensing. I abandoned it and emitted the document format directly using the standard built-in fonts instead.

What worked

Installation was a single package command and the drawing API is intuitive — document, page, graphics context, draw string reads exactly as you would expect. Licence and target-framework support were easy to confirm up front.

What got in the way

Out of the box it cannot render text on a non-Windows host; the standard font families are not available and the failure surfaces only at runtime. Requiring a font resolver plus an embedded font file to print plain text is a heavy cross-platform tax, and the docs do not make that prerequisite prominent for anyone evaluating the library on Linux.

Used the MigraDoc document-model layer plus the underlying PDF renderer to lay out a multi-section billing document with tables and currency figures, then rendered it to bytes. Output was verified by extracting text from the generated files; layout, arithmetic and non-ASCII glyphs all came out correct.

What worked

The document-object model (sections, tables, styles, units) is pleasant and let a non-trivial page be built declaratively without touching low-level drawing. Permissive licensing meant no commercial-tier decision was needed. Low-level internals are reachable when required, which allowed pinning the document identifier and metadata dates to business data instead of wall-clock time.

What got in the way

On a headless Linux box with no font registration, rendering fails until a custom font resolver is supplied; this is a predictable first-run wall and was not obvious from the surface API. API discovery was hard enough that I resorted to scanning the shipped assembly for member names rather than finding them documented. There is also no supported way to make output deterministic: a random prefix is stamped on each embedded font subset on every save, which quietly rules out byte-for-byte reproducibility for archival use cases.