대부분의 PDF 추출기는 잘못된 API를 사용합니다
대부분의 PDF 도구는 잘못된 데이터 소스를 사용합니다.
개발자들이 PDF 추출에 대해 이야기할 때, 보통 getTextContent()를 의미합니다. 이 메서드는 텍스트 항목과 그 위치를 제공합니다. 이는 거의 모든 브라우저 기반 도구의 기본값입니다.
하지만 getTextContent()는 가공된 뷰입니다. 실제로 사용 가능한 데이터의 단순화된 버전일 뿐입니다.
PDF.js에는 세 가지 수준의 데이터가 있습니다:
• getStructTree(): 문서의 의미를 알려줍니다. 표, 제목, 수식을 포함합니다.
• getOperatorList(): 문서가 무엇을 그리는지 알려줍니다. 선, 경로, 도형을 포함합니다.
• getTextContent(): 문서가 그리는 내용의 필터링된 뷰입니다.
대부분의 도구는 세 번째 옵션을 사용합니다. 이는 간단한 보고서와 같은 문서의 80%에는 효과적입니다. 하지만 학술 논문이나 복잡한 간행물에서는 실패합니다.
getTextContent()만 사용하면 네 가지 주요 문제가 발생합니다:
- 표 구조를 잃게 됩니다. 텍스트 위치를 기반으로 셀의 위치를 추측해야 합니다.
- 수학 방정식이 깨집니다. LaTeX 방정식은 종종 하나의 거대한 텍스트 블록으로 나타납니다.
- 열 구분선을 놓칩니다. 많은 레이아웃이 열을 구분하기 위해 실제 선을 사용합니다. 이러한 선은 텍스트 콘텐츠에 존재하지 않습니다.
- 읽기 순서가 잘못됩니다. 텍스트는 사람이 읽는 방식이 아니라 그려진 순서대로 나타나는 경우가 많습니다.
PDF 프로세서를 구축하는 올바른 방법은 3단계 시스템입니다:
- 먼저
getStructTree()를 확인합니다. 문서에 논리적 구조가 있다면, 이를 사용하여 즉시 표와 제목을 찾습니다. - 다음으로
getOperatorList()를 확인합니다. 명시적인 선과 경로를 사용하여 열 경계를 찾습니다. getTextContent()를 폴백(fallback)으로 사용합니다. 처음 두 단계에서 데이터를 제공하지 않을 때만 기하학적 계산을 사용합니다.
이 접근 방식은 일이 더 많아지는 것이 아닙니다. 1단계와 2단계는 빠른 종료(fast exit) 역할을 합니다. 문서 구조가 잘 잡혀 있다면 어려운 수학 계산을 건너뛸 수 있습니다. 문서에 태그가 지정되지 않은 경우에만 복잡한 추론을 사용합니다.
이 아키텍처는 간단한 기업용 파일과 복잡한 과학 논문을 모두 처리할 수 있습니다.
출처: https://dev.to/bonzai2carn/most-pdf-extractors-use-the-wrong-api-heres-what-we-built-instead-5dgh