- PDF फ़ाइलों से text extract करना उम्मीद से कहीं ज़्यादा कठिन है, और PDF मूल रूप से graphics-based file format है
- PDF के भीतर सिर्फ glyph position information होती है और semantic signals लगभग नहीं के बराबर होते हैं, इसलिए text की पहचान और reconstruction मुश्किल हो जाती है
- search engines को HTML के रूप में साफ़ input चाहिए, लेकिन मौजूदा open source tools में title या paragraph जैसी structural information extraction की सीमाएँ हैं
- machine learning आधारित vision approach सबसे सटीक है, लेकिन resource और performance समस्याओं के कारण इसे बड़े पैमाने पर लागू करना कठिन है
- प्रमुख सुधारों में font size और statistics आधारित title·paragraph identification algorithm शामिल हैं, जो extraction accuracy बढ़ाते हैं
PDF से text extraction की चुनौती
- आधुनिक search engines अब PDF file format को index कर सकते हैं
- PDF से information extract करना आसान नहीं है, क्योंकि PDF मूल रूप से text format नहीं बल्कि graphics format है
- इसमें वास्तविक text की जगह coordinates पर रखे गए glyphs होते हैं, इसलिए rotation, overlap, order के बिगड़ने और semantic information की कमी जैसी समस्याएँ होती हैं
- जिसे हम सामान्यतः text के रूप में information मानते हैं, वह फ़ाइल के भीतर सीधे मौजूद नहीं होती
- PDF viewer में
ctrl+f से text search कर पाना वास्तव में काफ़ी आश्चर्यजनक है
search engine की ज़रूरतें और basic approach की सीमाएँ
- search engine सबसे अधिक साफ़ HTML format को पसंद करता है
- आधुनिक machine learning आधारित computer vision models सबसे अच्छा performance दिखाते हैं,
- लेकिन सैकड़ों GB के PDF files को बिना GPU के एक server पर process करना अक्षम है
- अच्छी बात यह है कि यह क्षेत्र पूरी तरह अनजाना नहीं है, इसलिए
- PDFBox की PDFTextStripper class को शुरुआती बिंदु के रूप में इस्तेमाल किया जा सकता है
- लेकिन title जैसी semantic structure की समझ लगभग नहीं होती—सिर्फ strings extract होती हैं
title identification algorithm
title पहचान का मूल सिद्धांत
- आमतौर पर title semi-bold या अधिक मोटे अक्षरों में अलग-थलग दिखते हैं, इसका उपयोग किया जा सकता है
- लेकिन non-bold titles भी काफ़ी आम हैं, इसलिए सिर्फ इस तरीके की सीमाएँ हैं
- कई मामलों में, font size title को अलग करने का आधार बनता है
- लेकिन font size हर document में अलग होता है, इसलिए global threshold का उपयोग संभव नहीं है
font size statistics का उपयोग
- हर page पर आमतौर पर एक dominant font size (body text) होता है
- page 1 (cover) में वर्णनात्मक content और author information होने से font size distribution अलग होता है
- क्योंकि page-दर-page font size distribution बदलता है, इसलिए पूरे document की बजाय page-level statistics अधिक प्रभावी हैं
- हर page के median font size पर लगभग 20% बढ़ोतरी लागू करके title को काफ़ी सटीकता से पहचाना जा सकता है
multi-line title merge की समस्या
- stylistic कारणों से title कई पंक्तियों में भी बँट सकता है
- title merge करने का सही समय तय करना आसान नहीं है; दो या अधिक पंक्तियों वाले title, author names, और अलग emphasized text आपस में मिले हो सकते हैं
- merge rules:
- same font size और weight वाली लगातार पंक्तियों को जोड़ना काफ़ी अच्छा काम करता है
- लेकिन बहुत से अपवाद मौजूद हैं—बिना सोचे-समझे merge करने से गलत परिणाम आ सकते हैं
paragraph identification में सुधार
- PDFTextStripper line spacing और indentation के आधार पर paragraph पहचानता है
- यह line-by-line separation threshold के लिए fixed value का उपयोग करता है, इसलिए अलग-अलग documents की line spacing पर इसकी सीमाएँ हैं
- खासकर paper drafts/preprints में 1.5~2x line spacing भी आम है
- threshold बहुत बड़ा होने पर, title के body text में शामिल हो जाने जैसी गलती होती है
statistics आधारित paragraph separation
- font size की तरह, line spacing पर भी statistical processing लागू की जा सकती है
- पंक्तियों के बीच की दूरी के median का उपयोग करके, किसी भी line spacing में robust paragraph separation संभव है
निष्कर्ष
- PDF से text extract करना मूल रूप से कभी पूरी तरह perfect नहीं हो सकता
- क्योंकि PDF format खुद उस उद्देश्य के लिए डिज़ाइन नहीं किया गया था
- वास्तविक implementation में समझौता अनिवार्य है, और “काफ़ी अच्छा” स्तर का परिणाम पाने की रणनीति महत्वपूर्ण है
- search engine के लिए title, summary, और मुख्य structural clues जैसे meaningful signals निकालने पर ध्यान देना अधिक प्रभावी है
संदर्भ sample text
- 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
1 टिप्पणियां
Hacker News राय
कभी ऐसा अनुभव हुआ है कि ज़िंदगी में कुछ नया और दिलचस्प लग रहा हो, और फिर धुंधली-सी याद आए कि पहले कभी कई महीनों या वर्षों तक इसी चीज़ में विशेषज्ञ रह चुके थे। यहाँ तक कि जो बहुत कमाल की चीज़ें की थीं, वे भी जैसे दिमाग से गायब हो चुकी हों, और फिर से शुरुआत से शुरू करने जैसा महसूस हो। धुंधली-सी याद है कि करीब 6~7 साल पहले PDF और OCR के साथ कुछ ज़बरदस्त किया था। Google पर खोजने पर “tesseract” नाम जाना-पहचाना लगा
2006 के आसपास शुरुआती hackable e-reader iRex पर multi-column वैज्ञानिक papers से text copy न कर पाने की समस्या से चिढ़ हुआ था। उस समय pdf viewer में poppler इस्तेमाल होता था, इसलिए multi-column documents में reading order infer करने के लिए poppler में बदलाव किया। इसके लिए tesseract के लेखक Thomas Breuel के OCR algorithm को देखा। यह एक तरह का heuristic hack था और accessibility API के साथ अच्छी तरह फिट नहीं बैठता था। Multi-column selection फीचर जोड़ दिया गया था, लेकिन maintainers को मनाने में मुश्किल हुई। फिर भी इस तरह kpdf में multi-column selection आ गया। अब लगता है कि ऐसे काम के लिए सीधे tesseract इस्तेमाल करना कहीं ज़्यादा उचित है
PDF नाम के format की वजह से बर्बाद हुए मानवता के दर्जनों साल वापस नहीं लाए जा सकते। यह पागलपन आखिर कब खत्म होगा, सोचता हूँ
Tesseract कुछ समय तक सबसे बेहतरीन open source OCR था। लेकिन आजकल accuracy और GPU acceleration के मामले में docTR बेहतर लगता है। docTR एक pipeline architecture है जिसमें अलग-अलग text detection और recognition models को जोड़ा जा सकता है। PyTorch या TensorFlow में training और tuning भी संभव है, इसलिए किसी खास domain के लिए कहीं बेहतर performance निकाली जा सकती है
ज़िंदगी ऐसी ही है। हर project खत्म करते समय लगता है, “अब मैं इस क्षेत्र का विशेषज्ञ बन गया हूँ। लेकिन शायद यह फिर कभी नहीं करूँगा।” क्योंकि अगली बार फिर किसी बिल्कुल नए विषय को शुरुआत से सीखना होता है
कुछ समय पहले किसी ने C++ के बारे में पूछा तो मैंने कहा था, “मैंने इसमें कभी गंभीरता से काम नहीं किया।” फिर बाद में याद आया कि करीब 20 साल पहले Borland C++ से बने एक private instant messenger का client code मैंने लिखा था, और उसे हज़ारों लोग इस्तेमाल करते थे। ऐसा अक्सर होता है
मैं तुम्हारे दिमाग के बारे में सब नहीं जान सकता, लेकिन शायद सच में वही tesseract था। मेरे साथ भी ऐसा ही अनुभव हुआ है, मेरे मामले में करीब 12 साल पहले
जब HQ लोकप्रिय था, तब मैंने tesseract से एक automatic HQ quiz solver बनाया था। App के question screen का screenshot लेकर एक छोटे API पर भेजते थे, फिर Google में सवाल की पंक्ति खोजकर हर answer कितनी बार आता है, यह गिनकर probability के हिसाब से rank कर देते थे। यह बहुत accurate नहीं था और काफ़ी simple तरीका था, लेकिन इसे बनाना बहुत मज़ेदार था
यह वैसा ही है जैसे हवा में पत्ता उड़ जाए तो fire ant बस दूसरा पत्ता ढूँढ़ ले
यह 7~8 साल पहले की बात है जब मैं 20s में था, इसलिए अब भी सब साफ़ याद है। सोच रहा हूँ कि क्या उम्र का थोड़ा अंतर है। या फिर health checkup भी करा लेना चाहिए
इच्छा है कि browser developer tools (“Inspect Element”) की तरह कोई ऐसा tool हो जिसमें PDF के content stream—जैसे text को घेरने वाले BT…ET, font और coordinates तय करने वाले operators आदि—को source level पर “देख” सकें, और rendering result के साथ साथ-साथ compare/analyze कर सकें। यह उस flow से अलग है जिसमें vision models PDF को “देखकर” text पढ़ते हैं; यहाँ चाहत यह है कि PDF के अंदर वास्तव में कौन-सी जानकारी शामिल है, उसे गहराई से समझा जाए। कुछ tools हैं, लेकिन वे सिर्फ object level तक दिखाते हैं, content stream के अंदर तक नहीं जाते। ऐसा environment चाहिए जहाँ किसी example PDF का असली stream source और rendered result HTML की तरह साथ-साथ देखकर यह समझा जा सके कि कौन-सा हिस्सा कैसे व्यक्त हुआ है
Mozilla के PDF.js से अगर PDF को DOM में render किया जाए तो लगभग वैसा ही अनुभव मिल सकता है। उदाहरण के लिए Tj या TJ जैसे operators क्रमशः <span> या उनके समूहों में बदल जाते हैं। शायद ऐसा इसलिए है क्योंकि original document के प्रति faithful रहना पड़ता है
cpdf tool आज़माने की सलाह दूँगा (इसे मैंने बनाया है)। cpdf के -output-json और -output-json-parse-content-streams options से PDF को JSON में बदलकर तरह-तरह के experiments किए जा सकते हैं। उल्टा JSON से PDF में वापस बदलना भी संभव है। हालाँकि real-time interaction नहीं मिलता
लगता है आप कोई free या open source tool ढूँढ़ रहे हैं, लेकिन पहले Acrobat Pro में लगभग ऐसा फीचर था। बस यह page inspect करने के बजाय content tree traverse करता था, और object/stream तक दिखाता था, individual commands तक नहीं जाता था
“Vision model से PDF को ‘इंसान की तरह देखना’ और ‘PDF में वास्तव में कौन-सा data है, यह जानना’—इन दोनों का मेल हम Tensorlake में बना रहे हैं (मैं वहीं काम करता हूँ)। सिर्फ text पढ़ना नहीं, बल्कि tables, images, equations, handwriting आदि को सच में समझकर Markdown/JSON में data extract करना, ताकि AI, LLM जैसी apps में इस्तेमाल हो सके” https://tensorlake.ai
यह पूरी तरह वैसा नहीं है जैसा आप चाहते हैं, लेकिन PDF के अंदर के अलग-अलग drawing operations को ‘live’ दिखाने वाला inspector देने वाली यह notebook देख सकते हैं https://observablehq.com/@player1537/pdf-utilities
मैंने कई वर्षों तक Apple में इस समस्या पर काम किया। मूल बात यह मान लेना है कि “सब कुछ geometry है”, और word spacing तथा character spacing को cluster analysis से अलग करने वाला algorithm बनाना। ज़्यादातर PDFs में यह काम करता है, लेकिन गहराई से देखें तो प्रकार इतने अलग-अलग हैं कि कुछ निराशाजनक मामले मिलते हैं। अगर आज फिर करता, तो OCR को पूरी तरह हटा देता और geometry-based approach रखकर उसमें machine learning जोड़ता। अगर पहले से ज्ञात text से PDF बनाकर machine learning में इस्तेमाल करें, तो training data बनाना भी automate किया जा सकता है। (WWDC 2009 में Bertrand Serlet की presentation video है)
यह ‘PDF to Text’ नाम की एक ही समस्या नहीं है; वास्तव में इसे 3 categories में बाँटा जा सकता है: (1) reliable OCR (search, vector DB input वगैरह के लिए), (2) structured data extraction (सिर्फ कुछ खास values निकालना), (3) पूरे document pipeline का automation (जैसे mortgage automation)। Marginalia का लक्ष्य (1) है, और आजकल Gemini Flash जैसी चीज़ों की वजह से OCR सस्ता और सामान्य हो गया है। लेकिन (2) और (3) ज़्यादा कठिन हैं, और full automation के लिए अब भी dataset बनाना, pipeline design, uncertainty detection और manual intervention, fine-tuning आदि में काफी मानवीय मेहनत लगती है। भविष्य इसी दिशा में है। (मैं LLM document processing company चलाता हूँ) https://extend.ai
मुझे लगता है कि (4) के रूप में अलग-अलग तरह के documents से reliable OCR और semantic extraction, यानी accessibility के लिए solutions भी चाहिए। यह मुश्किल इसलिए है क्योंकि सामान्य workflow के विपरीत यहाँ user documents का प्रकार पहले से अनुमानित नहीं होता, tables, headers/footers/annotations/equations जैसे text के अलावा और भी elements extract करने पड़ते हैं, errors को न्यूनतम रखना होता है इसलिए ज़रूरत से ज़्यादा OCR नहीं चला सकते, embedded text और rendered content में mismatch हो सकता है (जैसे hidden text या non-standard combinations), यह अक्सर local apps में चलता है इसलिए server का उपयोग मुश्किल है, और imprinter purpose वाले documents के लिए Form support भी चाहिए। ऐसी कई जटिल चुनौतियाँ एक साथ मौजूद हैं। अभी तक ऐसा कोई solution नहीं है जो इन सबको पूरी तरह सुलझाता हो
कहा जाता है कि VLM से OCR pipeline सरल हो गई है, लेकिन यह चेतावनी है कि वास्तव में जटिल documents में यह बेहद कठिन है। Simple image labels के लिए यह शानदार है, और बहुत साधारण documents में काम चल सकता है, लेकिन tables, headers, summaries वाले documents में hallucinate की समस्या बहुत ज़्यादा होती है। इसलिए व्यवहार में यह लगभग अनुपयोगी स्तर पर पहुँच जाता है
Markdown में बदलते समय header detection जैसी कई समस्याएँ देख रहा हूँ। आजकल OCR शानदार है, लेकिन पूरे document structure को बनाए रखना कहीं ज़्यादा कठिन है। LLM को कई बार pass कराकर structure निकालना और page-by-page context देना—इस तरह कुछ ठीक-ठाक परिणाम मिल रहे हैं
बेहतर समाधान यह है कि PDF के अंदर editable source document attach किया जाए। LibreOffice में यह आसानी से किया जा सकता है। आम तौर पर इससे बहुत ज़्यादा space भी नहीं लगता, और text का अर्थ स्पष्ट बना रहता है। मौजूदा PDF readers के साथ भी यह बिना समस्या के काम करता है
जब समस्या मौजूदा PDFs से text extraction की हो, तब PDF बनाने के तरीके पर सलाह वास्तव में कितनी मददगार होगी, इस पर संदेह है। सोचता हूँ कि ऐसे समाधान वास्तव में कब बड़े पैमाने पर असर दिखाएँगे
बात सही है, लेकिन इससे यह जोखिम भी बनता है कि source document और rendered PDF की सामग्री पूरी तरह अलग हो सकती है
बात सही है, लेकिन यह तभी उपयोगी है जब PDF बनाने वाले और PDF इस्तेमाल करने वाले के हित एक जैसे हों। e-Discovery क्षेत्र में अक्सर सामने वाले वकील जानबूझकर सामग्री को इस्तेमाल में कठिन बनाने के लिए उसे PDF में बदलकर जमा करते हैं। नतीजतन संसाधन-संकट वाले public defenders को सामग्री प्रोसेस करने में ज़्यादा समय देना पड़ता है और उन्हें वास्तविक नुकसान होता है। इसे रोकने के लिए मेरा मानना है कि तरह-तरह के data को standard machine-readable formats में अनिवार्य रूप से जमा कराने के लिए कानून होना चाहिए
अगर source document तक पहुँच हो, तो उसे PDF के अंदर attach करना बहुत अच्छा है। लेकिन ज़्यादातर मामलों में हमारे पास ऐसा नियंत्रण नहीं होता
असली समस्या का बड़ा हिस्सा legacy PDFs हैं। हमारी कंपनी में भी ऐसे हज़ारों जमा हैं, और कुछ तो बेहद खराब scans हैं। कुछ में Adobe OCR embedded है, लेकिन ज़्यादातर में वह भी नहीं है
नीचे दिया गया PDF असल में एक .txt file है। extension को .pdf में बदलकर इसे PDF viewer में खोला जा सकता है, और text editor से सीधे edit करके स्क्रीन पर दिखने वाला content, font, font size, line spacing, प्रति पेज characters की संख्या, lines की संख्या, paper size जैसी कई चीज़ें नियंत्रित की जा सकती हैं। (इसमें actual PDF text example शामिल है)
PDF में binary streams भी embed किए जा सकते हैं। PDF text format नहीं, बल्कि layout और graphics के लिए बना format है। उदाहरण की तरह हर line एक साथ आ सकती है, लेकिन वास्तविकता में इसे character-by-character, word-by-word, या यहाँ तक कि बिना किसी क्रम के भी व्यक्त किया जा सकता है
PDF का मतलब “Portable Document Format” है। यह 7-bit ASCII file के रूप में encoded होता है, इसलिए अलग-अलग devices या OS environments में इसकी portability बहुत अच्छी है। (संदर्भ: Adobe official document link)
यह उदाहरण PDF का ‘Hello World’ है। हाल के PDFs में ज़्यादातर objects (obj) deflate से compress किए जाते हैं, और उन objects को streams के अंदर group भी किया जाता है, जिससे यह और जटिल हो जाता है। इसलिए साधारण text में "6 0 Obj" खोजते हुए उसका analysis करना बहुत मुश्किल हो जाता है
PDF से text, खासकर structured text निकालना कभी आसान नहीं रहा। HTML tables को आमतौर पर फिर भी अपेक्षाकृत आसानी से extract किया जा सकता है, लेकिन PDF में table सिर्फ rendered coordinates के आधार पर table जैसी दिखती है; असल में text और graphics बिखरे हुए रहते हैं। मैं भी Poppler PDF utils से PDF को HTML में बदलने के बाद table headers ढूँढ़कर, हर value के x-coordinate के आधार पर columns पहचानकर, row-wise data extract करने का तरीका इस्तेमाल करता हूँ। देखने में भले भद्दा लगे, लेकिन aligned txt से काम करने की तुलना में यह ज़्यादा भरोसेमंद नतीजे देता है
मुझे यह खलता था कि web pages से BeautifulSoup की तरह PDF से data extract नहीं किया जा सकता, इसलिए मैंने उसी तरह का interface वाली library खुद बनाई। ('page.find' शैली का उदाहरण) हर PDF का case इतना अलग-अलग और डरावना होता है कि extraction know-how और अजीब PDFs के examples इकट्ठा करके library बना रहा हूँ https://jsoma.github.io/natural-pdf/ , https://badpdfs.com/
कभी न कभी मैं PDF से table data निकालकर अपने data processing software में डालना चाहता हूँ। अगर किसी को ऐसी library पता हो जो C++ app में integrate हो सके और free हो या बहुत सस्ती हो, तो बताइए
ऐसे documents भी होते हैं (जैसे सरकारी संस्थानों के) जिनमें जो text print होता है और जो वास्तव में extract होता है, दोनों बिल्कुल अलग होते हैं। ऐसे cases अक्सर मिलते हैं
PDF मूलतः एक markup/XML format है। एक ही PDF को बहुत अलग-अलग तरीकों से बनाया जा सकता है। Graphics tools से export करने पर graphics और text मिश्रित PDF बन सकती है, जबकि word processor से export करने पर text-केंद्रित PDF बनती है। बनाने वाला app जानकारी को कैसे संभालता है, इसका PDF output के तरीके पर बहुत असर पड़ता है। Off-the-shelf utilities में cisdem जैसे कई products कुछ हद तक structured data निकालने के लिए काम आ सकते हैं। लेकिन हर task के लिए सही tool अलग होता है
मेरे पसंदीदा examples में से एक यह paper PDF है (link संलग्न)। पहले पेज पर typical 2-column text, बीच में header, दोनों columns के बीच घुसा हुआ text, line length और indentation बदलने वाले elements—सब कुछ मौजूद है। Page headers भी odd/even pages पर अलग हैं, और section headers के नियम भी एक जैसे नहीं हैं। Paragraphs भी हमेशा indented नहीं हैं और line spacing में भी बदलाव है। यह तरह-तरह की समस्याओं का पूरा संग्रह है
जब मैंने खुद एक simple PDF parser बनाया था, तो format की कार्यप्रणाली देखकर मैं हैरान रह गया था। इसलिए मुझे हमेशा यह अजीब लगा कि यह format text-केंद्रित कामों में इतना व्यापक क्यों है। उदाहरण के लिए अगर invoice है, तो digital system के लिए data extraction आसान होना चाहिए, और इंसान के लिए formatted presentation उपयुक्त होनी चाहिए। इसलिए उम्मीद है कि tech industry धीरे-धीरे किसी बेहतर format की ओर migrate करे
PDF से ‘उपयोगी जानकारी’ निकालना ही Tensorlake का काम है (https://tensorlake.ai)। PDF में सिर्फ text नहीं बल्कि tables, images, equations, handwriting, strikethrough जैसी कई तरह की जानकारी होती है, इसलिए developers के रूप में हमें text को सिर्फ “पढ़ना” नहीं बल्कि “समझना” भी आना चाहिए। (मैं कर्मचारी हूँ)