Three libraries. Three distinct jobs. Picking the wrong one costs you weeks of workarounds, and picking all three when you only need one costs you maintenance overhead you did not budget for. Here is a direct account of what each losLab PDF library actually does, where it fits, and where it hands off to its siblings
HotPDF: writing PDF from scratch in Delphi
HotPDF is a native VCL component for generating PDF documents. Its model is imperative and page-centric: you construct a THotPDF instance, set document properties, call BeginDoc, draw to CurrentPage, add pages as needed, and close with EndDoc. The order matters because BeginDoc commits the encryption dictionary and compression settings at the moment it runs; anything assigned after that point is silently ignored rather than applied retroactively
The drawing surface covers the full PDF operator set at the Delphi level: TextOut for positioned Unicode text, SetFont with TrueType embedding, vector primitives (lines, Bezier curves, ellipses, rectangles), image placement from file or memory, and barcode generation. Coordinates are in points from the bottom-left corner with Y increasing upward, which catches everyone once. Font state does not survive AddPage, so a call to SetFont is required after every page break
AcroForm fields are first-class citizens. You can add text fields, checkboxes, radio buttons, combo boxes, list boxes, and push buttons directly to a page object with a single call each. HotPDF can also load an existing PDF through LoadFromFile and fill or read field values, which makes it useful in two separate workflows: building forms and automating their population
Encryption is also handled at the document level. CryptKeyLength selects the scheme (40-bit RC4 through AES-256), ActivateProtection arms it, and ProtectOptions sets the ISO permission flags. The two AES-256 revision modes (R5 and R6, controlled by UseAES256R6) exist because revision 6 fixes a known weakness in revision 5 but requires a PDF 2.0-capable viewer; choosing between them is a compatibility decision, not a convenience one
Digital signature support in HotPDF covers the PAdES baseline profiles, so it is suitable for workflows where the signature must meet ETSI EN 319 142 requirements. If your need is only generating output, HotPDF is the library to reach for first
PDFium VCL: rendering, viewing, and reading existing PDFs
PDFium VCL wraps Google’s PDFium engine as a VCL component, which gives it a fundamentally different role from HotPDF. Where HotPDF writes, PDFium VCL reads and renders. The core object is TPdf, a document manager that opens a file by setting FileName and then Active := True. Load failures are not raised as exceptions; Active simply stays False, so checking it after the assignment is not optional
Rendering runs through TPdfView, a visual component you drop on a form and link to a TPdf instance via PdfView.Pdf := Pdf. Zoom and fit mode live on the view, not on the document. One subtlety that trips people up: Pdf.PageNumber and PdfView.PageNumber are independent properties. Setting one does not update the other, and the view-based extraction APIs (word boxes, reading units) use the view’s current page, not the document’s
Text extraction is where PDFium VCL has no direct competitor in the losLab lineup. ReadablePageContent returns structured text with reading-order awareness, PageWordBoxes gives word-level bounding rectangles, and DocumentReadingUnits walks the entire document. For accessibility work, IsTagged tells you whether a structure tree is present and ValidatePdfUa runs a UA conformance check. These APIs make PDFium VCL the natural choice for any workflow that needs to understand what is inside an existing PDF rather than produce a new one
Form filling also works on the PDFium side, through the same AcroForm layer that the underlying engine exposes. It is appropriate when the source document already exists and you are automating its completion rather than constructing the form fields yourself
PDFlibPas: manipulation, compliance signing, and direct-file access
PDFlibPas (version 3.73.0) sits at the other end of the complexity spectrum. It exposes three API layers on top of the same document model: a flat handle-based facade (TPDFlib) compatible with the Quick-PDF calling convention, a full object-tree layer (TPDFDocument), and a streaming parser (TSmartPDFReader / TSmartPDFWriter) that operates directly on the file bytes without loading the complete object graph
The streaming layer is what makes PDFlibPas the right choice for large documents. TSmartPDFWriter can append an incremental update to a file on disk without reconstructing the entire cross-reference table, which is the mechanism underlying both efficient resaving and PAdES long-term validation stamps. For compliance-grade signing workflows where the signed hash must cover a specific byte range and the signature is applied without rewriting the document, this layer is the only viable path
Document manipulation at the TPDFDocument level includes merging with Merge, selective page copying via CopyPagesFromDoc with a range string, and version governance through SetMinimumVersion and LockSaveVersion. The version lock raises error 602 if you attempt to save a feature that would push the output above the locked version, which is useful when you need to guarantee that output stays within a specific PDF revision for archival compliance
PDF/A support (ISO 19005) sits in PDFlibPas’s conformance workbench. Note that encryption and PDF/A are mutually exclusive by specification: you cannot have both in one file. Workflows that need an encrypted distribution copy and a PDF/A archive copy must produce two separate artifacts
Choosing between them
The typical decision tree is short. If you are generating a new document from data, use HotPDF. If you are rendering or extracting text from an existing document in a Delphi VCL application, use PDFium VCL. If you are manipulating, merging, or compliance-signing existing PDFs at scale or with incremental-save semantics, use PDFlibPas. Many production systems use two of the three: HotPDF to generate output and PDFlibPas to apply a long-term validation stamp to it before archival, for instance, or PDFium VCL to preview what HotPDF produced before sending it downstream
All three ship as native Pascal source for Delphi and C++Builder, with no runtime dependencies beyond the VCL. PDFium VCL additionally bundles the PDFium DLL, which covers the engine’s rendering and parsing work. Each library’s product page carries its full API reference and current version history
Details on the individual libraries: HotPDF Component, PDFium VCL Component, and PDFlibPas