三個函式庫；三項不同的工作；選錯一個會花費您數週的時間來尋求因應對策，而當您只需要一個時卻選擇了全部三個，則會花費您未列入預算的維護開銷；以下直接說明每個 losLab PDF 函式庫的實際功用、適用場景以及它們如何與其他系列元件協作
HotPDF：在 Delphi 中從零撰寫 PDF
HotPDF 是用來產生 PDF 文件的原生 VCL 元件。它的模型是命令式、以頁面為中心的：建構一個 THotPDF 實例、設定文件屬性、呼叫 BeginDoc、繪製到 CurrentPage、按需要加頁，最後以 EndDoc 收尾。順序之所以重要，是因為 BeginDoc 在執行當下就提交加密字典與壓縮設定；那之後才指派的任何設定會被悄悄忽略，而不是追溯套用
繪圖介面在 Delphi 層級涵蓋完整的 PDF 運算子集：定位 Unicode 文字的 TextOut、帶 TrueType 內嵌的 SetFont、向量基本圖形（線段、貝茲曲線、橢圓、矩形）、從檔案或記憶體放置影像，以及條碼產生。座標以左上角為原點、Y 軸向下遞增，就跟 VCL 畫布一樣；這點會讓習慣了原始 PDF 內容串流（原點在左下角）的人栽跟頭。字型狀態不會跨過 AddPage 存續，所以每次分頁之後都得重新呼叫 SetFont
AcroForm 欄位是一等公民。文字欄位、核取方塊、選鈕、下拉式選單、清單方塊與按鈕，各自一次呼叫就能直接加到頁面物件上。HotPDF 也能透過 LoadFromFile 載入既有 PDF 並填寫或讀取欄位值，這讓它在兩條各自獨立的工作流程裡都用得上：建表單，以及自動化填表
加密同樣在文件層級處理。CryptKeyLength 選擇機制（40 位元 RC4 到 AES-256），ActivateProtection 啟用它，ProtectOptions 設定 ISO 權限旗標。兩種 AES-256 修訂模式（R5 與 R6，由 UseAES256R6 控制）並存的原因：修訂 5 原本是 Adobe 的延伸，其密碼檢查後來被證實偏弱而遭棄用；修訂 6 才是 ISO 32000-2 標準化的形式。Acrobat X 與之後版本以及大多數現用檢視器都能開 R6 檔案，所以 R6 是合理的預設；只有收件端卡在舊檢視器上時，R5 才有意義
HotPDF 的數位簽章支援涵蓋 PAdES 基層級設定檔，適合簽章必須滿足 ETSI EN 319 142 要求的工作流程。如果您的需求只是產生輸出，HotPDF 就是第一個該伸手拿的函式庫
PDFium Component：渲染、檢視與讀取既有 PDF
PDFium Component 把 Google 的 PDFium 引擎包成 VCL 元件，這讓它的角色與 HotPDF 有根本差異：HotPDF 負責寫，PDFium Component 負責讀與渲染。核心物件是 TPdf，一份文件管理器，設定 FileName 再 Active := True 即可開檔。載入失敗不會以例外形式浮出；Active 只是停在 False，所以賦值之後檢查它不是可省的動作
渲染透過 TPdfView 進行，這是個視覺元件，放到表單上並以 PdfView.Pdf := Pdf 連到 TPdf 實例。縮放與契合模式住在檢視上，不在文件上。有個容易絆倒人的細節：Pdf.PageNumber 與 PdfView.PageNumber 是互相獨立的屬性，設了其中一個不會更新另一個，而以檢視為準的擷取 API（文字框、閱讀單元）用的是檢視的當前頁，不是文件的
文字擷取是 PDFium Component 在 losLab 產品線裡沒有直接對手的領域。ReadablePageContent 回傳具備閱讀順序感知的結構化文字，PageWordBoxes 給出詞層級的邊界矩形，DocumentReadingUnits 則走完整份文件。做無障礙工作時，IsTagged 告訴您是否存在結構樹，ValidatePdfUa 則執行 UA 符合性檢查。這些 API 讓 PDFium Component 成為任何「需要理解既有 PDF 內容、而非產生新 PDF」之工作流程的自然首選
表單填寫在 PDFium 這一側也行得通，走的是底層引擎暴露的同一套 AcroForm 層。當來源文件已經存在、您是在自動化它的完成流程而非自行建構表單欄位時，這條路是合適的
PDF Library for Delphi：操作、合規簽署與直接檔案存取
PDF Library for Delphi 坐落在複雜度光譜的另一端。它在同一份文件模型上暴露三個 API 層：與 Quick-PDF 呼叫慣例相容的扁平控制代碼外觀（TPDFlib）、完整的物件樹層（TPDFDocument），以及直接操作檔案位元組、無須載入完整物件圖的串流剖析器（TSmartPDFReader / TSmartPDFWriter）
串流層正是讓 PDF Library for Delphi 成為大型文件正解的關鍵。TSmartPDFWriter 能對磁碟上的檔案附加增量更新而不重建整張交叉參照表，高效重存與 PAdES 長期驗證戳記的底層機制都是它。對於簽章雜湊必須涵蓋特定位元組範圍、且簽章在不改寫文件的前提下套用的合規級簽署工作流程，這一層是唯一可行之路
在 TPDFDocument 層級的文件操作包括以 Merge 合併、以範圍字串透過 CopyPagesFromDoc 選擇性複製頁面，以及透過 SetMinimumVersion 與 LockSaveVersion 做版本治理。版本鎖定會在您試圖儲存會把輸出推高過鎖定版本的功能時發出錯誤 602，當您需要保證輸出維持在特定 PDF 修訂版內以符合封存合規時，這個功能很好用
PDF/A 支援（ISO 19005）位於 PDF Library for Delphi 的合規工作台裡。請注意，加密與 PDF/A 依規範互斥：同一份檔案無法兩者兼得。需要加密散布副本與 PDF/A 封存副本的工作流程，必須產出兩份分開的成品
如何在這三者之間選擇
典型的決策樹很短。要從資料產生新文件，用 HotPDF。要在 Delphi VCL 應用程式裡渲染或擷取既有文件的文字，用 PDFium Component。要大規模操作、合併既有 PDF，或以增量儲存語意做合規簽署，用 PDF Library for Delphi。許多生產系統同時用其中兩個：例如用 HotPDF 產生輸出、再以 PDF Library for Delphi 蓋上長期驗證戳記後歸檔；或用 PDFium Component 預覽 HotPDF 的產出，再送往下游
三者都以原生 Pascal 原始碼的形式出貨給 Delphi 與 C++Builder。HotPDF 與 PDF Library for Delphi 除了 VCL 外沒有執行期相依；PDFium Component 另外附帶 PDFium DLL，由它負責引擎的渲染與剖析工作。每個函式庫的產品頁都載有完整的 API 參考與目前的版本歷史
各函式庫的細節請見：HotPDF Delphi Component、PDFium Component 與 PDF Library for Delphi