Integrera PDFium VCL Component-flöden i Delphi- och C++Builder-applikationer, eller PDFium LCL Component-flöden i Lazarus/FPC, med källkodskomponenter för visning, rendering, formulär, utskrift, preflight-rapporter och standardinriktad validering.
Den här artikeln är skriven för Delphi teams building PDF viewers for public-sector, education, healthcare, or internal operations users. Den behandlar accessible PDF reader design som produktionsnära dokumentteknik, inte som ett isolerat komponentanrop.
Den praktiska risken är att 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. Därför behöver flödet ett skrivet kontrakt, observerbar diagnostik och realistiska regressionsfiler.
Arkitekturbeslut
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
Implementeringsflöde
Combine rendering with semantic inspection. Ordningen nedan gör arbetsflödet granskbart för Delphi- och C++Builder-team.
- define reader tasks and keyboard shortcuts before wiring viewer controls
- extract text and document structure where available and expose diagnostics
- connect focus updates to page, selection, form field, and annotation events
- test zoom, contrast, search, and speech cues on tagged and untagged files
- record unsupported document conditions as user-facing warnings
Valideringsbevis
Accessibility evidence to keep with releases. Behåll dessa fält tillsammans med utdata eller supportunderlaget.
- 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
Tekniska granskningsnoteringar för accessible PDF reader design
Använd dessa granskningsnoteringar för att säkerställa att funktionen har passerat demo-nivån och kan försvaras under leverans, support och kundeskalering.
- Beslut: keyboard model for page navigation, search, selection, panels, and annotations. Implementeringspresspunkt: extract text and document structure where available and expose diagnostics. Acceptansbevis: screen-reader notes for supported controls and viewer panels. Regressionsutlösare: contrast filters should be reversible and should not modify the PDF itself
- Beslut: focus order between the document viewport, thumbnails, form fields, and side panels. Implementeringspresspunkt: connect focus updates to page, selection, form field, and annotation events. Acceptansbevis: low-vision mode settings used during verification. Regressionsutlösare: image-only PDFs need OCR or a clear warning rather than silent empty text
- Beslut: fallback behavior when a document lacks tags, text, or usable reading order. Implementeringspresspunkt: test zoom, contrast, search, and speech cues on tagged and untagged files. Acceptansbevis: keyboard path coverage, focus transitions, text extraction status, and search behavior. Regressionsutlösare: rotated pages and mixed page sizes can break hit-testing and focus cues
- Beslut: color, zoom, contrast, and speech-assistance modes that do not alter the source file. Implementeringspresspunkt: record unsupported document conditions as user-facing warnings. Acceptansbevis: PDF/UA or structure diagnostics when available. Regressionsutlösare: thumbnail panes should not trap keyboard users away from the document
- Beslut: keyboard model for page navigation, search, selection, panels, and annotations. Implementeringspresspunkt: define reader tasks and keyboard shortcuts before wiring viewer controls. Acceptansbevis: screen-reader notes for supported controls and viewer panels. Regressionsutlösare: contrast filters should be reversible and should not modify the PDF itself
- Beslut: focus order between the document viewport, thumbnails, form fields, and side panels. Implementeringspresspunkt: extract text and document structure where available and expose diagnostics. Acceptansbevis: low-vision mode settings used during verification. Regressionsutlösare: image-only PDFs need OCR or a clear warning rather than silent empty text
Gränsfall
- 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 notes
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. Important terms include TPdfView, keyboard navigation, PDF/UA, reading order, focus, low-vision mode.
Delphi-kodexempel
Följande Delphi-skiss visar en praktisk servicegräns för detta ämne. Håll policykontroller, loggning och validering utanför det smala produktanropet så att arbetsflödet går att testa.
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;Produktionschecklista
- Kör arbetsflödet på en tom fil, en normal kundfil och en värstafallfil
- Öppna den genererade PDF-filen med rätt visare, validator, skrivare eller nedströmsapplikation
- Logga produktversion, profilversion, inmatningshash, utdatasökväg, förfluten tid och antal varningar
- Håll lösenord, certifikat, tillfälliga filer och kunddata under tydliga lagringsregler
- Lägg till regressionsdokument när en kundfil avslöjar ett nytt gränsfall
Produktdokumentation
Fler kodexempel
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;