LlosLab Software Development BlogEngineering notes for PDF, Delphi, and document software developers.

技術記事

PDFium Component: Delphi での accessible PDF reader design

PDFium Component

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

この記事は Delphi teams building PDF viewers for public-sector, education, healthcare, or internal operations users 向けです。accessible PDF reader design を単なるコンポーネント呼び出しではなく、本番向けのドキュメントエンジニアリングとして扱います。

実務上のリスクは accessibility cannot be added by a toolbar at the end if focus order, text extraction, color modes, keyboard navigation, and document diagnostics are not part of the viewer architecture です。そのため、明確な契約、観測可能な診断、実際の顧客ファイルに近い回帰サンプルが必要です。

アーキテクチャ上の判断

Design the reader around user tasks, not only pages. keyboard model for page navigation, search, selection, panels, and annotations / focus order between the document viewport, thumbnails, form fields, and side panels

  • keyboard model for page navigation, search, selection, panels, and annotations
  • focus order between the document viewport, thumbnails, form fields, and side panels
  • fallback behavior when a document lacks tags, text, or usable reading order
  • color, zoom, contrast, and speech-assistance modes that do not alter the source file

実装フロー

Combine rendering with semantic inspection. The order below keeps the workflow reviewable for Delphi and C++Builder teams.

  1. define reader tasks and keyboard shortcuts before wiring viewer controls
  2. extract text and document structure where available and expose diagnostics
  3. connect focus updates to page, selection, form field, and annotation events
  4. test zoom, contrast, search, and speech cues on tagged and untagged files
  5. record unsupported document conditions as user-facing warnings

検証エビデンス

Accessibility evidence to keep with releases. Keep these fields with the output or support record.

  • keyboard path coverage, focus transitions, text extraction status, and search behavior
  • PDF/UA or structure diagnostics when available
  • screen-reader notes for supported controls and viewer panels
  • low-vision mode settings used during verification

Accessible viewing starts with predictable navigation

An accessible PDF reader has to expose document state, keyboard paths, focus changes, text selection, search results, zoom behavior, and low-vision display choices consistently. Rendering accuracy is necessary but not sufficient.

Profile ownership and versioning

A named, versioned profile is easier to review than options scattered across forms, scripts, and batch parameters. It also makes support reports readable when customers use older templates or policies.

  • keyboard model for page navigation, search, selection, panels, and annotations
  • focus order between the document viewport, thumbnails, form fields, and side panels
  • fallback behavior when a document lacks tags, text, or usable reading order
  • color, zoom, contrast, and speech-assistance modes that do not alter the source file
  • keyboard path coverage, focus transitions, text extraction status, and search behavior
  • PDF/UA or structure diagnostics when available

accessible PDF reader design に関する技術レビューの注意点

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

  • 判断: keyboard model for page navigation, search, selection, panels, and annotations. 実装上の焦点: extract text and document structure where available and expose diagnostics. 受け入れ証拠: screen-reader notes for supported controls and viewer panels. 回帰の引き金: contrast filters should be reversible and should not modify the PDF itself
  • 判断: focus order between the document viewport, thumbnails, form fields, and side panels. 実装上の焦点: connect focus updates to page, selection, form field, and annotation events. 受け入れ証拠: low-vision mode settings used during verification. 回帰の引き金: image-only PDFs need OCR or a clear warning rather than silent empty text
  • 判断: fallback behavior when a document lacks tags, text, or usable reading order. 実装上の焦点: test zoom, contrast, search, and speech cues on tagged and untagged files. 受け入れ証拠: keyboard path coverage, focus transitions, text extraction status, and search behavior. 回帰の引き金: rotated pages and mixed page sizes can break hit-testing and focus cues
  • 判断: color, zoom, contrast, and speech-assistance modes that do not alter the source file. 実装上の焦点: record unsupported document conditions as user-facing warnings. 受け入れ証拠: PDF/UA or structure diagnostics when available. 回帰の引き金: thumbnail panes should not trap keyboard users away from the document
  • 判断: keyboard model for page navigation, search, selection, panels, and annotations. 実装上の焦点: define reader tasks and keyboard shortcuts before wiring viewer controls. 受け入れ証拠: screen-reader notes for supported controls and viewer panels. 回帰の引き金: contrast filters should be reversible and should not modify the PDF itself
  • 判断: focus order between the document viewport, thumbnails, form fields, and side panels. 実装上の焦点: extract text and document structure where available and expose diagnostics. 受け入れ証拠: low-vision mode settings used during verification. 回帰の引き金: image-only PDFs need OCR or a clear warning rather than silent empty text

境界ケース

  • image-only PDFs need OCR or a clear warning rather than silent empty text
  • rotated pages and mixed page sizes can break hit-testing and focus cues
  • thumbnail panes should not trap keyboard users away from the document
  • contrast filters should be reversible and should not modify the PDF itself

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. 重要な用語には TPdfView, keyboard navigation, PDF/UA, reading order, focus, low-vision mode.

Delphi コード例

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

procedure TReaderForm.LoadReadingStream(const FileName: string; PageNo: Integer);
begin
  PdfView.LoadFromFile(FileName);
  if (PageNo < 1) or (PageNo > PdfView.PageCount) then
    raise ERangeError.Create('Page number is outside the document');
  FReadingUnits := ExtractTaggedReadingOrder(PdfView, PageNo);
  QueueSpeech(FReadingUnits);
  RenderPagePreview(PageNo);
end;

本番チェックリスト

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

製品ドキュメント

PDFium Component

追加のコード例

procedure TReaderForm.PrepareKaraoke(PageNumber: Integer);
begin
  // The view's word boxes come from the page the view displays —
  // setting Pdf.PageNumber alone would not move the view
  PdfView.PageNumber := PageNumber;
  FWordBoxes := PdfView.PageWordBoxes;
end;

procedure TReaderForm.OnTtsWordBoundary(Sender: TObject; CharIndex: Integer);
var
  WordIdx: Integer;
begin
  // TrackReadingWordAt maps the offset AND paints the word cursor
  WordIdx := PdfView.TrackReadingWordAt(FCurrentPage, CharIndex);
  if WordIdx < 0 then
    PdfView.ClearReadingWord;  // boundary ran past the page text
end;