Delphi에서 스캔 문서 PDF/raster 검증하기

ISO 23504-1로 표준화된 PDF/R은 스캔 문서를 위한 PDF 프로파일입니다. 모든 페이지는 정확히 하나의 스트립 이미지를 담고 그 외에는 아무것도 담지 않습니다. PDFium Component는 ValidatePdfRCompliance를 통해 Delphi, Lazarus, C++Builder에서 그것을 검증하며, 이 함수는 스트림을 읽고 규정 준수 수준과 구체적인 문제 집합을 반환합니다

이 프로파일이 존재하는 이유는 스캐너와 문서 캡처 시스템이 PDF/A보다 좁은 목표를 필요로 했기 때문입니다. 보존용 PDF는 파트가 허용하는 모든 것을 담을 수 있지만, 래스터 PDF는 의도적으로 빈약하여, 규칙을 준수하는 모든 리더가 동일하게 표시하고 규칙을 준수하는 모든 작성기가 저작 엔진 없이 스캔에서 그것을 생산할 수 있습니다

PDF/R은 PDF/A가 허용하는 무엇을 금지하는가

실질적으로 텍스트입니다. 래스터 페이지는 스캔된 이미지만 담고 그 외에는 아무것도 담지 않으므로, 페이지의 폰트 리소스는 위반입니다. ISO 23504-1 §6.5.2 아래 pvriFontForbidden으로 보고됩니다. 이것은 검색 가능성을 위해 보이지 않는 OCR 텍스트 레이어를 추가하는 사람들을 놀라게 하는데, 그것은 PDF/A 워크플로에서는 정상적이고 유용한 일이지만 PDF/R은 단순히 아닙니다

페이지와 이미지의 관계도 똑같이 엄격합니다. §6.5.1이 모든 페이지를 정확히 하나의 스트립 이미지로 만들므로, 이미지 수가 페이지 수와 일치하지 않을 때 pvriPageImageMismatch가 발화합니다. 이미지가 없는 페이지와 이미지가 두 개인 페이지는 둘 다 비준수입니다. 그리고 pvriBadMediaBox는 MediaBox가 [0 0 w h] 형태가 아닌 페이지를 보고하는데(§6.5.3), 스캔은 오프셋 원점에 앉을 이유가 없기 때문입니다

uses FPdfPdfr;

var
  Src: TFileStream;
  Res: TPdfRValidationResult;
begin
  Src := TFileStream.Create('scan-batch-0142.pdf', fmOpenRead or fmShareDenyWrite);
  try
    Res := ValidatePdfRCompliance(Src);
    if Res.IsCompliant then
      Memo1.Lines.Add('PDF/R-1 conformant')
    else
    begin
      if pvriFontForbidden in Res.Issues then
        Memo1.Lines.Add('A page names a font resource; a raster page carries no text');
      if pvriPageImageMismatch in Res.Issues then
        Memo1.Lines.Add('Image count does not match page count');
      if pvriForbiddenImageFilter in Res.Issues then
        Memo1.Lines.Add('A strip image uses an encoding outside the white list');
    end;
  finally
    Src.Free;
  end;
end;

어떤 이미지 인코딩이 허용되는가

네 가지이며, 화이트리스트는 이유가 있어 짧습니다. §6.6은 /CCITTFaxDecode, /DCTDecode, /JPXDecode, /FlateDecode를 인정합니다. 2레벨 팩스, JPEG, JPEG 2000, 무손실 deflate이며, 그 사이에서 의미가 있는 모든 스캐너 출력을 커버합니다. 그 외의 모든 것은 pvriForbiddenImageFilter로 보고되며, 여기에는 /LZWDecode, /RunLengthDecode, /ASCII85Decode, /ASCIIHexDecode, /JBIG2Decode, /Crypt가 포함됩니다

그 거부 중 두 가지는 암기보다 이해할 가치가 있습니다. /JBIG2Decode는 2레벨 스캔을 극도로 잘 압축하며 PDF/A에서 완전히 합법적이지만, 그 심볼 딕셔너리 재구성이 시각적으로 유사한 글리프를 치환할 수 있습니다. 스캔된 숫자에 대한 문서화된 실패 모드이며, 충실한 래스터 재현이 전체 목적인 프로파일은 그 위험을 인정할 수 없습니다. ASCII 필터는 반대 이유로 제외됩니다. 래스터 프로파일이 필요로 하는 것은 아무것도 추가하지 않으면서 파일을 부풀립니다

어떤 페이지를 읽기 전에 발화하는 구조 규칙

PDF/R은 컨테이너도 제약합니다. pvriObjStmPresent는 /Type /ObjStm 스트림을 보고하며, 프로파일은 그것을 전면 금지합니다. 객체 스트림은 래스터 리더가 할 수 있어야 하는 단순하고 순차적인 파싱을 복잡하게 만듭니다. pvriBadHeader는 %PDF-1.4에서 1.7과 %PDF-2.0 바깥의 헤더를 보고하며, pvriEncryptVersionMismatch는 §6.2.3에 따라 헤더가 %PDF-2.0이 아닌 암호화된 파일을 보고합니다

카탈로그와 Info 딕셔너리는 단순히 검사되는 것이 아니라 화이트리스트됩니다. pvriProhibitedCatalogEntry와 pvriProhibitedInfoEntry는 허용된 집합 바깥의 항목에 대해 발화하며, pvriInfoXmpMismatch는 Info 항목이 그에 해당하는 XMP와 다를 때 발화합니다. 누락된 카탈로그 /Metadata 스트림, 누락된 트레일러 /ID, 부재하는 %PDF-raster-1.0 푸터 마커도 각각 자신의 문제를 가집니다

저장 옵션 레코드가 Title과 Author를 생략하는 이유

TPdfRSaveOptions는 Creator, Producer, CreationDate, ModDate, DocumentId, InstanceId를 담으며, 의도적으로 Title, Author, Subject, Keywords를 위한 필드가 없습니다. 그 네 가지는 §6.4.3이 금지하는 항목이므로, 그것을 노출하는 레코드는 호출자에게 규칙을 준수하는 API를 통해 비준수 파일을 기록하도록 초대하는 것이 될 것입니다

두 불리언 옵션이 기존 PDF를 변환할 때 정리를 통제합니다. StripInfoOptionalEntries는 기본값이 True이며 소스 Info 딕셔너리에서 Title, Author, Subject, Keywords, Trapped를 제거합니다. StripCatalogOptionalEntries도 기본값이 True이며 Names, Outlines, StructTreeRoot, OutputIntents, Lang과 나머지를 제거하여 §6.3 화이트리스트만 남깁니다. 어느 쪽이든 False로 설정하면 항목을 유지합니다. 그리고 규정 준수를 잃습니다. 이것이 간혹 호출자가 내부 파일에 대해 진정으로 원하는 것이기도 합니다

var
  Opts: TPdfRSaveOptions;
  Src, Dest: TFileStream;
begin
  Opts := TPdfRSaveOptions.Default;
  Opts.Creator := 'Capture Station 4';
  Opts.Producer := 'PDFium Component';
  Src := TFileStream.Create('scan-in.pdf', fmOpenRead or fmShareDenyWrite);
  try
    Dest := TFileStream.Create('scan-pdfr.pdf', fmCreate);
    try
      InjectPdfRMarkers(Src, Dest, Opts);   // markers + metadata, not page content
    finally
      Dest.Free;
    end;
  finally
    Src.Free;
  end;
end;

마커 주입이 하지 않는 것에 유의하십시오. 메타데이터와 식별을 추가하며, 페이지 콘텐츠를 공급할 수는 없습니다. 스트립 이미지를 담지 않은 소스 페이지는 주입 후에도 여전히 pvriPageImageMismatch에서 실패하는데, 누락된 이미지는 결코 메타데이터 문제가 아니었기 때문입니다

캡처 파이프라인에서 PDF/R이 들어맞는 곳

인도물이 스캔 자체이고 충실도가 전체 계약인 곳에 사용하십시오. 증거 이미징, 수표와 송금 캡처, 대형 포맷 스캐너에서의 엔지니어링 도면 아카이브가 그것입니다. 문서가 검색 가능한 텍스트, 태깅, 임베드된 첨부파일, 래스터 프로파일이 벗겨내는 그 외의 무엇이든 필요로 하는 순간 PDF/A를 대신 사용하십시오

흔하고 실무적인 배치는 둘 다 생산하는 것입니다. 결코 변하지 않는 PDF/R 원본과, 검색을 위해 OCR 레이어를 가진 PDF/A 파생물입니다. 검증기는 독립적이므로 같은 배치 작업이 각 산출물을 그것이 실제로 주장하는 프로파일에 대해 검사할 수 있습니다. 그 쌍의 보존 쪽은 PDF/A 보존 규정 준수와 PDF/A 프리플라이트 검증에 관한 글을 보고, 인쇄 지향 출력은 인쇄용 PDF/X 문서 검증 산책문을 보십시오

PDFium Component는 PDFium 엔진을 Delphi, C++Builder, Lazarus에 VCL API와 PDF/A, PDF/X, PDF/E, PDF/UA, PDF/R을 위한 규정 준수 검증기와 함께 가져옵니다. PDFium Component 제품 페이지에 지원 표준과 IDE 버전이 나열되어 있습니다