PDF 텍스트 추출

글자는 어디에서 오고, 어떤 순서로 나오는가

PDF 속 글자는 텍스트로 저장되어 있지 않습니다. 내장된 글꼴을 가리키는 글리프 번호로 저장되며, 이를 다시 문자로 바꾸려면 각 글리프가 어떤 문자인지 알려 주는 파일 안의 표가 필요합니다. 대부분의 프로그램은 이 표를 넣습니다. 넣지 않은 경우(일부 디자인 소프트웨어가 만드는 축소된 글꼴 서브셋이 흔한 원인입니다)에는 화면에서는 완벽해 보여도 추출하면 알 수 없는 문자열이 나옵니다. 읽는 데 필요한 정보가 애초에 기록되지 않았기 때문입니다. 어떤 추출 도구도 이를 고칠 수 없습니다. 어려운 문제가 아니라 데이터가 없는 것입니다.

결과를 믿기 전에 확인해야 할 것은 읽는 순서입니다. 텍스트는 페이지가 그려지는 순서, 즉 PDF를 만든 소프트웨어가 내보낸 순서대로 나오며, 이는 사람이 읽는 순서와 다른 경우가 많습니다. 2단 페이지는 PDF가 어떻게 생성되었느냐에 따라 왼쪽 단과 오른쪽 단이 제대로 나뉘어 나오기도 하고, 두 단의 줄이 번갈아 섞여 나오기도 합니다. 머리글, 바닥글, 페이지 번호, 사이드바는 그려진 위치 그대로, 대개 본문 한가운데에 끼어듭니다.

몇 가지 작은 현상은 당황하기보다 알아 두는 편이 좋습니다. 합자는 글꼴이 실제로 사용한 한 글자로 나오기 때문에 “find”가 f와 i가 아닌 하나의 글리프로 나올 수 있고, 그러면 “find”를 단순 검색했을 때 찾지 못합니다. 줄 끝에서 하이픈으로 나뉜 단어는 파일 안에서도 실제로 나뉘어 있으므로 하이픈이 그대로 남습니다. 또한 곧은 따옴표가 둥근 따옴표로 되어 있는 경우가 많아, 텍스트를 코드나 CSV에 넣을 때 문제가 될 수 있습니다.

스캔한 페이지에서는 아무것도 나오지 않으며, 이 도구는 빈 파일을 건네는 대신 그 사실을 알려 줍니다. 문서를 찍은 사진에는 글자가 없고 픽셀만 있기 때문입니다. 윤곽선으로 변환된 텍스트도 마찬가지입니다. 디자이너가 어디서나 똑같이 인쇄되도록 일부러 하는 작업인데, 그 시점부터는 사실상 그림입니다. 두 경우 모두 추출이 아니라 OCR이 필요합니다.

다른 작업이 필요할 때

단 구성이 중요하다면 Poppler의 pdftotext -layout in.pdf out.txt가 브라우저로 할 수 있는 어떤 방법보다 낫습니다. 실제 공백으로 시각적 간격을 재현하기 때문에 단은 단대로, 표는 읽을 수 있는 표 모양대로 유지됩니다. pdftotext -raw는 반대로 그려진 순서를 손대지 않고 그대로 내보내는데, 스크립트에서는 가끔 이쪽이 필요합니다.

수백 개 파일에서 텍스트를 뽑아야 한다면 mutool draw -F txt와 Python의 pdfplumber를 기반으로 삼으세요. 특히 pdfplumber는 모든 글자를 좌표, 글꼴, 크기와 함께 넘겨주므로 머리글과 바닥글을 짐작이 아닌 위치로 걸러 낼 수 있습니다. 이 페이지로는 할 수 없는 작업이며, 대량 처리에서 중요한 것이 바로 이 부분입니다.