PDF를 텍스트로 변환하기는 어려운 문제임

 (marginalia.nu)
4P by GN⁺ | ★ favorite | 댓글 1개
  • 검색 엔진에 PDF 인덱싱이 추가됐지만, PDF에서 검색에 쓸 만한 구조화 텍스트를 얻는 일은 HTML 처리보다 훨씬 까다로움
  • PDF는 텍스트 문서라기보다 좌표 기반 그래픽 형식에 가까워 글리프가 회전·겹침·순서 뒤섞임 상태로 배치될 수 있음
  • PDFBox의 PDFTextStripper는 출발점이 될 수 있지만, 제목·문단 같은 의미 구조를 충분히 살리지 못해 검색 관련성 판단에 한계가 있음
  • 제목과 문단을 구분하려면 문서 전체 기준보다 페이지별 글꼴 크기 통계와 줄 간격 중앙값 같은 휴리스틱이 더 유용함
  • 완벽한 PDF 텍스트 추출은 어렵기 때문에, 검색 엔진에는 제목·초록·본문 구조를 안정적으로 얻는 충분히 좋은 해법이 현실적인 목표임

PDF 인덱싱을 추가하며 드러난 문제

  • 검색 엔진은 최근 PDF 파일 형식을 인덱싱할 수 있게 되었고, 변경 사항은 몇 달 동안 배포될 예정임
  • 검색 엔진 입장에서는 깔끔한 HTML이 가장 다루기 쉽지만, PDF는 같은 수준의 구조화 텍스트를 바로 제공하지 않음
  • 겉으로는 텍스트가 보이더라도, PDF 내부에서 검색 가능한 문장과 문단을 복원하는 일은 별도 문제에 가까움

PDF가 텍스트 추출에 어려운 이유

  • PDF는 일반적인 텍스트 형식이 아니라 그래픽 형식에 가까움
  • 내부 표현은 문장이나 문단보다 “종이” 위 좌표에 글리프를 배치한 형태에 가까움
  • 글리프는 다음과 같은 상태일 수 있음
    • 회전되어 있음
    • 서로 겹쳐 있음
    • 읽는 순서와 다르게 나타남
    • 붙어 있는 의미 정보가 매우 적음
  • PDF 뷰어나 브라우저에서 ctrl+f 검색이 되는 것 자체가 꽤 놀라운 결과임
  • 비전 기반 머신러닝 모델이 현재로서는 좋은 접근일 수 있지만, GPU 없는 단일 서버에서 수백 GB의 PDF를 처리하는 규모에는 맞지 않음

PDFBox로 시작할 수 있지만 충분하지 않음

  • 완전히 미개척 문제는 아니어서 PDFBox의 PDFTextStripper 클래스를 출발점으로 삼을 수 있음
  • PDFTextStripper는 PDF에서 텍스트를 추출하지만, 이름 그대로 텍스트를 벗겨내는 데 초점이 있음
  • 검색 엔진에는 제목 같은 의미 정보가 중요한 관련성 신호인데, 기본 추출 결과만으로는 이런 구조를 충분히 얻기 어려움

제목을 찾기 위한 휴리스틱

  • 가장 단순한 제목 탐지는 다른 텍스트와 떨어져 있는 semibold 이상 굵기의 줄을 찾는 방식임
  • 하지만 모든 제목이 굵게 표시되지는 않고, 많은 문서는 글꼴 크기로 제목을 구분함
  • 전역 글꼴 크기 기준점은 문서마다 흔들림
    • 어떤 문서는 본문 10pt, 제목 16pt를 쓸 수 있음
    • 다른 문서는 본문 14pt, 제목 20pt를 쓸 수 있음
  • 문서 전체보다 페이지별 통계가 더 적합할 때가 있음
    • 첫 페이지는 초록과 저자 목록 때문에 나머지 페이지와 글꼴 선택이 크게 다를 수 있음
    • 예시 문서에서는 문서 제목에 17 크기 글꼴이 쓰이고, 이후 제목에는 14 크기 글꼴이 쓰임
  • 각 페이지에는 대체로 본문에 해당하는 지배적 글꼴 크기가 있음
  • 페이지별 중앙 글꼴 크기에 약 20% 정도의 계수를 붙이면 제목을 꽤 안정적으로 식별할 수 있음
  • 예외는 남지만, 중요한 사례 대부분은 잡아낼 수 있음

여러 줄 제목을 하나로 합치기

  • 제목은 스타일 때문에 여러 줄로 나뉘는 경우가 많아, 연속된 제목 줄을 하나로 합쳐야 할 때가 있음
  • 언제 합칠지 정하는 기준은 단순하지 않음
  • 예시에는 다음 조건이 함께 나타남
    • 두 줄짜리 제목
    • 오른쪽 정렬된 제목
    • 제목 뒤에 이어지는 semibold 저자명
    • 몇 줄 아래에 있는 굵지 않은 제목
  • 들여쓰기는 문단 구분 신호로도 쓰이므로, 오른쪽 정렬된 제목은 판단을 더 어렵게 만듦
  • 같은 글꼴 크기와 굵기를 가진 연속 제목을 합치는 방식은 대체로 잘 동작하지만, 원치 않는 결과도 만들 수 있음

문단 식별에서 줄 간격이 만드는 함정

  • PDFTextStripper는 문단 식별을 꽤 잘 수행함
  • 줄 간격과 들여쓰기를 함께 보면서 문단을 나눌 위치를 판단함
  • 개선 여지는 특히 줄 간격 로직에 있음
  • PDFTextStripper의 큰 문제는 줄 분리에 고정 기준점을 쓴다는 점임
    • 기준점보다 줄 간격이 크면 같은 문단이 아니라고 판단함
    • 문서마다 줄 간격이 다르다는 점을 충분히 반영하지 못함
  • 학술 초안과 프리프린트에서는 1.5~2배 줄 간격이 꽤 흔함
  • 기준값을 너무 크게 잡으면 일부 제목이 본문 문단에 흡수되어 제목 식별을 방해할 수 있음

줄 간격 통계로 보정하기

  • 글꼴 크기 처리와 비슷하게, 줄 사이 거리에도 통계적 기법을 적용할 수 있음
  • 텍스트 페이지에서 줄 사이 거리 히스토그램을 만들면 큰 이상치가 나타나는 경향이 있음
  • 평균값은 이상치에 흔들리기 쉽지만, 중앙값은 본문에 사용된 줄 간격과 정확히 맞는 경우가 있음
  • 중앙값에 일정 계수를 붙이면 다양한 줄 간격에서도 버티는 문단 분리 휴리스틱을 만들 수 있음

현실적인 목표는 완벽보다 안정성

  • PDF에서 텍스트를 추출하는 작업은 완벽해지기 어려움
  • PDF 형식 자체가 그런 작업을 위해 설계되지 않았고, “충분히 좋은” 해법을 고를 때 여러 트레이드오프가 생김
  • 검색 엔진은 특히 다음 정보에 관심이 큼
    • 제목 같은 관련성 신호
    • 초록 식별
    • 나머지 텍스트의 어느 정도 일관된 구조
  • 이런 목표라면 대부분의 관련 문서를 비교적 무리 없이 처리하는 해법에 접근할 수 있음

사용된 샘플 텍스트

  • Can Education be Standardized? Evidence from Kenya (2022) - Working Paper
  • Guthrie Gray-Lobe, Anthony Keats, Michael Kremer, Isaac Mbiti, Owen W. Ozier
  • The theory of ideas and Plato’s philosophy of mathematics (2019)
  • Dembiński, B.
  • The role of phronesis in Knowledge-Based Economy (2024)
  • Anna Ceglarska, Cymbranowicz Katarzyna

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 예전에 몇 달, 몇 년씩 파고들어 전문가 수준이 됐던 걸 완전히 잊고 있다가, 나중에 “이거 새롭고 흥미롭네”라고 느끼는 일이 있음
    흥미로운 일을 꽤 많이 해놓고도 기억에서 사라져서, 뭔가가 계기가 되기 전까지는 인생을 새로 시작하는 사람처럼 느껴짐
    6~7년 전쯤 PDF와 OCR로 꽤 멋진 작업을 했던 기억이 어렴풋하고, 찾아보니 Tesseract였던 것 같음

    • 2006년쯤 iRex라는 초기 전자책 단말에서 다단 과학 논문의 텍스트 복사가 안 돼서 원인을 파고들었고, PDF 리더가 내부적으로 Poppler를 쓰길래 Tesseract 저자 Thomas Breuel이 발표한 OCR 알고리즘을 참고해 다단 문서의 읽기 순서를 추론하도록 Poppler를 수정했음
      휴리스틱에 가까운 해킹이었고, 당시 Poppler의 오래된 API는 접근성 API에 적합한 방식으로 텍스트 런을 표현하지 않았던 것 같음
      다단 선택 기능은 어느 정도 들어갔지만, 이후 성능 개선 제안은 휴리스틱이 조금 달라 일부 상황에서 선택 결과가 달라진다는 이유로 유지보수자를 설득하기 어려웠음
      애초에 “정답”이 하나가 아니어서 결과 일치를 요구하는 건 말이 안 됐고, 그렇게 kpdf의 다단 선택이 어느 정도 생겼음
      요즘은 이런 용도에 Tesseract를 직접 쓰는 쪽이 더 합리적일 가능성이 큼
    • 이 형식 때문에 집단적으로 태워버린 수십 년 단위의 인력 시간은 절대 되돌릴 수 없음
      이 광기는 언제 끝날지 모르겠음
    • Tesseract는 오랫동안 최고의 오픈소스 OCR이었지만, 지금은 docTR이 더 낫다고 봄
      기본 정확도가 더 높고 GPU 가속이 되며, 여러 텍스트 검출·인식 모델 구조를 조합 가능한 파이프라인으로 구현함
      PyTorch나 TensorFlow로 학습·미세조정해서 특정 도메인 성능도 더 끌어올릴 수 있음
    • 누가 C++ 질문을 했을 때 “C++로 진지하게 일해본 적은 없다”고 답했다가, 20년 전쯤 Borland C++ 로 수천 명이 쓰던 사설 메신저 클라이언트 코드를 작성했다는 걸 떠올린 적 있음
      그래서 실제로 그런 일이 생김
    • 프로젝트를 끝낼 때마다 “이제 이걸 하는 데 전문가가 됐네. 그런데 아마 다시는 안 하겠지”라고 느끼는 일이 많음
      다음 일은 전혀 다른 분야라서 다시 기초부터 시작하게 됨

  • 누군가 PDF용 브라우저 개발자 도구 같은 걸 만들어주면 좋겠음
    “요소 검사”처럼 PDF의 콘텐츠 스트림을 소스로 보고, BT … ET 텍스트 연산자나 Tj 텍스트 배치 연산자가 각 픽셀을 어떻게 지정·생성하는지 확인할 수 있으면 좋겠음
    요즘 흐름처럼 시각 모델이 PDF를 사람처럼 “보고” 읽는 것과는 반대지만, 실제로 PDF 파일 안에 뭐가 들어 있는지 이해할 수 있으면 훨씬 좋음
    PDF 내용을 검사하는 도구는 몇 가지 있지만(https://news.ycombinator.com/item?id=41379101), PDF 객체 수준에서 멈춰서 콘텐츠 스트림 전체가 하나의 객체로만 보임
    예를 들어 글에서 언급된 https://bfi.uchicago.edu/wp-content/uploads/2022/06/BFI_WP_2...의 6쪽 PDF 페이지 8에는 BT, 폰트 설정, Td, TJ 같은 연산자로 텍스트가 배치됨
    이런 “소스”와 렌더링된 PDF를 나란히 보고, 한쪽에 마우스를 올리면 다른 쪽의 대응 영역이 강조되는 식이면 HTML 페이지처럼 디버깅할 수 있을 것 같음

    • Mozilla의 PDF.js로 PDF를 DOM에 렌더링하면 꽤 가까운 결과가 나올 수 있음
      예를 들어 각 Tj가 DOM 요소 하나가 되고, TJ는 여러 요소의 묶음이 되는 식일 것 같음
      원본 문서를 제대로 반영해야 작동하므로 상당히 충실하게 변환할 가능성이 큼
    • cpdf로 어느 정도 가능함
      cpdf -output-json -output-json-parse-content-streams in.pdf -o out.json로 JSON을 만들고, 그 JSON을 만진 뒤 cpdf -j out.json -o out.pdf로 다시 PDF로 되돌릴 수 있음
      다만 실시간 양방향 연동은 없음
    • 오픈소스나 무료를 말한 거겠지만, 몇 년 전 써본 Acrobat Pro도 거의 비슷한 기능이 있었음
      다만 페이지를 검사하는 방식이 아니라 콘텐츠 트리를 탐색하는 방식이었고, 페이지 위의 객체는 강조해줬음
      명령 단위까지는 아니고 객체나 스트림 수준까지만 가능했음
    • 이 노트북이 정확히 원하는 건 아니지만, PDF 안의 여러 그리기 연산을 “실시간”으로 검사하는 기능을 제공함
      https://observablehq.com/@player1537/pdf-utilities
    • Tensorlake에서 만드는 것도 이 조합에 가까움
      PDF를 사람처럼 “보고” 텍스트만 읽는 게 아니라, 표·이미지·텍스트·수식·손글씨까지 포함한 내용을 이해하려는 방향임
      그래서 PDF를 파싱하고 여러 모델을 돌려 Markdown 조각이나 JSON을 추출해, 실제 데이터를 AI 에이전트·LLM·기타 애플리케이션에 넣을 수 있게 함
      https://tensorlake.ai

  • “PDF를 텍스트로”는 너무 단순화된 표현임
    이 범주 안에는 1) 검색 색인이나 벡터 DB 입력을 위한 신뢰성 있는 OCR, 2) 특정 값을 뽑는 구조화 데이터 추출, 3) 모기지 신청 자동화 같은 종단 간 문서 파이프라인이 있음
    Marginalia가 풀어야 하는 건 1번 OCR이고, Gemini Flash 같은 모델 덕분에 빠르게 범용화되고 있음
    여러 회사가 기존 OCR 파이프라인을 Flash로 대체하면서 비용을 크게 줄이는 걸 봤고 꽤 놀라움
    하지만 2번과 3번은 훨씬 어렵고, 원시 OCR 출력에서 운영 환경의 미션 크리티컬 문서 파이프라인까지 가려면 아직 간극이 큼
    LLM과 시각 언어 모델은 마법이 아니며, 100% 자동화를 기대하면 놀라게 됨
    데이터셋 구축·라벨링, 분류 -> 분할 -> 추출 파이프라인 오케스트레이션, 불확실성 감지와 사람 검수, 미세조정 등이 여전히 필요함
    장기적으로는 거의 완전 자동화에 가까워질 수 있지만 시간과 노력이 필요하고, 미래가 이 방향으로 가는 건 분명해 보임
    관련해서 https://extend.ai라는 LLM 문서 처리 회사를 시작했음

    • 접근성 관점에서는 4번, 즉 다양한 문서 유형 전반에서 작동하는 신뢰성 있는 OCR과 의미 추출도 필요함
      비즈니스 워크플로는 몇 가지 정해진 문서만 다루는 경우가 많지만, 범용 PDF 리더는 사용자가 어떤 문서를 열지 알 수 없음
      텍스트뿐 아니라 표, 머리말·꼬리말, 각주, 제목, 수학식 등을 인식해야 함
      사람 소비용이므로 오류를 최소화해야 해서 불필요할 때 OCR을 쓰면 안 되고, PDF에 포함된 기본 텍스트를 활용하면서도 의미 구조를 추출해야 함
      결국 이미지뿐인 PDF와 콘텐츠 스트림에서 정보를 얻을 수 있는 PDF를 위한 두 경로가 필요함
      그런데 콘텐츠 스트림에는 실제 화면과 다른 텍스트가 들어갈 수 있음. 흰색 글자로 숨긴 정보나, 유니코드 악센트 대신 명령으로 악센트 기호를 그리는 LaTeX식 구현 같은 경우가 있음
      보통 사용자의 저성능 기기에서 로컬 앱으로 돌고, 서버나 구독 모델이 없을 가능성이 커서 클라우드 AI 모델도 못 씀
      접근성 소프트웨어 사용자는 출력해서 펜으로 작성하기 어려울 수 있으므로, 명세에 맞는 깔끔한 양식뿐 아니라 인쇄용 양식도 처리해야 함
      이건 아직 해결에 전혀 가깝지 않은 열린 문제이고, 현재 해법들은 모두 어떤 방식으로든 부족하며 위 5가지를 모두 제대로 푸는 단일 해법은 없음
    • 시각 언어 모델이 너무 불안정해서 직접 도구를 만들어야 했던 입장에서, 처리되지 않은 이미지에 VLM을 쓰는 회사는 큰 고통을 겪게 될 가능성이 큼
      이미지 라벨링은 아주 잘하고, 단일 열 텍스트·가운데 정렬된 단일 단계 제목·페이지당 이미지나 표 하나 같은 단순 문서에는 괜찮음
      대부분의 MVP 데모가 이런 예시를 보여줌
      하지만 표와 이미지가 섞인 복잡한 문서에서는 아직 훨씬 더 많은 파라미터가 있어야 “나쁜 수준”이라도 될 것 같음
      지금은 환각이 너무 심해서, 위에 제목이 있고 가운데 데이터가 있으며 아래에 요약이 있는 단순한 표조차 그대로 쓰기 어려움
    • PDF를 Markdown으로 처리하려고 계속 손보고 있는데, 원글처럼 헤더 감지와 여러 문제에 부딪힘
      요즘 OCR은 훌륭하지만 문서의 전역 구조를 유지하는 건 훨씬 까다로움
      큰 문서에서 일관된 HTML을 얻는 건 아직 멀어 보이고, LLM을 여러 번 통과시켜 문서 구조를 추출한 뒤 페이지별 추출에 문맥으로 넣는 방식으로 Markdown은 어느 정도 괜찮은 결과가 나옴

  • Apple에서 여러 해 동안 이 문제를 꽤 성공적으로 다뤘는데, 핵심 비결은 모든 것을 기하 구조로 받아들이고 군집 분석으로 단어 간격과 글자 간격을 구분하려 한 것이었음
    많은 PDF에서는 아주 잘 작동하지만 PDF 종류가 너무 다양해서 결과가 별로인 경우도 항상 있음
    지금 다시 한다면 기하 구조는 유지하고 OCR은 완전히 피하되, 기계학습을 쓸 것 같음
    기계학습의 큰 장점은 알려진 텍스트에서 PDF를 생성하는 기존 도구를 활용해 학습 단계를 완전히 자동화할 수 있다는 점임
    Bertrand Serlet이 WWDC 2009에서 이 기능을 발표한 장면: https://youtu.be/FTfChHwGFf0?si=wNCfI9wZj1aj9rY7&t=308

  • 더 나은 해법은 PDF 안에 편집 가능한 원본 문서를 함께 임베드하는 것임
    LibreOffice에서는 쉽게 가능하고, 압축이 잘 되기 때문에 보통 공간도 거의 안 듦
    그러면 텍스트와 의미에 대해 훨씬 더 좋은 정보를 얻을 수 있으며, 기존 PDF 리더에서도 잘 작동함

    • 맞는 말이지만, PDF 생성자와 소비자의 이해관계가 맞아야 함
      전자증거개시 분야에서는 증거 제공자가 상대측 변호사가 내용을 소비하기 어렵게 하려고 일부러 PDF로 덤프하는 일이 흔함
      양쪽이 돈이 많으면 장벽이 아니지만, 예를 들어 국선변호인은 PDF를 읽기 쉬운 형식으로 처리할 사람을 고용할 자금이 없어 처리 시간이 훨씬 길어지고, 피고인에게 심리적 부담이 커짐
      심지어 데이터를 제대로 처리하지 못할 수도 있음
      해법은 이런 행위를 불법화하는 것임
      예를 들어 감청 데이터는 표준화된 기계 판독 가능 형식으로 제공돼야 하며, 단순한 기술적 마찰이 형사절차 결과에 영향을 주는 데 윤리적 이유는 없음
    • 기존 PDF에서 텍스트를 추출해야 하는 검색 엔진 문제의 더 나은 해법이, PDF 작성 방법에 대한 조언이라는 건 이상함
      이 해법이 효과를 내기까지 어느 정도 시간이 걸릴지 의문임
    • 맞지만, 원본 문서가 렌더링된 PDF 내용과 임의로 다를 수 있는 취약점도 생김
    • 문제 공간의 90%는 레거시 PDF일 것 같음
      회사에도 이런 파일이 수천 개 있고, 일부는 형편없는 스캔본이며, 일부는 Adobe OCR이 임베드돼 있지만 대부분은 아무것도 없음
    • PDF를 만든 원본 문서에 접근할 수 있다면 좋은 방법임
      하지만 일반적으로는 그런 통제권이 없음

  • 아래 PDF는 사실 .txt 파일임
    .pdf 확장자로 저장하면 PDF 뷰어에서 열 수 있고, 텍스트 편집기로 수정할 수도 있음
    예를 들어 이 텍스트 파일을 편집해서 PDF를 열었을 때 화면에 표시되는 텍스트, 글꼴, 글자 크기, 줄 간격, 줄당 최대 문자 수, 페이지당 줄 수, 종이 너비와 높이, 세로·가로 방향까지 바꿀 수 있음
    예시는 %PDF-1.4로 시작하는 최소 PDF 구조로, Catalog, Pages, Font, Page, Contents, xref, trailer 등을 직접 텍스트로 작성한 형태임

    • PDF에는 임베드된 바이너리 스트림도 들어갈 수 있음
      PDF는 텍스트를 위해 만들어진 게 아니라 레이아웃과 그래픽을 위해 만들어졌음
      예시는 좋지만, 각 줄은 문자 하나당 호출 하나, 단어 하나당 호출 하나로 쪼개질 수도 있고, 순서가 뒤섞일 수도 있음
    • “PDF”는 “Portable Document Format”의 약자임
      PDF 1.0 참조 문서의 “2.3.2 Portability”에서는 PDF 파일을 7비트 ASCII 파일로 설명하며, 이미지와 특수문자를 포함한 문서도 ASCII의 출력 가능한 부분집합만 사용해 기술한다고 되어 있음
      그 결과 다양한 하드웨어와 운영체제 환경에서 매우 이식성이 높다고 설명함
      https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
    • 이건 PDF의 Hello World에 가까움
      요즘 PDF 대부분은 모든 객체가 deflate로 압축돼 있음
      게다가 따라가기 더 어렵게 만들려고 많은 PDF는 객체 대부분을 객체 스트림 타입 객체 안에 묶은 뒤 다시 압축함
      그래서 6 0 R의 끝을 추적하려고 해도 텍스트 편집기에서 6 0 Obj를 검색할 수 없음

  • 이 글에서 설명한 어려움을 보여주는 좋아하는 문서가 있음: https://academic.oup.com/auk/article/126/4/717/5148354
    첫 페이지부터 전형적인 2단 텍스트, 가운데 정렬 제목, 두 단 사이에 끼어 줄 길이와 들여쓰기를 바꾸는 텍스트 박스가 있음
    이후에는 홀수·짝수 페이지마다 바뀌는 머리말, 크게 달라지는 섹션 헤더 규칙까지 나옴
    더 나쁘게는 문단 사이 추가 간격이 없고 첫 줄 들여쓰기도 항상 있지 않아서 온갖 어려움이 다 들어 있음

    • MacOS의 CoreGraphics PDF API는 기본적으로 페이지별 텍스트를 딕셔너리에 인코딩된 순서대로 제공했음
      95% 정도는 꽤 괜찮았고, Mac의 PDFKit과 Preview에서는 여러 해 동안 그걸로 충분했음
      PDF를 만든 원래 앱, 예를 들어 워드프로세서를 떠올려보면 자체 텍스트 버퍼에서 PDF 컨텍스트로 꽤 합리적인 순서로 텍스트를 렌더링했을 가능성이 큼
      그래서 2단 문서라도 왼쪽 열에서 오른쪽 열로 텍스트가 올바르게 흐르는 경우가 많았고, PDF 안에서도 이미 올바른 순서로 들어 있었음
      다만 페이지 꼬리말이나 머리말은 PDF 생성 앱이 어떤 순서로 컨텍스트에 덤프했는지 알 수 없음

  • PDF에서 텍스트, 심지어 구조화된 텍스트를 뽑는 건 전혀 쉽지 않음
    HTML 문서에서 표를 긁어오는 건 사이트가 모든 걸 div로 만드는 안티패턴을 써도 종종 단순하고, 의미 있는 요소를 쓰면 더 쉬움
    PDF는 그렇지 않음
    형식 전문가가 아니라서 의미 구조 지원이 얼마나 있는지는 모르지만, 렌더링했을 때만 표로 보이는 그래픽·텍스트 요소들의 느슨한 모음으로 표를 만든 PDF를 많이 봤음
    실제로는 Poppler PDF 유틸리티로 PDF를 HTML로 변환한 뒤, 예상되는 표 헤더를 찾고 각 값의 x좌표로 열을 계산해 행별 값을 추출하는 방식으로 표 데이터 추출에 꽤 성공했음
    지저분한 방식이지만 필요한 용도에는 안정적으로 작동했고, 간격이 들쭉날쭉하거나 행 중간에 줄바꿈이 끼는 서식 있는 일반 텍스트보다 훨씬 나았음

    • 웹페이지와 BeautifulSoup을 쓰듯 PDF에서 데이터를 뽑을 수 없다는 게 답답해서, 비슷한 일을 어느 정도 하는 라이브러리를 만들었음
      여러 잡다한 기능도 있지만 핵심 목표는 page.find('text:bold:contains("Summary").below().extract_text()처럼 더 사람다운 방식으로 상호작용하는 것임
      PDF마다 맞춤형 악몽이라서, 추출이 어려운 예시들을 모아 방법론 라이브러리의 기반으로 삼으려는 중임
      https://jsoma.github.io/natural-pdf/
      https://badpdfs.com/
    • 공식 정부 문서 중에는 렌더링되는 텍스트와 일반적인 방식으로 추출했을 때 나오는 텍스트가 완전히 다른 경우가 제일 마음에 듦
    • 언젠가 내 데이터 정리 소프트웨어에서 PDF의 표 데이터 추출을 할 수 있길 바람
      C++ 앱에 통합 가능하고 무료이거나 몇백 달러 미만인 PDF 표 추출 라이브러리를 아는 사람이 있으면 알려줬으면 함
    • PDF는 본질적으로 마크업/XML 형식이고 표준도 공개돼 배울 수 있음
      같은 PDF를 만드는 방법은 정말 많음
      어떤 도구는 그래픽 편집기에서 텍스트와 그래픽이 포함된 레이아웃을 내보내는 쪽에 가깝고, 다른 도구는 워드프로세서처럼 단어가 먼저인 텍스트와 그래픽을 내보내는 쪽에 가까움
      생성 앱이 정보를 다루는 관점이 PDF 출력 방식에도 자주 영향을 줌
      기성 유틸리티를 찾는다면 cisdem 같은 도구가 로컬 사용자에게 구조화 데이터를 꽤 잘 뽑아주는 수준까지는 해결해둔 편임
      이런 도구는 많고, 구조화 데이터 지원을 약속하는 경우도 많지만, 하려는 작업과 잘 맞아야 함

  • PDF는 표시 형식임
    사람 눈과 프린터에 최적화돼 있고, 기능은 점점 늘어났음
    기계 간 데이터 전송 수단으로는 형편없지만, 사람이 읽거나 A4 한 페이지를 저장하는 데는 아주 좋음
    .pdf가 텍스트를 저장하니 그 텍스트를 원한다는 전제로 시작한다면, 그냥 눈을 키우라는 얘기가 됨
    아니면 아주 복잡한 걸 다뤄야 함
    우선 그 텍스트가 진짜 텍스트인지 이미지인지부터 문제임
    사람 눈은 안경만 다시 쓰면 상관없이 읽지만, 파서는 세그멘테이션 오류를 내며 망가질 수 있음
    PDF는 사람이 읽는 용도이므로, PDF를 읽으려면 사람을 흉내 내야 함

  • 예전에 장난감 PDF 파서를 만들어봤는데, 형식이 어떻게 작동하는지 알고 나서 크게 당황했음
    그런 점을 생각하면 텍스트가 많은 용도에 PDF가 자주 쓰이는 게 더 이상함
    특히 송장 같은 경우를 떠올리게 됨
    디지털 시스템은 파일에서 데이터를 쉽게 추출할 수 있어야 하고, 동시에 사람에게는 보기 좋게 포맷돼야 함
    기술 업계가 더 나은 형식으로 옮겨가면 훨씬 나아질 것 같음

    • XML+XSLT가 거의 그런 해법이었지만, 안타깝게도 브라우저들이 이제 로컬 XML 파일에 대해서는 지원하지 않고 원격 서버의 XML만 지원함
답변달기