Export functionality is one of the most underestimated architectural concerns in desktop applications.<\/p>\n\n\n\n
Most systems begin with a simple requirement:<\/p>\n\n\n\n
\n\u201cWe need a PDF export.\u201d<\/p>\n<\/blockquote>\n\n\n\n
The first implementation is usually straightforward. A developer generates a PDF directly from a button click, manually builds tables, fetches data inline, and writes the file to disk.<\/p>\n\n\n\n
Initially, this works.<\/p>\n\n\n\n
But over time, export requirements grow:<\/p>\n\n\n\n
\n
- multiple export formats<\/li>\n\n\n\n
- optional columns<\/li>\n\n\n\n
- localization<\/li>\n\n\n\n
- branding<\/li>\n\n\n\n
- customer-specific layouts<\/li>\n\n\n\n
- background exports<\/li>\n\n\n\n
- preview support<\/li>\n\n\n\n
- email attachments<\/li>\n\n\n\n
- audit requirements<\/li>\n<\/ul>\n\n\n\n
At that point, the export feature stops being \u201cjust a utility\u201d and becomes a subsystem.<\/p>\n\n\n\n
This article explores how Chrona approaches PDF export architecture using:<\/p>\n\n\n\n
\n
- Strategy Pattern<\/li>\n\n\n\n
- dependency injection<\/li>\n\n\n\n
- QuestPDF<\/li>\n\n\n\n
- repository abstraction<\/li>\n\n\n\n
- layout orchestration<\/li>\n\n\n\n
- pre-render caching<\/li>\n\n\n\n
- UI-independent export pipelines<\/li>\n<\/ul>\n\n\n\n
The goal is not only to generate PDFs, but to build an export architecture that remains maintainable as complexity grows.<\/p>\n\n\n\n
\n\n\n\nWhy Export Logic Often Becomes Fragile<\/h1>\n\n\n\n
Many desktop applications implement exports directly in the UI layer.<\/p>\n\n\n\n
Typical examples:<\/p>\n\n\n\n
private void ExportButton_Click(object sender, RoutedEventArgs e)\n{\n var report = _repository.Load(...);\n\n var pdf = new PdfDocument();\n\n \/\/ render content\n\n pdf.Save(\"report.pdf\");\n}\n<\/code><\/pre>\n\n\n\nThis approach works for prototypes, but it creates long-term architectural problems.<\/p>\n\n\n\n
The UI becomes responsible for:<\/p>\n\n\n\n
\n
- data retrieval<\/li>\n\n\n\n
- formatting<\/li>\n\n\n\n
- layout decisions<\/li>\n\n\n\n
- export orchestration<\/li>\n\n\n\n
- filesystem handling<\/li>\n\n\n\n
- PDF library interaction<\/li>\n<\/ul>\n\n\n\n
Over time, the export logic grows into a large procedural block that becomes difficult to extend safely.<\/p>\n\n\n\n
Adding optional columns or supporting additional export formats usually leads to more branching logic and tighter coupling.<\/p>\n\n\n\n
Chrona takes a different approach.<\/p>\n\n\n\n
The export behavior is isolated behind a dedicated strategy implementation.<\/p>\n\n\n\n
\n\n\n\nStrategy Pattern for Export Pipelines<\/h1>\n\n\n\n
Chrona models PDF export as its own export strategy.<\/p>\n\n\n\n
The strategy encapsulates:<\/p>\n\n\n\n
\n
- PDF-specific layout logic<\/li>\n\n\n\n
- rendering behavior<\/li>\n\n\n\n
- formatting rules<\/li>\n\n\n\n
- document orchestration<\/li>\n<\/ul>\n\n\n\n
This keeps export concerns separate from:<\/p>\n\n\n\n
\n
- view models<\/li>\n\n\n\n
- UI workflows<\/li>\n\n\n\n
- repository orchestration<\/li>\n\n\n\n
- application startup<\/li>\n<\/ul>\n\n\n\n
The constructor already reflects this architecture clearly.<\/p>\n\n\n\n
public PdfExportStrategy(\n IProjectRepository projectRepository,\n IBookingCodeRepository bookingCodeRepository,\n ISettingsService settingsService)\n{\n _projectRepository = projectRepository;\n _bookingCodeRepository = bookingCodeRepository;\n _settingsService = settingsService;\n\n QuestPDF.Settings.License = LicenseType.Community;\n}\n<\/code><\/pre>\n\n\n\nSeveral important design decisions are visible here.<\/p>\n\n\n\n
First, the strategy depends on interfaces instead of concrete implementations. This keeps the exporter testable and replaceable.<\/p>\n\n\n\n
Second, data access happens through repositories rather than directly through UI state or database access.<\/p>\n\n\n\n
Third, PDF-library-specific configuration remains localized inside the export strategy instead of leaking into application startup or view models.<\/p>\n\n\n\n
That separation matters because export infrastructure evolves independently from presentation logic.<\/p>\n\n\n\n
\n\n\n\nWhy QuestPDF Fits This Architecture Well<\/h1>\n\n\n\n
One of the strongest aspects of Chrona\u2019s export pipeline is the use of QuestPDF.<\/p>\n\n\n\n
Traditional PDF generation libraries often rely heavily on coordinate-based rendering:<\/p>\n\n\n\n
graphics.DrawText(..., x, y);\ngraphics.DrawRectangle(...);\n<\/code><\/pre>\n\n\n\nThis becomes difficult to maintain as layouts evolve.<\/p>\n\n\n\n
QuestPDF uses a declarative layout approach instead.<\/p>\n\n\n\n
The document structure reads like document intent.<\/p>\n\n\n\n
Chrona creates documents like this:<\/p>\n\n\n\n
var document = Document.Create(container =>\n{\n container.Page(page =>\n {\n page.Size(PageSizes.A4);\n page.Margin(2, Unit.Centimetre);\n page.DefaultTextStyle(x => x.FontSize(10));\n\n page.Header()\n .PaddingBottom(15);\n });\n});\n<\/code><\/pre>\n\n\n\nThe footer follows the same pattern:<\/p>\n\n\n\n
page.Footer()\n .AlignCenter()\n .Text(x =>\n {\n x.Span(\"Seite \").FontSize(8);\n x.CurrentPageNumber().FontSize(8);\n x.Span(\" von \").FontSize(8);\n x.TotalPages().FontSize(8);\n });\n<\/code><\/pre>\n\n\n\nThis is significantly more maintainable than coordinate-driven rendering.<\/p>\n\n\n\n
The layout is expressed structurally:<\/p>\n\n\n\n
\n
- page<\/li>\n\n\n\n
- header<\/li>\n\n\n\n
- content<\/li>\n\n\n\n
- footer<\/li>\n<\/ul>\n\n\n\n
Instead of manually calculating positions for every visual element.<\/p>\n\n\n\n
That becomes especially valuable once reports become dynamic.<\/p>\n\n\n\n
\n\n\n\nComparing PDF Rendering Approaches<\/h1>\n\n\n\n
QuestPDF\u2019s declarative model is fundamentally different from classic PDF-generation styles.<\/p>\n\n\n\n
Coordinate-Based Rendering<\/h2>\n\n\n\n
Libraries such as older PDF toolkits often work like this:<\/p>\n\n\n\n
graphics.DrawString(text, font, brush, x, y);\n<\/code><\/pre>\n\n\n\nAdvantages:<\/p>\n\n\n\n
\n
- extremely precise control<\/li>\n\n\n\n
- useful for fixed forms<\/li>\n\n\n\n
- predictable rendering positions<\/li>\n<\/ul>\n\n\n\n
Disadvantages:<\/p>\n\n\n\n
\n
- hard to maintain<\/li>\n\n\n\n
- fragile during layout changes<\/li>\n\n\n\n
- difficult with dynamic content<\/li>\n\n\n\n
- manual pagination complexity<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nHTML-to-PDF Rendering<\/h2>\n\n\n\n
Another common approach is HTML rendering.<\/p>\n\n\n\n
Advantages:<\/p>\n\n\n\n
\n
- easy for web developers<\/li>\n\n\n\n
- CSS styling<\/li>\n\n\n\n
- reusable templates<\/li>\n<\/ul>\n\n\n\n
Disadvantages:<\/p>\n\n\n\n
\n
- inconsistent rendering engines<\/li>\n\n\n\n
- browser dependency<\/li>\n\n\n\n
- print-layout unpredictability<\/li>\n\n\n\n
- harder desktop integration<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nQuestPDF\u2019s Declarative Layout<\/h2>\n\n\n\n
QuestPDF sits between both worlds.<\/p>\n\n\n\n
Advantages:<\/p>\n\n\n\n
\n
- layout-oriented instead of coordinate-oriented<\/li>\n\n\n\n
- strongly typed C#<\/li>\n\n\n\n
- deterministic rendering<\/li>\n\n\n\n
- composable structure<\/li>\n\n\n\n
- excellent for reports\/tables\/documents<\/li>\n<\/ul>\n\n\n\n
Trade-offs:<\/p>\n\n\n\n
\n
- learning curve<\/li>\n\n\n\n
- less raw pixel-level control<\/li>\n\n\n\n
- deeply nested layouts can become verbose<\/li>\n<\/ul>\n\n\n\n
For business-report-style exports, Chrona\u2019s architecture benefits strongly from this model.<\/p>\n\n\n\n
\n\n\n\nLicensing Considerations<\/h1>\n\n\n\n
Why PDF Libraries Are an Architectural Decision<\/h2>\n\n\n\n
Once a desktop application becomes a real product, PDF generation is no longer just a technical concern. Licensing becomes part of the architecture decision.<\/p>\n\n\n\n
That explicit configuration is important because QuestPDF uses a hybrid licensing model. According to the official licensing guide, the Community license is free for:<\/p>\n\n\n\n
\n
- individuals<\/li>\n\n\n\n
- non-profits<\/li>\n\n\n\n
- open-source projects<\/li>\n\n\n\n
- organizations below $1M annual gross revenue<\/li>\n<\/ul>\n\n\n\n
Larger organizations require a commercial license depending on the number of developers using QuestPDF. (QuestPDF<\/a>)<\/p>\n\n\n\n
One strong aspect of QuestPDF\u2019s licensing approach is that functionality is not artificially restricted between tiers. The same rendering engine and features are available across Community, Professional, and Enterprise licensing. (QuestPDF<\/a>)<\/p>\n\n\n\n
Architecturally, this matters because it avoids \u201cfeature fragmentation\u201d between environments. A team does not need separate implementations for development versus production capabilities.<\/p>\n\n\n\n
QuestPDF also avoids runtime activation mechanisms:<\/p>\n\n\n\n
\n
- no license keys<\/li>\n\n\n\n
- no online activation server<\/li>\n\n\n\n
- no runtime internet dependency<\/li>\n<\/ul>\n\n\n\n
This is particularly valuable for desktop applications, CI\/CD pipelines, offline deployments, and enterprise environments with restricted outbound connectivity. (QuestPDF<\/a>)<\/p>\n\n\n\n
Compared to other PDF approaches, the trade-offs become clearer.<\/p>\n\n\n\n
Traditional commercial reporting suites such as Telerik or Syncfusion often provide large ecosystems and enterprise tooling, but introduce vendor lock-in and recurring licensing cost.<\/p>\n\n\n\n
HTML-to-PDF engines such as IronPDF simplify HTML rendering workflows, but usually rely on embedded browser infrastructure and commercial licensing models. (IronPDF<\/a>)<\/p>\n\n\n\n
Older coordinate-based libraries such as PdfSharp or low-level PDF APIs provide permissive licensing and fine-grained control, but require significantly more manual layout logic.<\/p>\n\n\n\n
QuestPDF occupies a middle position:<\/p>\n\n\n\n