Technisch artikel

PDFlibPas: tagged PDF accessibility structure in Delphi

losLab PDF Library biedt Delphi- en C++Builder-teams een PDF-engine met beschikbare broncode voor desktop-, server-, DLL-, ActiveX- en Dylib-workflows, inclusief ingebouwde PDF/A- en PDF/UA-controles, PAdES-ondertekening en keuze uit renderers zonder documenten via een externe PDF-service te sturen.

Dit artikel is bedoeld voor developers generating accessible reports, statements, manuals, or public documents from Delphi. Het behandelt tagged PDF accessibility structure als productiegerichte documentengineering, niet als een losse componentaanroep.

Het praktische risico is dat a PDF can contain text and still be inaccessible if headings, tables, artifacts, alternate text, and reading order are missing or wrong. Daarom heeft de workflow een geschreven contract, observeerbare diagnose en representatieve regressiebestanden nodig.

Architectuurbeslissingen

Design semantic structure while generating content. heading levels, paragraphs, lists, tables, figures, artifacts, and role mapping / alternate text ownership for charts, logos, signatures, and decorative images

  • heading levels, paragraphs, lists, tables, figures, artifacts, and role mapping
  • alternate text ownership for charts, logos, signatures, and decorative images
  • reading order for multi-column, repeated-header, and mixed-language content
  • validation profile and manual review process for generated samples

Implementatiepad

Treat tags as document data, not decoration. The order below keeps the workflow reviewable for Delphi and C++Builder teams.

  1. build a semantic outline in parallel with visual layout
  2. tag content as it is emitted so page geometry and structure stay aligned
  3. mark decorative elements as artifacts and supply alternate text for meaningful images
  4. validate PDF/UA-related diagnostics and inspect reading order manually
  5. keep accessible reference samples for every report template family

Validatiebewijs

Accessibility evidence for generated PDFs. Keep these fields with the output or support record.

  • structure tree summary, role map, heading order, table structure, and artifact count
  • alternate text coverage for figures and chart-like content
  • reading-order review notes for representative pages
  • PDF/UA diagnostic report and remediation decisions

Reading order is an authoring responsibility

Tagged PDF output requires a structure tree, role mapping, alternate text, table relationships, artifacts, and reading order that match the visual document. Retrofitting those semantics after layout is far harder.

Decision table for tagged PDF accessibility structure

A decision table keeps product ownership visible when the same workflow is reused by a desktop tool, service job, and support utility.

DecisionEngineering reasonEvidence
heading levels, paragraphs, lists, tables, figures, artifacts, and role mappingbuild a semantic outline in parallel with visual layoutstructure tree summary, role map, heading order, table structure, and artifact count
alternate text ownership for charts, logos, signatures, and decorative imagestag content as it is emitted so page geometry and structure stay alignedalternate text coverage for figures and chart-like content
reading order for multi-column, repeated-header, and mixed-language contentmark decorative elements as artifacts and supply alternate text for meaningful imagesreading-order review notes for representative pages

Engineering review notes for tagged PDF accessibility structure

Use these review notes to make sure the feature has moved beyond a demo and can be defended during release, support, and customer escalation.

  • Decision: heading levels, paragraphs, lists, tables, figures, artifacts, and role mapping. Implementation pressure point: tag content as it is emitted so page geometry and structure stay aligned. Acceptance evidence: reading-order review notes for representative pages. Regression trigger: images with text may need both alternate text and source-data access
  • Decision: alternate text ownership for charts, logos, signatures, and decorative images. Implementation pressure point: mark decorative elements as artifacts and supply alternate text for meaningful images. Acceptance evidence: PDF/UA diagnostic report and remediation decisions. Regression trigger: visual headers repeated on every page should often be artifacts
  • Decision: reading order for multi-column, repeated-header, and mixed-language content. Implementation pressure point: validate PDF/UA-related diagnostics and inspect reading order manually. Acceptance evidence: structure tree summary, role map, heading order, table structure, and artifact count. Regression trigger: tables need header relationships, not only drawn grid lines
  • Decision: validation profile and manual review process for generated samples. Implementation pressure point: keep accessible reference samples for every report template family. Acceptance evidence: alternate text coverage for figures and chart-like content. Regression trigger: multi-column pages can read incorrectly if tags follow drawing order
  • Decision: heading levels, paragraphs, lists, tables, figures, artifacts, and role mapping. Implementation pressure point: build a semantic outline in parallel with visual layout. Acceptance evidence: reading-order review notes for representative pages. Regression trigger: images with text may need both alternate text and source-data access
  • Decision: alternate text ownership for charts, logos, signatures, and decorative images. Implementation pressure point: tag content as it is emitted so page geometry and structure stay aligned. Acceptance evidence: PDF/UA diagnostic report and remediation decisions. Regression trigger: visual headers repeated on every page should often be artifacts

Randgevallen

  • visual headers repeated on every page should often be artifacts
  • tables need header relationships, not only drawn grid lines
  • multi-column pages can read incorrectly if tags follow drawing order
  • images with text may need both alternate text and source-data access

Delphi / C++Builder notes

PDFlibPas should sit behind a small service boundary that receives files, streams, profiles, and credentials, then returns output paths, warnings, metrics, and validation status. Important terms include tagged PDF, structure tree, role map, alternate text, artifact, reading order.

Delphi-codevoorbeeld

De volgende Delphi-schets toont een praktische servicegrens voor dit onderwerp. Houd beleidscontroles, logging en validatie buiten het smalle productaanroepblok, zodat de workflow testbaar blijft.

procedure InspectTaggedStructure(const FileName: string);
var
  Pdf: TPDFlib;
begin
  Pdf := TPDFlib.Create;
  try
    Pdf.LoadFromFile(FileName, '');
    FTagReport := BuildStructureTreeReport(Pdf);
    RequireAltTextForFigures(FTagReport);
    RequireLogicalReadingOrder(FTagReport);
  finally
    Pdf.Free;
  end;
end;

Productiechecklist

  • Run the workflow on an empty file, a normal customer file, and a worst-case file
  • Open the generated PDF with the target viewer, validator, printer, or downstream application
  • Log product version, profile version, input hash, output path, elapsed time, and warning count
  • Keep passwords, certificates, temporary files, and customer data under explicit retention rules
  • Add regression documents when a customer file exposes a new edge case

Product documentation

PDFlibPas