PDFium Component: Delphi での Lazarus and Free Pascal viewer integration

Delphi/C++Builder には PDFium VCL Component のワークフローを、Lazarus/FPC には PDFium LCL Component のワークフローを組み込み、表示、レンダリング、フォーム、印刷、プリフライトレポート、標準対応の検証をソースコード付きコンポーネントで実装できます。

この記事は teams sharing PDF viewing code between Delphi, Lazarus, and Free Pascal applications 向けです。Lazarus and Free Pascal viewer integration を単なるコンポーネント呼び出しではなく、本番向けのドキュメントエンジニアリングとして扱います。

実務上のリスクは a viewer can compile in multiple IDEs yet fail in deployment because widget-set behavior, binary loading, calling conventions, and resource paths differ です。そのため、明確な契約、観測可能な診断、実際の顧客ファイルに近い回帰サンプルが必要です。

アーキテクチャ上の判断

Treat the viewer layer as portable infrastructure. supported IDEs, compiler versions, CPU architectures, and widget sets / PDFium binary location, bitness, load failure message, and update policy

• supported IDEs, compiler versions, CPU architectures, and widget sets
• PDFium binary location, bitness, load failure message, and update policy
• high-DPI scaling, mouse wheel, keyboard, and focus behavior across frameworks
• feature parity expectations for thumbnails, search, forms, printing, and annotations

実装フロー

Stabilize runtime loading before adding UI features. The order below keeps the workflow reviewable for Delphi and C++Builder teams.

1. create a small viewer shell that loads the PDFium runtime before opening documents
2. normalize paths and binary names for each supported deployment layout
3. exercise zoom, scroll, selection, and focus events on every widget set
4. separate shared PDF logic from framework-specific panels and dialogs
5. package diagnostics that identify missing binaries and architecture mismatches

検証エビデンス

Deployment evidence for mixed-toolchain support. Keep these fields with the output or support record.

• compiler, widget set, target architecture, PDFium binary path, and runtime version
• load success or failure reason before the first document is opened
• input-event test results for wheel, drag, keyboard, focus, and high-DPI scaling
• feature matrix showing which viewer actions are supported in each build

Portability is a packaging decision

A Lazarus and FPC integration should define how the PDFium binary is found, which widget sets are supported, how DPI and input events are normalized, and which viewer features are guaranteed across platforms.

Operational metrics to watch

The first release should expose enough metrics to prove the workflow is healthy under real files, not only under curated samples.

• count and rate for compiler, widget set, target architecture, PDFium binary path, and runtime version
• warning trend for a 32-bit application cannot load a 64-bit PDFium binary
• latency of the stage that must create a small viewer shell that loads the PDFium runtime before opening documents
• profile usage for supported IDEs, compiler versions, CPU architectures, and widget sets

Lazarus and Free Pascal viewer integration に関する技術レビューの注意点

これらのレビュー項目を使って、機能がデモ段階を超え、リリース、サポート、顧客エスカレーションの場で説明できることを確認します

• 判断: supported IDEs, compiler versions, CPU architectures, and widget sets. 実装上の焦点: normalize paths and binary names for each supported deployment layout. 受け入れ証拠: input-event test results for wheel, drag, keyboard, focus, and high-DPI scaling. 回帰の引き金: printing and file dialogs may need framework-specific wrappers
• 判断: PDFium binary location, bitness, load failure message, and update policy. 実装上の焦点: exercise zoom, scroll, selection, and focus events on every widget set. 受け入れ証拠: feature matrix showing which viewer actions are supported in each build. 回帰の引き金: a 32-bit application cannot load a 64-bit PDFium binary
• 判断: high-DPI scaling, mouse wheel, keyboard, and focus behavior across frameworks. 実装上の焦点: separate shared PDF logic from framework-specific panels and dialogs. 受け入れ証拠: compiler, widget set, target architecture, PDFium binary path, and runtime version. 回帰の引き金: relative paths often work in the IDE and fail from installed shortcuts

境界ケース

• a 32-bit application cannot load a 64-bit PDFium binary
• relative paths often work in the IDE and fail from installed shortcuts
• widget-set differences can alter focus behavior in docked panes
• printing and file dialogs may need framework-specific wrappers

Delphi / C++Builder の補足

PDFium Component should sit behind a small service boundary that receives files, streams, profiles, and credentials, then returns output paths, warnings, metrics, and validation status. 重要な用語には Lazarus, Free Pascal, LCL, PDFium, widget set, runtime loading.

Delphi コード例

次の Delphi スケッチは、このテーマに対する実用的なサービス境界を示します。ポリシー確認、ログ記録、検証を製品呼び出しの狭い部分の外側に置くと、ワークフローをテストしやすくなります。

procedure TMainForm.OpenDocument(const FileName: string);
begin
  PdfView.LoadFromFile(FileName);
  TrackDocumentLifetime(FileName, PdfView.PageCount);
  PageSpinEdit.MaxValue := PdfView.PageCount;
  RenderCurrentPage;
  UpdateToolbarState;
end;

本番チェックリスト

• ワークフローは、空のファイル、通常の顧客ファイル、最悪ケースのファイルで実行します
• 生成された PDF は、対象のビューアー、検証ツール、プリンター、または downstream アプリケーションで開きます
• 製品バージョン、プロファイルバージョン、入力ハッシュ、出力パス、経過時間、警告数を記録します
• パスワード、証明書、一時ファイル、顧客データは明確な保持ルールの下で管理します
• 顧客ファイルが新しい境界ケースを示したら、回帰用ドキュメントを追加します

製品ドキュメント

PDFium Component

追加のコード例

procedure TViewerForm.FormCreate(Sender: TObject);
begin
  Pdf := TPdf.Create(Self);

  PdfView := TPdfView.Create(Self);
  PdfView.Parent := Self;
  PdfView.Align := alClient;
  PdfView.Pdf := Pdf;
  PdfView.FitMode := pfmFitWidth;

  if ParamCount > 0 then
  begin
    Pdf.FileName := ParamStr(1);
    Pdf.Active := True;   // opens the document; PageCount valid after this
  end;
end;