Chuyển PDF sang văn bản là một bài toán khó
(marginalia.nu)- Dù lập chỉ mục PDF đã được bổ sung cho công cụ tìm kiếm, việc lấy ra văn bản có cấu trúc đủ tốt để dùng cho tìm kiếm từ PDF vẫn khó hơn xử lý HTML rất nhiều
- PDF gần với một định dạng đồ họa dựa trên tọa độ hơn là tài liệu văn bản, nên các glyph có thể được đặt trong trạng thái xoay, chồng lấp hoặc đảo lẫn thứ tự
- PDFTextStripper của PDFBox có thể là điểm khởi đầu, nhưng không giữ lại đủ cấu trúc ngữ nghĩa như tiêu đề hay đoạn văn, nên có giới hạn trong việc đánh giá mức độ liên quan của tìm kiếm
- Để phân biệt tiêu đề và đoạn văn, các heuristic như thống kê cỡ chữ theo từng trang và trung vị khoảng cách dòng hữu ích hơn so với việc dựa vào chuẩn của toàn bộ tài liệu
- Vì rất khó trích xuất văn bản PDF một cách hoàn hảo, mục tiêu thực tế cho công cụ tìm kiếm là một giải pháp đủ tốt để lấy ổn định cấu trúc tiêu đề, tóm tắt và nội dung chính
Vấn đề bộc lộ khi bổ sung lập chỉ mục PDF
- Công cụ tìm kiếm gần đây đã có thể lập chỉ mục định dạng tệp PDF, và thay đổi này sẽ được triển khai trong vài tháng tới
- Từ góc nhìn của công cụ tìm kiếm, HTML gọn gàng vẫn là dạng dễ xử lý nhất, còn PDF không cung cấp ngay văn bản có cấu trúc ở cùng mức độ đó
- Dù bề ngoài có vẻ là văn bản, việc khôi phục câu và đoạn có thể tìm kiếm được từ bên trong PDF gần như là một bài toán riêng biệt
Vì sao PDF khó cho việc trích xuất văn bản
- PDF không phải là định dạng văn bản thông thường mà gần với một định dạng đồ họa hơn
- Biểu diễn nội bộ của nó gần với việc đặt các glyph theo tọa độ trên “tờ giấy” hơn là lưu câu hay đoạn văn
- Các glyph có thể ở những trạng thái như sau
- bị xoay
- chồng lên nhau
- xuất hiện khác với thứ tự đọc
- có rất ít thông tin ngữ nghĩa đi kèm
- Việc trình xem PDF hay trình duyệt vẫn hỗ trợ tìm
ctrl+ftự nó đã là một kết quả khá ấn tượng - Các mô hình học máy dựa trên thị giác có thể là hướng tiếp cận tốt ở thời điểm hiện tại, nhưng không phù hợp với quy mô xử lý hàng trăm GB PDF trên một máy chủ đơn không có GPU
Có thể bắt đầu với PDFBox nhưng chưa đủ
- Đây không phải là bài toán hoàn toàn chưa có ai đụng tới, nên có thể lấy lớp PDFTextStripper của PDFBox làm điểm khởi đầu
- PDFTextStripper trích xuất văn bản từ PDF, nhưng đúng như tên gọi, nó tập trung vào việc “lột” văn bản ra khỏi tài liệu
- Với công cụ tìm kiếm, thông tin ngữ nghĩa như tiêu đề là tín hiệu quan trọng cho mức độ liên quan, nhưng chỉ với kết quả trích xuất mặc định thì khó thu được đầy đủ cấu trúc này
Heuristic để tìm tiêu đề
- Cách phát hiện tiêu đề đơn giản nhất là tìm các dòng có độ đậm từ semibold trở lên và tách biệt khỏi phần văn bản khác
- Nhưng không phải tiêu đề nào cũng được in đậm, và nhiều tài liệu phân biệt tiêu đề bằng cỡ chữ
- Mốc cỡ chữ toàn cục dễ dao động theo từng tài liệu
- Có tài liệu dùng thân bài 10pt và tiêu đề 16pt
- Tài liệu khác có thể dùng thân bài 14pt và tiêu đề 20pt
- Thống kê theo từng trang đôi khi phù hợp hơn so với toàn bộ tài liệu
- Trang đầu có thể rất khác các trang còn lại về lựa chọn phông chữ do có phần tóm tắt và danh sách tác giả
- Trong tài liệu ví dụ, tiêu đề tài liệu dùng cỡ chữ 17, còn các tiêu đề phía sau dùng cỡ 14
- Mỗi trang nhìn chung có một cỡ chữ chi phối tương ứng với phần thân bài
- Nếu lấy cỡ chữ trung vị theo trang rồi nhân với hệ số khoảng 20%, có thể nhận diện tiêu đề khá ổn định
- Vẫn còn ngoại lệ, nhưng phần lớn các trường hợp quan trọng có thể được bắt đúng
Gộp tiêu đề nhiều dòng thành một
- Do yếu tố trình bày, tiêu đề thường bị tách thành nhiều dòng, nên đôi khi cần gộp các dòng tiêu đề liên tiếp lại thành một
- Việc quyết định khi nào nên gộp không hề đơn giản
- Trong ví dụ, các điều kiện sau cùng xuất hiện
- tiêu đề hai dòng
- tiêu đề căn phải
- tên tác giả semibold xuất hiện ngay sau tiêu đề
- một tiêu đề không in đậm nằm vài dòng phía dưới
- Thụt đầu dòng cũng được dùng làm tín hiệu phân đoạn văn, nên tiêu đề căn phải càng khiến việc phán đoán khó hơn
- Cách gộp các dòng tiêu đề liên tiếp có cùng cỡ chữ và độ đậm nhìn chung hoạt động khá tốt, nhưng cũng có thể tạo ra kết quả không mong muốn
Cái bẫy do khoảng cách dòng gây ra trong nhận diện đoạn văn
- PDFTextStripper làm nhận diện đoạn văn khá tốt
- Nó xem đồng thời khoảng cách dòng và thụt đầu dòng để quyết định vị trí ngắt đoạn
- Vẫn còn chỗ để cải thiện, đặc biệt là ở logic khoảng cách dòng
- Vấn đề lớn của PDFTextStripper là dùng một mốc cố định cho việc tách dòng
- Nếu khoảng cách giữa các dòng lớn hơn mốc đó, nó sẽ cho rằng chúng không thuộc cùng một đoạn
- Nó chưa phản ánh đủ thực tế rằng mỗi tài liệu có khoảng cách dòng khác nhau
- Trong các bản thảo học thuật và preprint, giãn dòng 1.5 đến 2 lần là chuyện khá phổ biến
- Nếu đặt ngưỡng quá lớn, một số tiêu đề có thể bị nhập vào đoạn thân bài, làm cản trở việc nhận diện tiêu đề
Hiệu chỉnh bằng thống kê khoảng cách dòng
- Tương tự cách xử lý cỡ chữ, có thể áp dụng kỹ thuật thống kê cho khoảng cách giữa các dòng
- Nếu tạo histogram khoảng cách giữa các dòng trên một trang văn bản, thường sẽ xuất hiện những ngoại lệ lớn
- Giá trị trung bình dễ bị ngoại lệ làm lệch, còn trung vị đôi khi lại khớp chính xác với khoảng cách dòng dùng trong thân bài
- Gắn thêm một hệ số nhất định vào trung vị có thể tạo ra heuristic tách đoạn đủ bền vững trước nhiều kiểu giãn dòng khác nhau
Mục tiêu thực tế là độ ổn định hơn là sự hoàn hảo
- Công việc trích xuất văn bản từ PDF rất khó đạt tới mức hoàn hảo
- Bản thân định dạng PDF không được thiết kế cho việc này, và khi chọn một giải pháp “đủ tốt” sẽ xuất hiện nhiều đánh đổi
- Công cụ tìm kiếm đặc biệt quan tâm tới các thông tin sau
- tín hiệu liên quan như tiêu đề
- nhận diện phần tóm tắt
- một mức độ cấu trúc tương đối nhất quán cho phần văn bản còn lại
- Với những mục tiêu như vậy, có thể tiến tới một giải pháp xử lý phần lớn tài liệu liên quan khá ổn mà không quá gượng ép
Văn bản mẫu đã dùng
Can Education be Standardized? Evidence from Kenya (2022) - Working PaperGuthrie Gray-Lobe, Anthony Keats, Michael Kremer, Isaac Mbiti, Owen W. OzierThe 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
1 bình luận
Ý kiến trên Hacker News
Có những lúc trước đây bạn đã đào sâu hàng tháng, hàng năm đến mức đạt trình độ chuyên gia, rồi quên sạch hoàn toàn, để sau này lại cảm thấy “cái này mới mẻ và thú vị đấy”
Dù đã làm khá nhiều việc thú vị, chúng biến mất khỏi ký ức, khiến bạn cảm thấy như một người bắt đầu lại cuộc đời cho đến khi có thứ gì đó khơi gợi lại
Tôi mơ hồ nhớ rằng khoảng 6–7 năm trước mình đã làm một việc khá hay với PDF và OCR, tìm lại thì có vẻ đó là Tesseract
Đó gần như là một bản hack dựa trên heuristic, và tôi nghĩ API cũ của Poppler khi đó không biểu diễn các text run theo cách phù hợp với accessibility API
Tính năng chọn văn bản nhiều cột đã được đưa vào ở một mức nào đó, nhưng các đề xuất cải thiện hiệu năng sau này lại khó thuyết phục maintainer vì heuristic hơi khác làm kết quả chọn văn bản thay đổi trong một số tình huống
Ngay từ đầu vốn đã không có một “đáp án đúng” duy nhất, nên yêu cầu kết quả phải khớp là điều vô lý; và thế là tính năng chọn nhiều cột của kpdf đã hình thành ở một mức nào đó
Ngày nay có lẽ việc dùng trực tiếp Tesseract cho mục đích này sẽ hợp lý hơn
Không biết cơn điên này bao giờ mới kết thúc
Độ chính xác mặc định cao hơn, có tăng tốc GPU, và triển khai pipeline có thể kết hợp nhiều kiến trúc mô hình phát hiện và nhận dạng văn bản
Có thể huấn luyện và fine-tune bằng PyTorch hoặc TensorFlow để đẩy hiệu năng cho các domain cụ thể lên cao hơn nữa
Vì vậy chuyện như thế thực sự có xảy ra
Công việc tiếp theo lại thuộc lĩnh vực hoàn toàn khác, nên lại phải bắt đầu từ nền tảng
Ước gì ai đó làm một thứ giống như công cụ dành cho nhà phát triển của trình duyệt nhưng cho PDF
Kiểu như “Inspect element”, có thể xem content stream của PDF như mã nguồn, rồi kiểm tra các toán tử văn bản
BT … EThoặc toán tử đặt văn bảnTjchỉ định và tạo ra từng pixel như thế nàoĐiều này trái ngược với xu hướng hiện nay, nơi các mô hình thị giác “nhìn” và đọc PDF như con người, nhưng nếu có thể hiểu thực sự bên trong tệp PDF có gì thì sẽ tốt hơn nhiều
Có một vài công cụ để kiểm tra nội dung PDF (https://news.ycombinator.com/item?id=41379101), nhưng chúng dừng ở cấp đối tượng PDF, nên toàn bộ content stream chỉ hiện như một đối tượng duy nhất
Ví dụ, ở trang PDF số 8, trang in số 6 của https://bfi.uchicago.edu/wp-content/uploads/2022/06/BFI_WP_2... được nhắc trong bài, văn bản được đặt bằng các toán tử như
BT, thiết lập phông chữ,Td,TJNếu có thể xem “mã nguồn” này và PDF đã render cạnh nhau, rồi khi rê chuột lên một bên thì vùng tương ứng ở bên kia được tô sáng, có lẽ ta sẽ debug được như với trang HTML
Chẳng hạn mỗi
Tjcó thể trở thành một phần tử DOM, cònTJlà một nhóm gồm nhiều phần tửVì phải phản ánh đúng tài liệu gốc mới hoạt động được, khả năng cao nó sẽ chuyển đổi khá trung thực
Tạo JSON bằng
cpdf -output-json -output-json-parse-content-streams in.pdf -o out.json, chỉnh JSON đó, rồi chuyển ngược lại thành PDF bằngcpdf -j out.json -o out.pdfTuy nhiên không có liên kết hai chiều theo thời gian thực
Tuy nhiên nó không kiểm tra theo kiểu từng trang, mà duyệt cây nội dung, và có tô sáng đối tượng trên trang
Không tới cấp từng lệnh, chỉ đến cấp đối tượng hoặc stream
https://observablehq.com/@player1537/pdf-utilities
Không chỉ “nhìn” PDF như con người và đọc văn bản, mà theo hướng hiểu nội dung, bao gồm bảng, hình ảnh, văn bản, công thức và chữ viết tay
Vì vậy họ parse PDF, chạy nhiều mô hình để trích xuất các mảnh Markdown hoặc JSON, rồi đưa dữ liệu thực vào AI agent, LLM và các ứng dụng khác
https://tensorlake.ai
“PDF sang văn bản” là cách nói bị đơn giản hóa quá mức
Trong phạm trù này có 1) OCR đáng tin cậy để lập chỉ mục tìm kiếm hoặc làm đầu vào cho vector DB, 2) trích xuất dữ liệu có cấu trúc để lấy ra các giá trị cụ thể, 3) các pipeline tài liệu đầu-cuối như tự động hóa đơn xin vay thế chấp
Thứ Marginalia cần giải quyết là OCR ở mục 1, và nhờ các mô hình như Gemini Flash, việc này đang nhanh chóng trở nên phổ dụng
Tôi đã thấy nhiều công ty thay thế pipeline OCR hiện có bằng Flash và giảm chi phí rất nhiều, khá đáng kinh ngạc
Nhưng mục 2 và 3 khó hơn nhiều, và vẫn còn khoảng cách lớn từ đầu ra OCR thô đến pipeline tài liệu mission-critical trong môi trường vận hành
LLM và mô hình thị giác-ngôn ngữ không phải phép màu; nếu kỳ vọng tự động hóa 100% thì bạn sẽ ngạc nhiên
Vẫn cần xây dựng và gán nhãn dataset, điều phối pipeline
phân loại -> phân tách -> trích xuất, phát hiện bất định và kiểm duyệt bởi con người, tinh chỉnh mô hình, v.v.Về dài hạn có thể tiến đến gần như tự động hóa hoàn toàn, nhưng cần thời gian và công sức; có vẻ rõ ràng là tương lai sẽ đi theo hướng này
Liên quan đến việc đó, tôi đã bắt đầu một công ty xử lý tài liệu bằng LLM tên là https://extend.ai
Workflow doanh nghiệp thường chỉ xử lý vài loại tài liệu cố định, nhưng trình đọc PDF đa dụng không thể biết người dùng sẽ mở tài liệu nào
Nó phải nhận diện không chỉ văn bản mà còn bảng, đầu trang/cuối trang, chú thích cuối trang, tiêu đề, công thức toán, v.v.
Vì dành cho con người sử dụng nên phải giảm thiểu lỗi; do đó không nên dùng OCR khi không cần, đồng thời phải tận dụng văn bản gốc nhúng trong PDF mà vẫn trích xuất được cấu trúc ngữ nghĩa
Cuối cùng cần hai hướng xử lý: một cho PDF chỉ có hình ảnh, và một cho PDF có thể lấy thông tin từ content stream
Tuy nhiên content stream có thể chứa văn bản khác với những gì thực sự hiển thị. Ví dụ như thông tin bị ẩn bằng chữ màu trắng, hoặc cách triển khai kiểu LaTeX vẽ dấu trọng âm bằng lệnh thay vì dùng ký tự Unicode có dấu
Thường nó chạy như ứng dụng cục bộ trên thiết bị hiệu năng thấp của người dùng, và nhiều khả năng không có server hay mô hình thuê bao, nên cũng không dùng được mô hình AI trên cloud
Người dùng phần mềm hỗ trợ tiếp cận có thể gặp khó khi in ra rồi điền bằng bút, vì vậy không chỉ cần xử lý các biểu mẫu sạch đúng đặc tả mà cả các biểu mẫu dành để in
Đây vẫn là một bài toán mở còn rất xa mới được giải quyết; các giải pháp hiện tại đều thiếu sót theo cách nào đó, và không có một giải pháp đơn lẻ nào giải quyết tốt cả 5 điểm trên
Chúng làm rất tốt việc gán nhãn ảnh, và ổn với các tài liệu đơn giản như văn bản một cột, tiêu đề một cấp căn giữa, hoặc mỗi trang chỉ có một ảnh hay một bảng
Phần lớn demo MVP đều cho thấy các ví dụ kiểu này
Nhưng với tài liệu phức tạp trộn bảng và ảnh, có lẽ vẫn cần nhiều tham số hơn rất nhiều thì mới đạt đến mức “tệ nhưng dùng được”
Hiện tại hallucination quá nặng, đến mức ngay cả một bảng đơn giản có tiêu đề phía trên, dữ liệu ở giữa và phần tóm tắt bên dưới cũng khó dùng nguyên xi
OCR ngày nay rất xuất sắc, nhưng giữ được cấu trúc toàn cục của tài liệu thì khó hơn nhiều
Việc có HTML nhất quán từ một tài liệu lớn có vẻ vẫn còn xa; còn với Markdown thì có thể đạt kết quả tương đối ổn bằng cách cho qua LLM nhiều lần để trích xuất cấu trúc tài liệu rồi đưa cấu trúc đó làm ngữ cảnh khi trích xuất từng trang
Apple đã xử lý vấn đề này khá thành công trong nhiều năm, và bí quyết cốt lõi là coi mọi thứ như cấu trúc hình học rồi dùng phân tích cụm để cố phân biệt khoảng cách giữa các từ và khoảng cách giữa các chữ cái
Cách này hoạt động rất tốt với nhiều PDF, nhưng vì PDF quá đa dạng nên luôn có những trường hợp kết quả không tốt
Nếu làm lại bây giờ, có lẽ tôi vẫn giữ cấu trúc hình học và tránh hoàn toàn OCR, nhưng sẽ dùng machine learning
Ưu điểm lớn của machine learning là có thể tận dụng các công cụ hiện có để tạo PDF từ văn bản đã biết, qua đó tự động hóa hoàn toàn giai đoạn huấn luyện
Cảnh Bertrand Serlet công bố tính năng này tại WWDC 2009: https://youtu.be/FTfChHwGFf0?si=wNCfI9wZj1aj9rY7&t=308
Giải pháp tốt hơn là nhúng kèm tài liệu gốc có thể chỉnh sửa vào trong PDF
Với LibreOffice thì việc này rất dễ, và vì nén tốt nên thường gần như không tốn thêm dung lượng
Khi đó có thể lấy được thông tin tốt hơn nhiều về văn bản và ngữ nghĩa, đồng thời vẫn hoạt động tốt với các trình đọc PDF hiện có
Trong lĩnh vực e-discovery, bên cung cấp bằng chứng thường cố tình dump thành PDF để luật sư phía đối phương khó tiêu thụ nội dung hơn
Nếu cả hai bên đều nhiều tiền thì đó không phải rào cản, nhưng chẳng hạn luật sư công thường không có ngân sách thuê người xử lý PDF sang định dạng dễ đọc, khiến thời gian xử lý dài hơn nhiều và tạo gánh nặng tâm lý lớn hơn cho bị cáo
Thậm chí có thể họ không xử lý dữ liệu đúng cách được
Giải pháp là biến hành vi này thành bất hợp pháp
Ví dụ, dữ liệu nghe lén phải được cung cấp ở định dạng máy đọc được đã chuẩn hóa, và không có lý do đạo đức nào để ma sát kỹ thuật đơn thuần ảnh hưởng đến kết quả tố tụng hình sự
Tôi tự hỏi sẽ mất bao lâu để giải pháp này phát huy hiệu quả
Công ty chúng tôi cũng có hàng nghìn tệp như vậy; một số là bản scan rất tệ, một số có OCR của Adobe được nhúng, nhưng phần lớn chẳng có gì
Nhưng thông thường bạn không có quyền kiểm soát đó
PDF dưới đây thực ra là một tệp
.txtNếu lưu với phần mở rộng
.pdfthì có thể mở bằng trình xem PDF, và cũng có thể chỉnh sửa bằng trình soạn thảo văn bảnVí dụ, bằng cách chỉnh sửa tệp văn bản này, khi mở PDF có thể thay đổi văn bản hiển thị trên màn hình, phông chữ, cỡ chữ, giãn dòng, số ký tự tối đa mỗi dòng, số dòng mỗi trang, chiều rộng và chiều cao giấy, thậm chí cả hướng dọc/ngang
Ví dụ này là một cấu trúc PDF tối thiểu bắt đầu bằng
%PDF-1.4, trong đóCatalog,Pages,Font,Page,Contents,xref,trailer... được viết trực tiếp dưới dạng văn bảnPDF không được tạo ra cho văn bản, mà cho bố cục và đồ họa
Ví dụ thì hay, nhưng mỗi dòng cũng có thể bị tách thành một lệnh gọi cho mỗi ký tự, một lệnh gọi cho mỗi từ, và thứ tự cũng có thể bị xáo trộn
Trong mục “2.3.2 Portability” của tài liệu tham chiếu PDF 1.0, tệp PDF được mô tả là tệp ASCII 7-bit, và nói rằng ngay cả các tài liệu có hình ảnh và ký tự đặc biệt cũng được mô tả chỉ bằng tập con có thể in được của ASCII
Kết quả là nó được mô tả là có tính di động rất cao trên nhiều môi trường phần cứng và hệ điều hành
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
Ngày nay, phần lớn PDF có tất cả các object được nén bằng deflate
Hơn nữa, để khiến việc lần theo khó hơn, nhiều PDF gom phần lớn object vào trong các object kiểu object stream rồi nén lại lần nữa
Vì vậy, ngay cả khi muốn truy vết phần kết của
6 0 R, bạn cũng không thể tìm6 0 Objtrong trình soạn thảo văn bảnCó một tài liệu tôi thích vì nó cho thấy những khó khăn được mô tả trong bài này: https://academic.oup.com/auk/article/126/4/717/5148354
Ngay từ trang đầu đã có văn bản 2 cột điển hình, tiêu đề căn giữa, và một hộp văn bản chen giữa hai cột làm thay đổi độ dài dòng và thụt lề
Sau đó còn có header thay đổi theo trang chẵn/lẻ, cùng các quy tắc tiêu đề mục thay đổi rất nhiều
Tệ hơn nữa là giữa các đoạn không có khoảng cách bổ sung, và dòng đầu cũng không phải lúc nào cũng thụt lề, nên gần như đủ mọi khó khăn đều có mặt
Khoảng 95% trường hợp khá ổn, và điều đó là đủ trong nhiều năm với PDFKit và Preview trên Mac
Nếu nghĩ đến ứng dụng gốc đã tạo PDF, chẳng hạn một trình xử lý văn bản, thì nhiều khả năng nó đã render văn bản từ buffer văn bản của chính nó sang PDF context theo một thứ tự khá hợp lý
Vì vậy, ngay cả với tài liệu 2 cột, văn bản thường chảy đúng từ cột trái sang cột phải, và ngay trong PDF nó cũng đã nằm đúng thứ tự
Tuy nhiên, với footer hoặc header của trang thì không thể biết ứng dụng tạo PDF đã dump chúng vào context theo thứ tự nào
Trích xuất văn bản từ PDF, thậm chí là văn bản có cấu trúc, hoàn toàn không dễ
Việc cào bảng từ tài liệu HTML thường khá đơn giản, ngay cả khi trang dùng anti-pattern biến mọi thứ thành
div, và còn dễ hơn nếu dùng các phần tử có ngữ nghĩaPDF thì không như vậy
Tôi không phải chuyên gia về định dạng nên không biết mức hỗ trợ cấu trúc ngữ nghĩa đến đâu, nhưng tôi đã thấy nhiều PDF tạo bảng bằng một tập hợp lỏng lẻo các phần tử đồ họa và văn bản chỉ trông như bảng khi render
Trên thực tế, tôi đã khá thành công trong việc trích xuất dữ liệu bảng bằng cách dùng các tiện ích Poppler PDF để chuyển PDF sang HTML, rồi tìm header bảng dự kiến và tính cột dựa trên tọa độ x của từng giá trị để trích xuất giá trị theo từng hàng
Đó là cách làm bẩn, nhưng hoạt động ổn định cho nhu cầu cần thiết, và tốt hơn nhiều so với văn bản thuần có định dạng với khoảng cách lộn xộn hoặc xuống dòng chen giữa hàng
Nó cũng có nhiều tính năng linh tinh, nhưng mục tiêu cốt lõi là tương tác theo cách giống con người hơn, kiểu
page.find('text:bold:contains("Summary").below().extract_text()Mỗi PDF là một cơn ác mộng tùy biến riêng, nên tôi đang thu thập các ví dụ khó trích xuất để làm nền tảng cho một thư viện phương pháp luận
https://jsoma.github.io/natural-pdf/
https://badpdfs.com/
Nếu ai biết thư viện trích xuất bảng PDF miễn phí hoặc dưới vài trăm đô la, có thể tích hợp vào ứng dụng C++, thì mong hãy cho tôi biết
Có rất nhiều cách để tạo ra cùng một PDF
Một số công cụ thiên về xuất bố cục có văn bản và đồ họa từ trình chỉnh sửa đồ họa, còn công cụ khác thì gần với việc xuất văn bản và đồ họa trong đó từ ngữ là trước hết, như trình xử lý văn bản
Cách ứng dụng tạo tài liệu nhìn nhận và xử lý thông tin thường ảnh hưởng đến cách nó xuất PDF
Nếu đang tìm tiện ích có sẵn, các công cụ như cisdem đã giải quyết được đến mức trích xuất dữ liệu có cấu trúc khá tốt cho người dùng cục bộ
Có nhiều công cụ kiểu này, và nhiều công cụ cũng hứa hẹn hỗ trợ dữ liệu có cấu trúc, nhưng phải phù hợp với việc bạn muốn làm
PDF là định dạng hiển thị
Nó được tối ưu cho mắt người và máy in, và các chức năng thì ngày càng được bổ sung nhiều hơn
Là phương tiện truyền dữ liệu giữa máy với máy thì rất tệ, nhưng để con người đọc hoặc lưu một trang A4 thì lại rất tốt
Nếu bắt đầu với giả định rằng
.pdflưu văn bản nên thứ mình muốn là phần văn bản đó, thì chẳng khác nào bảo hãy phóng to mắt ra mà đọcNếu không thì phải xử lý những thứ cực kỳ phức tạp
Trước hết, ngay việc văn bản đó có thật sự là văn bản hay là hình ảnh đã là vấn đề
Mắt người chỉ cần đeo lại kính là vẫn đọc được, nhưng parser có thể hỏng vì lỗi segmentation
Vì PDF được dùng cho con người đọc, nên muốn đọc PDF thì phải bắt chước con người
Trước đây tôi từng thử làm một parser PDF đồ chơi, và sau khi hiểu định dạng này hoạt động ra sao thì khá sốc
Nghĩ đến điều đó thì việc PDF thường được dùng cho các mục đích chứa nhiều văn bản lại càng kỳ lạ
Đặc biệt là những thứ như hóa đơn
Hệ thống số cần có thể dễ dàng trích xuất dữ liệu từ file, đồng thời vẫn phải được định dạng đẹp mắt cho con người xem
Tôi nghĩ nếu ngành công nghệ chuyển sang một định dạng tốt hơn thì sẽ khá hơn nhiều