pdfforge/pdfcreator

1. Product shape

PDFCreator is a Windows desktop application that behaves like a virtual printer. Print jobs arrive through the Windows print spooler and are turned into PDF or other output formats, then optionally routed to viewers, mail, cloud storage, FTP/HTTP endpoints, or other post-processing actions.

2. Top-level solution boundaries

The repository is split into Source/Application for runtime code, Source/Setup for installer-related tooling, Source/Languages for gettext-based localization, Source/WebViewer for a separate viewer app, and a COM Scripts area with language-specific automation examples and test harnesses.

3. Startup and edition entry points

Source/Application/Startup decides how the app is launched: normal UI startup, direct conversion, drag-and-drop, merge mode, print-file mode, or piped/queued startup. Source/Application/Editions contains edition-specific bootstraps, with PDFCreator being the main executable and EditionBase providing shared startup infrastructure.

4. Core runtime orchestration

Source/Application/Core is the central runtime layer. It coordinates controller logic, job queues, workflow execution, printing integration, direct conversion, communication, service location, settings management, logging, licensing, update checks, usage statistics, and error reporting. Most higher-level features depend on this layer rather than talking directly to Windows or conversion engines.

5. Job-centric architecture

The system is organized around a Job/JobInfo model. Incoming print jobs are represented, enriched with metadata, queued, and processed through workflow objects. The job pipeline is managed by components such as JobInfoQueue, Workflow, JobRunner, JobBuilder, and JobCleanUp, with progress and completion events exposed to the UI.

6. Print-spooler and COM integration

There is a strong Windows integration boundary around printing and COM. Core/Printing handles printer discovery, ports, and print-command construction; Core/ComImplementation and UI/COM provide COM-facing adapters; UI/ComWrapper exposes wrapper objects for automation. This is how external apps and legacy scripts can drive PDFCreator.

7. Conversion engine layer

Source/Application/Conversion contains the conversion subsystem. It includes abstract interfaces, a Ghostscript-based converter stack, PDF/text/image output devices, and helper code for merge, OCR-adjacent image handling, printing, and file conversion. Ghostscript is the main rendering/conversion backend, while iText-related interfaces support PDF manipulation tasks like signing, watermarking, stamping, encryption, page numbers, and merging.

8. Action pipeline

A major architectural feature is the action framework under Conversion/Actions. Actions are composable steps applied to a job before or after conversion: cover, background, attachment, watermark, stamp, page numbers, signing, encryption, open-file, printing, scripting, mail, cloud upload, and forwarding to another profile. ActionManager and related helpers control ordering and execution.

9. Profiles and settings

Source/Application/Conversion/Settings and Source/Application/Core/SettingsManagement define the profile-driven configuration model. Profiles describe output format, metadata, passwords, page layout, destination actions, and business features. Settings are loaded from persisted storage, upgraded across versions, optionally overridden by group policy, and surfaced through UI view models.

10. Interactive WPF UI

Source/Application/UI/Presentation is the main WPF shell. It uses Prism and SimpleInjector for navigation and dependency injection, with a large MVVM surface composed of views, view models, commands, interactions, and overlays. The UI hosts the main shell, print-job shell, profile editor, settings pages, update prompts, feedback window, and specialized dialogs.

11. Workflow and user interaction loop

The presentation layer wraps the core job workflow in interactive assistants. It handles password prompts, save/overwrite decisions, profile validation, quick actions, update notices, email collection hints, and error recovery. This layer bridges automated processing with user decisions when the workflow cannot proceed unattended.

12. External services and integrations

Several subsystems connect outward: Dropbox, OneDrive, SharePoint, FTP/SFTP, HTTP upload endpoints, SMTP mail, Microsoft Graph/web mail, and Outlook COM attachment support. Additional infrastructure includes update downloads, usage statistics, Sentry-based error reporting, licensing checks, and RSS/feed content in the UI.

13. Shared utility foundation

Source/Application/Utilities provides cross-cutting helpers for files, paths, tokens, registry, process launching, threading, Windows API calls, spooler repair, and update/user-guide support. Many higher-level modules depend on this package for environment-specific behavior and filesystem/process safety.

14. Localization and packaging

Source/Languages holds translations in gettext .po files, which are consumed by the app’s translation helpers. Source/Setup contains helper code for installer/bootstrap scenarios, while the checked-in nuget-feed folder indicates the repo is designed to build mostly offline from pinned package artifacts.

15. Ancillary tooling and examples

COM Scripts contains small samples in C#, VB.NET, C++, VBScript, JavaScript, Python, and VBA that demonstrate automation and conversion scenarios. These are not the core runtime, but they show the external integration surface the application exposes.

16. Diagram takeaway

For an architecture diagram, the central flow is: Windows print job or launch command enters Startup/Controller → job is represented in Core workflow → settings/profile determine action chain and output format → conversion engine renders via Ghostscript/iText helpers → results are saved, printed, uploaded, mailed, opened, or otherwise dispatched → UI and services observe progress, errors, and completion.