PDFlibPas: Delphi での PDF/A and PDF/UA preflight

losLab PDF Library は、Delphi/C++Builder チーム向けにソース提供の PDF エンジンを提供します。デスクトップ、サーバー、DLL、ActiveX、Dylib ワークフローで使え、PDF/A・PDF/UA チェック、PAdES 署名、複数レンダラーを外部 PDF サービスなしで利用できます。

この記事は developers delivering archive-ready and accessibility-aware PDFs from Delphi systems 向けです。PDF/A and PDF/UA preflight を単なるコンポーネント呼び出しではなく、本番向けのドキュメントエンジニアリングとして扱います。

実務上のリスクは PDF/A and PDF/UA failures usually reflect document design decisions, so late preflight without ownership produces lists of issues nobody can fix です。そのため、明確な契約、観測可能な診断、実際の顧客ファイルに近い回帰サンプルが必要です。

アーキテクチャ上の判断

Connect preflight findings to template ownership. target PDF/A profile, PDF/UA expectations, and accepted validator set / font, metadata, color, annotation, form, and attachment policies

target PDF/A profile, PDF/UA expectations, and accepted validator set
font, metadata, color, annotation, form, and attachment policies
tag structure, heading order, table markup, alternate text, and artifacts
issue ownership and release-gate severity mapping

実装フロー

Treat diagnostics as product requirements. The order below keeps the workflow reviewable for Delphi and C++Builder teams.

configure document generation around the target profiles before output
run structured preflight and normalize findings by owner and severity
route template issues to template maintainers and data issues to application owners
rerun validation after each fix rather than relying on visual inspection
ship the report with the document package when customers require evidence

検証エビデンス

Preflight evidence for archive and accessibility workflows. Keep these fields with the output or support record.

profile, validator version, issue code, severity, page, object, and owner
font embedding, output intent, metadata, and attachment findings
tagging diagnostics such as heading order, table structure, artifacts, and alternate text
release decision, waivers, and final pass or fail report

Archive and accessibility profiles ask different questions

PDF/A focuses on durable reproduction while PDF/UA focuses on semantic access. A production workflow should keep both validation profiles visible and assign findings to generation code, templates, or content owners.

リリース前の確認事項

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

Who owns target PDF/A profile, PDF/UA expectations, and accepted validator set?
What evidence proves profile, validator version, issue code, severity, page, object, and owner?
What happens when an archive-valid file can still have poor reading order?
Which regression file covers ship the report with the document package when customers require evidence?

PDF/A and PDF/UA preflight に関する技術レビューの注意点

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

判断: target PDF/A profile, PDF/UA expectations, and accepted validator set. 実装上の焦点: run structured preflight and normalize findings by owner and severity. 受け入れ証拠: tagging diagnostics such as heading order, table structure, artifacts, and alternate text. 回帰の引き金: third-party inserted pages can break profile assumptions late in assembly
判断: font, metadata, color, annotation, form, and attachment policies. 実装上の焦点: route template issues to template maintainers and data issues to application owners. 受け入れ証拠: release decision, waivers, and final pass or fail report. 回帰の引き金: an archive-valid file can still have poor reading order
判断: tag structure, heading order, table markup, alternate text, and artifacts. 実装上の焦点: rerun validation after each fix rather than relying on visual inspection. 受け入れ証拠: profile, validator version, issue code, severity, page, object, and owner. 回帰の引き金: decorative content should be marked as artifacts instead of hidden visually only
判断: issue ownership and release-gate severity mapping. 実装上の焦点: ship the report with the document package when customers require evidence. 受け入れ証拠: font embedding, output intent, metadata, and attachment findings. 回帰の引き金: forms and annotations can conflict with archive goals depending on profile

境界ケース

an archive-valid file can still have poor reading order
decorative content should be marked as artifacts instead of hidden visually only
forms and annotations can conflict with archive goals depending on profile
third-party inserted pages can break profile assumptions late in assembly

Delphi / C++Builder の補足

PDFlibPas should sit behind a small service boundary that receives files, streams, profiles, and credentials, then returns output paths, warnings, metrics, and validation status. 重要な用語には PDF/A, PDF/UA, CreatePreflightReportEx, accessibility, tag structure, validator.

Delphi コード例

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

procedure RunStandardsPreflight(const InputFile, ReportFile: string; const Profile: string);
var
  Pdf: TPDFlib;
begin
  Pdf := TPDFlib.Create;
  try
    Pdf.LoadFromFile(InputFile, '');
    TFile.WriteAllText(ReportFile, BuildStandardsReport(Pdf, Profile), TEncoding.UTF8);
    FailOnBlockingStandardsIssues(ReportFile);
  finally
    Pdf.Free;
  end;
end;

本番チェックリスト

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

製品ドキュメント

PDFlibPas

追加のコード例

var
  Pdf: TPDFlib;
  Diag: WideString;
begin
  Pdf := TPDFlib.Create;
  try
    Pdf.NewDocument;
    Pdf.SetPDFAMode(1);
    Pdf.LoadOutputIntentProfile('sRGB-IEC61966-2.1.icc', 'RGB');
    Pdf.SetPDFUAMode('en-US');
    Pdf.SetInformation(1, 'Quarterly Statement');  // /Title: required for PDF/UA
    // ... draw tagged content here ...
    Diag := Pdf.GetPDFUADiagnostics;
    if Diag <> '' then
      Writeln('fix before shipping: ', Diag);
    Pdf.SaveToFile('statement.pdf');
    // the preflight that counts runs on the saved file:
    Writeln(Pdf.CreatePreflightReport('statement.pdf', '', 1, 0));
  finally
    Pdf.Free;
  end;
end;