技術記事

HotPDF Component: Delphi での object streams とインクリメンタル更新

HotPDF は Delphi/C++Builder アプリケーション向けのネイティブ VCL PDF ライブラリです。外部 PDF ランタイムを配置せずに、PDF 作成、編集、フォーム、注釈、暗号化、デジタル署名、Unicode フォント、標準対応出力、プリフライトレポートを扱えます。

この記事は 署名、改訂、圧縮オブジェクト、修復履歴をすでに含む可能性のある PDF を保守するエンジニア向け 向けです。object streams とインクリメンタル更新 を単なるコンポーネント呼び出しではなく、本番向けのドキュメントエンジニアリングとして扱います。

実務上のリスクは ファイルを新しく生成されたものとして書き直すと、改訂履歴が失われたり、署名が壊れたり、破損したクロスリファレンスデータが隠れたりします です。そのため、明確な契約、観測可能な診断、実際の顧客ファイルに近い回帰サンプルが必要です。

アーキテクチャ上の判断

既存の改訂チェーンを理解します。既存の署名や監査証跡を有効なまま維持する必要があるか / object stream の保持、展開、再圧縮に関するポリシー

  • 既存の署名や監査証跡を有効なまま維持する必要があるか
  • object stream の保持、展開、再圧縮に関するポリシー
  • repair handling when cross-reference data is inconsistent
  • metadata and catalog updates that should be appended instead of rewritten

実装フロー

完全な書き直しとインクリメンタル保存は意図して選びます。以下の順序にすると Delphi と C++Builder のチームがレビューしやすくなります。

  1. inspect the source for signatures, xref streams, object streams, and prior revisions
  2. select incremental update only when the business goal requires preservation
  3. write changed objects to a new revision and leave untouched objects stable
  4. verify signatures, object counts, and cross-reference consistency after saving
  5. record the reason if a full rewrite was required for repair or normalization

検証エビデンス

記録するべき改訂の証拠。これらの項目を出力またはサポート記録と一緒に保持します。

  • source revision count, signature presence, xref style, and object stream count
  • save mode, changed object identifiers, and whether object streams were preserved
  • validator output before and after the update
  • signature status for every signed revision after the final file is written

圧縮オブジェクトはサポート診断を変える

Object streams、hybrid cross-reference tables、incremental saves は現代の PDF では普通です。ワークフローは、改訂を保持しているのか、新しい改訂を追加しているのか、あるいはクリーンな出力ファイルを作成しているのかを把握する必要があります。

リリース前の確認事項

本番に出す前に、チームはソースコードを読まずにこれらの質問に答えられる必要があります

  • 既存の署名や監査証跡を有効なまま維持する責任は誰が持つのか?
  • ソースの改訂数、署名の有無、xref スタイル、object stream 数を示す証拠は何ですか?
  • 見た目の内容が変わらなくても、完全な書き直しで署名が無効になる場合はどうなりますか?
  • 修復または正規化のために完全な書き直しが必要だった理由を記録する回帰ファイルはどれですか?

object streams とインクリメンタル更新 に関する技術レビューの注意点

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

  • 判断: 既存の署名や監査証跡を有効なまま維持する必要があるか. 実装上の焦点: select incremental update only when the business goal requires preservation. 受け入れ証拠: validator output before and after the update. 回帰の引き金: object-stream compression can make diff-based support investigations misleading
  • 判断: object stream の保持、展開、再圧縮に関するポリシー. 実装上の焦点: write changed objects to a new revision and leave untouched objects stable. 受け入れ証拠: signature status for every signed revision after the final file is written. 回帰の引き金: a full rewrite can invalidate signatures even when visible content is unchanged
  • 判断: repair handling when cross-reference data is inconsistent. 実装上の焦点: verify signatures, object counts, and cross-reference consistency after saving. 受け入れ証拠: source revision count, signature presence, xref style, and object stream count. 回帰の引き金: repairing a damaged file may require a support note explaining lost revisions
  • 判断: metadata and catalog updates that should be appended instead of rewritten. 実装上の焦点: record the reason if a full rewrite was required for repair or normalization. 受け入れ証拠: save mode, changed object identifiers, and whether object streams were preserved. 回帰の引き金: linearization can be lost after incremental updates unless the workflow rebuilds it
  • 判断: 既存の署名や監査証跡を有効なまま維持する必要があるか. 実装上の焦点: inspect the source for signatures, xref streams, object streams, and prior revisions. 受け入れ証拠: validator output before and after the update. 回帰の引き金: object-stream compression can make diff-based support investigations misleading
  • 判断: object stream の保持、展開、再圧縮に関するポリシー. 実装上の焦点: select incremental update only when the business goal requires preservation. 受け入れ証拠: signature status for every signed revision after the final file is written. 回帰の引き金: a full rewrite can invalidate signatures even when visible content is unchanged
  • 判断: repair handling when cross-reference data is inconsistent. 実装上の焦点: write changed objects to a new revision and leave untouched objects stable. 受け入れ証拠: source revision count, signature presence, xref style, and object stream count. 回帰の引き金: repairing a damaged file may require a support note explaining lost revisions

境界ケース

  • a full rewrite can invalidate signatures even when visible content is unchanged
  • repairing a damaged file may require a support note explaining lost revisions
  • linearization can be lost after incremental updates unless the workflow rebuilds it
  • object-stream compression can make diff-based support investigations misleading

Delphi / C++Builder の補足

HotPDF Component は、ファイル、ストリーム、プロファイル、認証情報を受け取り、出力パス、警告、メトリクス、検証状態を返す小さなサービス境界の背後に置くべきです。重要な用語には object stream, incremental update, xref stream, revision, signature preservation, repair.

Delphi コード例

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

procedure SaveCompactIncrementalPdf(const OutputFile: string);
var
  Pdf: THotPDF;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.FileName := OutputFile;
    Pdf.UseXRefStream := True;
    Pdf.UseObjectStreams := True;
    Pdf.BeginDoc;
    AddRevisionContent(Pdf);
    Pdf.EndDoc;
    CompareObjectStreamProfile(OutputFile);
  finally
    Pdf.Free;
  end;
end;

本番チェックリスト

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

製品ドキュメント

HotPDF Component

追加のコード例

Pdf.BeginIncrementalUpdate('contract-signed.pdf');
Pdf.AddPage;
Pdf.CurrentPage.SetFont('Arial', [], 10);
Pdf.CurrentPage.TextOut(50, 760, 0, 'Addendum recorded 2026-06-11');
Pdf.SaveIncrementalUpdate('contract-updated.pdf');  // appends the delta only
PageCount := Pdf.LoadFromFile('base.pdf');
Pdf.InsertPagesFromDocument(OtherDoc, '1-3', 5);  // pages 1-3 after page 5
Pdf.MovePage(2, 5);
Pdf.SaveLoadedDocument('modified.pdf');
Pdf.LoadFromFile('stamped.pdf');
Pdf.SaveLoadedDocument('compacted.pdf');