기술 문서

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

  1. configure document generation around the target profiles before output
  2. run structured preflight and normalize findings by owner and severity
  3. route template issues to template maintainers and data issues to application owners
  4. rerun validation after each fix rather than relying on visual inspection
  5. 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;