PDF को टेक्स्ट में बदलना एक कठिन समस्या है

 (marginalia.nu)
4 पॉइंट द्वारा GN⁺ 2025-05-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सर्च इंजन में PDF indexing जोड़ी गई है, लेकिन PDF से सर्च के काम आने वाला structured text निकालना HTML प्रोसेसिंग की तुलना में कहीं ज़्यादा मुश्किल है
  • PDF, टेक्स्ट डॉक्यूमेंट से ज़्यादा coordinate-based graphics format जैसा है, इसलिए glyphs घुमे हुए, एक-दूसरे पर चढ़े हुए, या उलटे-पुलटे क्रम में रखे हो सकते हैं
  • PDFBox का PDFTextStripper शुरुआत के लिए उपयोगी हो सकता है, लेकिन title और paragraph जैसी semantic structure को पर्याप्त रूप से बचा नहीं पाता, इसलिए search relevance तय करने में सीमाएँ हैं
  • title और paragraph अलग करने के लिए पूरे डॉक्यूमेंट के मानकों की तुलना में per-page font size statistics और line spacing median जैसे heuristics ज़्यादा उपयोगी हैं
  • Perfect PDF text extraction मुश्किल है, इसलिए search engine के लिए title, abstract और body structure को स्थिर रूप से निकालने वाला काफी अच्छा समाधान ही व्यावहारिक लक्ष्य है

PDF indexing जोड़ते समय सामने आई समस्या

  • सर्च इंजन हाल ही में PDF file format को index करने में सक्षम हुआ है, और बदलाव अगले कुछ महीनों में rollout होंगे
  • सर्च इंजन के नज़रिए से साफ-सुथरा HTML सबसे आसान होता है, लेकिन PDF उसी स्तर का structured text सीधे उपलब्ध नहीं कराता
  • बाहर से टेक्स्ट दिखने के बावजूद, PDF के अंदर से searchable sentences और paragraphs को फिर से बनाना लगभग एक अलग समस्या है

PDF में text extraction मुश्किल क्यों है

  • PDF कोई सामान्य text format नहीं, बल्कि graphics format के ज़्यादा करीब है
  • इसकी internal representation sentences या paragraphs से ज़्यादा “कागज़” पर coordinates में glyphs रखने जैसी होती है
  • glyphs इन स्थितियों में हो सकते हैं
    • घुमाए हुए
    • एक-दूसरे पर overlap करते हुए
    • पढ़ने के क्रम से अलग क्रम में दिखते हुए
    • उनसे जुड़ी semantic information बहुत कम होना
  • PDF viewer या browser में ctrl+f search का चल पाना अपने आप में काफी हैरान करने वाला परिणाम है
  • Vision-based machine learning models फिलहाल अच्छा approach हो सकते हैं, लेकिन बिना GPU वाले single server पर सैकड़ों GB PDF प्रोसेस करने के scale के लिए उपयुक्त नहीं हैं

PDFBox से शुरुआत हो सकती है, लेकिन यह पर्याप्त नहीं

  • यह पूरी तरह अनसुलझी समस्या नहीं है, इसलिए PDFBox की PDFTextStripper class को शुरुआत का आधार बनाया जा सकता है
  • PDFTextStripper PDF से टेक्स्ट निकालता है, लेकिन नाम की तरह उसका फोकस टेक्स्ट को strip करने पर है
  • सर्च इंजन के लिए title जैसी semantic information एक महत्वपूर्ण relevance signal है, लेकिन default extraction result से ऐसी structure पर्याप्त रूप से मिलना मुश्किल है

title खोजने के लिए heuristics

  • सबसे सरल title detection तरीका अन्य टेक्स्ट से अलग खड़ी semibold या उससे ज़्यादा मोटी line ढूंढना है
  • लेकिन हर title bold में नहीं होता, और कई documents font size से title अलग करते हैं
  • Global font size baseline हर document में बदल जाता है
    • कोई document body के लिए 10pt और title के लिए 16pt इस्तेमाल कर सकता है
    • दूसरा document body के लिए 14pt और title के लिए 20pt इस्तेमाल कर सकता है
  • पूरे document की तुलना में per-page statistics कई बार ज़्यादा उपयुक्त होते हैं
    • पहला पेज abstract और authors list की वजह से बाकी pages से font selection में काफी अलग हो सकता है
    • उदाहरण document में document title के लिए size 17 font इस्तेमाल होता है, और बाद के titles के लिए size 14 font
  • हर page में आम तौर पर body text से संबंधित dominant font size होता है
  • Per-page median font size पर लगभग 20% का coefficient लगाने से titles की पहचान काफी स्थिर रूप से की जा सकती है
  • Exceptions फिर भी रहते हैं, लेकिन ज्यादातर महत्वपूर्ण cases पकड़े जा सकते हैं

कई lines वाले title को एक में मिलाना

  • Style की वजह से titles अक्सर कई lines में टूट जाते हैं, इसलिए लगातार title lines को कभी-कभी एक में जोड़ना पड़ता है
  • कब जोड़ना है, इसका criterion सरल नहीं है
  • उदाहरण में ये स्थितियाँ साथ-साथ दिखती हैं
    • दो-line title
    • right-aligned title
    • title के बाद आने वाला semibold author name
    • कुछ lines नीचे मौजूद non-bold title
  • Indentation paragraph separation signal के रूप में भी इस्तेमाल होता है, इसलिए right-aligned title निर्णय को और कठिन बना देता है
  • समान font size और weight वाले consecutive titles को जोड़ने का तरीका आम तौर पर अच्छी तरह काम करता है, लेकिन अनचाहे results भी बना सकता है

paragraph पहचान में line spacing के जाल

  • PDFTextStripper paragraph detection काफी अच्छी तरह करता है
  • वह line spacing और indentation को साथ देखकर paragraphs कहाँ अलग करने हैं, यह तय करता है
  • सुधार की गुंजाइश खास तौर पर line spacing logic में है
  • PDFTextStripper की बड़ी समस्या यह है कि वह line separation के लिए fixed baseline इस्तेमाल करता है
    • अगर line spacing baseline से बड़ी हो, तो वह मानता है कि यह वही paragraph नहीं है
    • यह बात पर्याप्त रूप से reflect नहीं करता कि हर document में line spacing अलग होती है
  • Academic drafts और preprints में 1.5~2x line spacing काफी आम है
  • Baseline value बहुत बड़ी रखने पर कुछ titles body paragraphs में absorb हो सकते हैं, जिससे title identification में बाधा आती है

line spacing statistics से सुधारना

  • Font size handling की तरह, lines के बीच की दूरी पर भी statistical techniques लागू की जा सकती हैं
  • Text page में lines के बीच distance का histogram बनाने पर बड़े outliers दिखने की प्रवृत्ति होती है
  • Mean value outliers से आसानी से प्रभावित होती है, लेकिन median कभी-कभी body में इस्तेमाल line spacing से बिल्कुल match करता है
  • Median पर एक निश्चित coefficient लगाने से विभिन्न line spacing में भी टिकने वाला paragraph separation heuristic बनाया जा सकता है

व्यावहारिक लक्ष्य perfection नहीं, stability है

  • PDF से टेक्स्ट extract करने का काम perfect बनाना मुश्किल है
  • PDF format खुद ऐसे काम के लिए design नहीं किया गया, और “काफी अच्छा” समाधान चुनते समय कई trade-offs पैदा होते हैं
  • सर्च इंजन खास तौर पर इन जानकारियों में रुचि रखता है
    • title जैसे relevance signals
    • abstract identification
    • बाकी टेक्स्ट की कुछ हद तक consistent structure
  • ऐसे लक्ष्यों के लिए, ज्यादातर relevant documents को अपेक्षाकृत बिना ज्यादा मुश्किल के संभालने वाले समाधान तक पहुँचा जा सकता है

इस्तेमाल किए गए 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 टिप्पणियां

 
GN⁺ 2025-05-15
Hacker News की रायें

  • कभी-कभी ऐसा होता है कि जिस चीज़ में पहले महीनों, सालों तक गहराई से लगकर expert-level हो गए थे, उसे पूरी तरह भूल जाते हैं, और बाद में वही चीज़ “नई और दिलचस्प” लगती है
    काफी सारी रोचक चीज़ें करने के बाद भी वे याद से गायब हो जाती हैं, और जब तक कोई trigger न मिले, ऐसा लगता है जैसे जिंदगी नए सिरे से शुरू कर रहे हों
    6–7 साल पहले PDF और OCR पर कुछ काफी शानदार काम किया था, इसकी धुंधली-सी याद है, और खोजने पर लगता है कि वह Tesseract था

    • 2006 के आसपास iRex नाम के शुरुआती e-book device पर multi-column scientific papers से text copy नहीं हो रहा था, तो वजह समझने में जुटा; PDF reader internally Poppler इस्तेमाल करता था, इसलिए Tesseract के लेखक Thomas Breuel द्वारा प्रकाशित OCR algorithm का संदर्भ लेकर Poppler को modify किया, ताकि multi-column documents का reading order infer किया जा सके
      यह heuristic जैसा hack था, और उस समय Poppler की पुरानी API शायद text runs को accessibility API के लिए उपयुक्त तरीके से represent नहीं करती थी
      multi-column selection feature कुछ हद तक शामिल हो गया, लेकिन बाद में performance सुधार के प्रस्तावों पर maintainers को मनाना मुश्किल था, क्योंकि heuristics थोड़ी अलग होने से कुछ स्थितियों में selection result बदल जाता था
      शुरुआत से ही कोई एक “सही जवाब” नहीं था, इसलिए results के match होने की मांग करना बेकार था, और इस तरह kpdf का multi-column selection कुछ हद तक बन गया
      आजकल ऐसे use case के लिए सीधे Tesseract इस्तेमाल करना शायद ज्यादा rational होगा
    • इस format की वजह से सामूहिक रूप से जला दिए गए दशकों के human-hours कभी वापस नहीं आएंगे
      यह पागलपन कब खत्म होगा, पता नहीं
    • Tesseract लंबे समय तक सबसे अच्छा open source OCR था, लेकिन अब मुझे लगता है docTR बेहतर है
      इसकी default accuracy ज्यादा है और GPU acceleration मिलता है, साथ ही यह कई text detection और recognition model architectures को composable pipeline के रूप में implement करता है
      PyTorch या TensorFlow से train/fine-tune करके specific domains में performance और भी बढ़ाई जा सकती है
    • एक बार किसी ने C++ के बारे में पूछा तो मैंने जवाब दिया, “मैंने C++ में कभी seriously काम नहीं किया,” फिर याद आया कि लगभग 20 साल पहले मैंने Borland C++ में एक private messenger client का code लिखा था, जिसे हजारों लोग इस्तेमाल करते थे
      इसलिए सचमुच ऐसी चीज़ें होती हैं
    • हर project खत्म करते समय अक्सर लगता है, “अब मैं यह करने में expert हो गया हूं। लेकिन शायद इसे फिर कभी नहीं करूंगा”
      अगला काम बिल्कुल अलग domain का होता है, इसलिए फिर basics से शुरू करना पड़ता है

  • काश कोई PDF के लिए browser developer tools जैसा कुछ बना दे
    “Inspect element” की तरह PDF की content stream को source के रूप में देखकर यह पुष्टि कर सकें कि BT … ET text operators या Tj text placement operator हर pixel को कैसे specify/generate करते हैं
    यह आजकल के उस trend के उलट है जहां visual models PDF को इंसान की तरह “देखकर” पढ़ते हैं, लेकिन अगर सच में PDF file के अंदर क्या है यह समझ सकें, तो कहीं बेहतर होगा
    PDF content inspect करने के कुछ tools हैं (https://news.ycombinator.com/item?id=41379101), लेकिन वे PDF object level पर रुक जाते हैं, इसलिए पूरी content stream बस एक object के रूप में दिखती है
    उदाहरण के लिए लेख में बताए गए https://bfi.uchicago.edu/wp-content/uploads/2022/06/BFI_WP_2... की 6-page PDF के page 8 पर text को BT, font settings, Td, TJ जैसे operators से place किया गया है
    अगर ऐसे “source” और rendered PDF को side-by-side देखा जा सके, और एक तरफ mouse hover करने पर दूसरी तरफ corresponding area highlight हो, तो HTML page की तरह debug किया जा सकेगा

    • Mozilla के PDF.js से PDF को DOM में render करें तो काफी करीब का result मिल सकता है
      उदाहरण के लिए हर Tj एक DOM element बने, और TJ कई elements का group बने—कुछ ऐसा लगता है
      original document को सही से reflect करना होगा, तभी यह काम करेगा, इसलिए काफी faithful conversion होने की संभावना है
    • cpdf से कुछ हद तक यह संभव है
      cpdf -output-json -output-json-parse-content-streams in.pdf -o out.json से JSON बनाया जा सकता है, फिर उस JSON को modify करके cpdf -j out.json -o out.pdf से वापस PDF में बदला जा सकता है
      हालांकि real-time two-way linking नहीं है
    • शायद बात open source या free की हो रही होगी, लेकिन कुछ साल पहले इस्तेमाल किए गए Acrobat Pro में भी लगभग ऐसी ही functionality थी
      हालांकि यह page inspect करने जैसा नहीं था, बल्कि content tree browse करने जैसा था, और page पर objects को highlight कर देता था
      command level तक नहीं, केवल object या stream level तक संभव था
    • यह notebook ठीक वही नहीं है जो चाहिए, लेकिन PDF के अंदर कई drawing operations को “real-time” में inspect करने की सुविधा देता है
      https://observablehq.com/@player1537/pdf-utilities
    • Tensorlake जो बना रहा है, वह भी इस combination के करीब है
      PDF को इंसान की तरह “देखकर” सिर्फ text पढ़ना नहीं, बल्कि tables, images, text, equations, handwriting तक सहित content को समझने की दिशा है
      इसलिए यह PDF parse करता है और कई models चलाकर Markdown snippets या JSON extract करता है, ताकि actual data को AI agents, LLMs और दूसरी applications में डाला जा सके
      https://tensorlake.ai

  • “PDF से text में” कहना बहुत ज़्यादा सरलीकृत अभिव्यक्ति है
    इस श्रेणी के अंदर 1) search index या vector DB input के लिए भरोसेमंद OCR, 2) किसी खास value को निकालने वाला structured data extraction, 3) mortgage application automation जैसी end-to-end document pipelines आती हैं
    Marginalia को जिस समस्या को हल करना है, वह नंबर 1 OCR है, और Gemini Flash जैसे models की वजह से यह तेज़ी से general-purpose बन रहा है
    मैंने कई कंपनियों को मौजूदा OCR pipelines को Flash से replace करके लागत बहुत कम करते देखा है, और यह काफ़ी हैरान करने वाला है
    लेकिन नंबर 2 और 3 कहीं ज़्यादा कठिन हैं, और raw OCR output से production environment की mission-critical document pipeline तक जाने में अभी भी बड़ा gap है
    LLM और visual language models कोई जादू नहीं हैं, और अगर आप 100% automation की उम्मीद करेंगे तो चौंक जाएंगे
    dataset बनाना·labeling, classification -> segmentation -> extraction pipeline orchestration, uncertainty detection और human review, fine-tuning आदि अब भी ज़रूरी हैं
    लंबे समय में हम लगभग पूरी तरह automation के करीब पहुंच सकते हैं, लेकिन इसमें समय और मेहनत लगेगी, और भविष्य इसी दिशा में जाता दिखता है
    इसी से जुड़ा https://extend.ai नाम का LLM document processing company शुरू किया है

    • accessibility के नज़रिए से नंबर 4, यानी अलग-अलग document types में काम करने वाला भरोसेमंद OCR और semantic extraction भी चाहिए
      business workflows अक्सर कुछ तय documents ही संभालते हैं, लेकिन general-purpose PDF reader को पता नहीं होता कि user कौन-सा document खोलेगा
      सिर्फ text नहीं, बल्कि tables, headers·footers, footnotes, titles, mathematical formulas आदि भी पहचानने होंगे
      क्योंकि यह human consumption के लिए है, errors को minimum रखना होगा; इसलिए जब ज़रूरत न हो तो OCR इस्तेमाल नहीं करना चाहिए, और PDF में मौजूद मूल text का उपयोग करते हुए भी semantic structure निकालना होगा
      अंततः image-only PDF और ऐसे PDF जिनके content stream से जानकारी मिल सकती है, इनके लिए दो रास्ते चाहिए
      लेकिन content stream में actual screen से अलग text हो सकता है। जैसे सफेद अक्षरों में छिपाई गई जानकारी, या LaTeX-स्टाइल implementation जिसमें Unicode accent के बजाय command से accent symbol draw किया जाता है
      यह आम तौर पर user के low-performance device पर local app के रूप में चलता है, और server या subscription model न होने की संभावना ज़्यादा है, इसलिए cloud AI models भी इस्तेमाल नहीं किए जा सकते
      accessibility software users के लिए print करके pen से भरना मुश्किल हो सकता है, इसलिए spec के हिसाब से साफ-सुथरे forms के साथ-साथ print के लिए बने forms भी handle करने होंगे
      यह अभी भी ऐसा open problem है जिसके समाधान के हम बिल्कुल करीब नहीं हैं, और मौजूदा solutions किसी न किसी तरह कमज़ोर हैं; ऊपर की 5 चीज़ों को ठीक से हल करने वाला कोई single solution नहीं है
    • visual language models इतने unstable थे कि मुझे खुद tools बनाने पड़े; उस अनुभव से, जो company unprocessed images पर VLM इस्तेमाल करती है, उसे बहुत दर्द झेलना पड़ सकता है
      image labeling वे बहुत अच्छी तरह करते हैं, और single-column text·center-aligned single-step title·हर page पर एक image या table जैसे simple documents के लिए ठीक हैं
      अधिकांश MVP demos इसी तरह के examples दिखाते हैं
      लेकिन tables और images मिले-जुले complex documents में “खराब स्तर” तक पहुंचने के लिए भी शायद अभी कहीं ज़्यादा parameters चाहिए
      फिलहाल hallucination इतनी ज़्यादा है कि ऊपर title, बीच में data और नीचे summary वाली simple table तक को सीधे इस्तेमाल करना मुश्किल है
    • PDF को Markdown में process करने के लिए लगातार tweaking कर रहा हूं, और original post की तरह header detection और कई समस्याओं से टकरा रहा हूं
      आजकल OCR शानदार है, लेकिन document की global structure बनाए रखना कहीं ज़्यादा tricky है
      बड़े documents से consistent HTML पाना अभी दूर लगता है, और LLM को कई बार pass कराकर document structure extract करने और फिर उसे page-by-page extraction में context के रूप में डालने के तरीके से Markdown में कुछ हद तक अच्छे results मिलते हैं

  • Apple में कई सालों तक इस समस्या को काफ़ी सफलतापूर्वक handle किया गया था, और core secret यह था कि सब कुछ geometry के रूप में लिया जाए और cluster analysis से word spacing और character spacing को अलग करने की कोशिश की जाए
    कई PDFs में यह बहुत अच्छे से काम करता है, लेकिन PDF types इतने विविध हैं कि results खराब आने वाले cases हमेशा होते हैं
    अगर आज फिर से करना हो तो geometry को बनाए रखते हुए OCR से पूरी तरह बचूंगा, लेकिन machine learning इस्तेमाल करूंगा
    machine learning का बड़ा फायदा यह है कि known text से PDF generate करने वाले मौजूदा tools का उपयोग करके training phase को पूरी तरह automate किया जा सकता है
    WWDC 2009 में Bertrand Serlet द्वारा इस feature को announce करने का दृश्य: https://youtu.be/FTfChHwGFf0?si=wNCfI9wZj1aj9rY7&t=308

  • बेहतर समाधान यह है कि PDF के अंदर editable original document को साथ में embed किया जाए
    LibreOffice में यह आसानी से संभव है, और compression अच्छा होता है इसलिए आम तौर पर space भी लगभग नहीं लगता
    इससे text और semantics के बारे में कहीं बेहतर जानकारी मिल सकती है, और यह मौजूदा PDF readers में भी ठीक से काम करता है

    • बात सही है, लेकिन PDF creator और consumer के हितों का मेल होना चाहिए
      e-discovery क्षेत्र में evidence देने वाला पक्ष अक्सर जानबूझकर PDF में dump करता है ताकि opposing counsel के लिए content consume करना मुश्किल हो जाए
      अगर दोनों पक्षों के पास बहुत पैसा हो तो यह barrier नहीं है, लेकिन उदाहरण के लिए public defender के पास PDF को readable format में process करने के लिए किसी को hire करने का पैसा नहीं होता, जिससे processing time बहुत बढ़ जाता है और defendant पर psychological burden बढ़ता है
      यहां तक कि data को ठीक से process भी नहीं किया जा सकता
      समाधान यह है कि ऐसे व्यवहार को illegal बनाया जाए
      उदाहरण के लिए wiretap data को standardized machine-readable format में दिया जाना चाहिए, और महज technical friction का criminal procedure के परिणामों को प्रभावित करना नैतिक रूप से उचित नहीं है
    • मौजूदा PDF से text extract करने वाले search engine problem का बेहतर समाधान PDF बनाने के तरीके पर सलाह होना अजीब है
      सवाल है कि इस समाधान को असर दिखाने में कितना समय लगेगा
    • सही है, लेकिन इससे यह vulnerability भी बनती है कि original document rendered PDF content से मनमाने ढंग से अलग हो सकता है
    • problem space का 90% शायद legacy PDFs होंगे
      हमारी company में भी ऐसे हजारों files हैं, कुछ बहुत खराब scans हैं, कुछ में Adobe OCR embedded है, लेकिन अधिकांश में कुछ भी नहीं है
    • अगर PDF बनाने वाले original document तक access हो तो यह अच्छा तरीका है
      लेकिन आम तौर पर आपके पास ऐसा control नहीं होता

  • नीचे दिया गया PDF असल में एक .txt फ़ाइल है
    अगर इसे .pdf extension के साथ save करें, तो यह PDF viewer में खुल सकता है और text editor से edit भी किया जा सकता है
    उदाहरण के लिए, इस text file को edit करके PDF खोलने पर screen पर दिखने वाला text, font, font size, line spacing, प्रति line अधिकतम characters की संख्या, प्रति page lines की संख्या, paper की width और height, यहाँ तक कि portrait/landscape orientation भी बदला जा सकता है
    यह उदाहरण %PDF-1.4 से शुरू होने वाले minimal PDF structure का है, जिसमें Catalog, Pages, Font, Page, Contents, xref, trailer आदि को सीधे text के रूप में लिखा गया है

    • PDF में embedded binary streams भी हो सकते हैं
      PDF text के लिए नहीं, बल्कि layout और graphics के लिए बनाया गया था
      उदाहरण अच्छा है, लेकिन हर line को एक character पर एक call, या एक word पर एक call में तोड़ा जा सकता है, और order भी गड़बड़ा सकता है
    • “PDF” का मतलब “Portable Document Format” है
      PDF 1.0 reference document के “2.3.2 Portability” में PDF file को 7-bit ASCII file के रूप में बताया गया है, और कहा गया है कि images और special characters वाले documents को भी ASCII के printable subset का ही उपयोग करके describe किया जाता है
      इसके परिणामस्वरूप यह अलग-अलग hardware और operating system environments में बहुत portable बताया गया है
      https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
    • यह PDF के Hello World के काफी करीब है
      आजकल के ज़्यादातर PDF में सभी objects deflate से compressed होते हैं
      ऊपर से, उन्हें follow करना और मुश्किल बनाने के लिए कई PDF ज़्यादातर objects को object stream type object के अंदर bundle करके फिर से compress कर देते हैं
      इसलिए अगर आप 6 0 R का अंत trace करना चाहें, तब भी text editor में 6 0 Obj search नहीं कर सकते

  • इस लेख में बताई गई कठिनाइयों को दिखाने वाला मेरा पसंदीदा document है: https://academic.oup.com/auk/article/126/4/717/5148354
    पहले page से ही typical two-column text, centered title, और दोनों columns के बीच फंसा एक text box है, जो line length और indentation बदल देता है
    आगे odd/even pages के हिसाब से बदलने वाले headers और काफ़ी अलग section header rules भी आते हैं
    और भी खराब बात यह है कि paragraphs के बीच extra spacing नहीं है और first-line indentation भी हमेशा नहीं है, इसलिए इसमें हर तरह की मुश्किलें मौजूद हैं

    • MacOS की CoreGraphics PDF API default रूप से page-wise text को dictionary में encoded order के अनुसार देती थी
      लगभग 95% मामलों में यह काफी ठीक था, और Mac के PDFKit और Preview में कई सालों तक यही पर्याप्त रहा
      PDF बनाने वाले original app, जैसे word processor, के बारे में सोचें तो संभावना है कि उसने अपने text buffer से PDF context में text को काफी reasonable order में render किया होगा
      इसलिए two-column document में भी अक्सर text left column से right column तक सही ढंग से flow करता था, और PDF के अंदर भी वह पहले से सही order में मौजूद होता था
      हालांकि page footer या header के मामले में यह नहीं पता कि PDF generation app ने उन्हें context में किस order में dump किया

  • PDF से text, यहाँ तक कि structured text निकालना बिल्कुल आसान नहीं है
    HTML document से tables scrape करना अक्सर सरल होता है, भले ही site हर चीज़ को div बनाने वाला anti-pattern इस्तेमाल करे; meaningful elements इस्तेमाल हों तो यह और आसान हो जाता है
    PDF में ऐसा नहीं है
    मैं format expert नहीं हूँ, इसलिए नहीं जानता कि semantic structure support कितना है, लेकिन मैंने कई PDF देखे हैं जिनमें table असल में graphics और text elements का एक ढीला-ढाला collection होता है, जो सिर्फ render होने पर table जैसा दिखता है
    व्यवहार में, Poppler PDF utilities से PDF को HTML में convert करके, expected table headers खोजने और हर value के x-coordinate से columns calculate करके row-wise values extract करने की method से table data extraction में मुझे काफी सफलता मिली
    यह messy तरीका है, लेकिन जिस काम के लिए चाहिए था उसमें reliably काम करता था, और inconsistent spacing या row के बीच line breaks घुसे हुए formatted plain text से कहीं बेहतर था

    • Webpage और BeautifulSoup की तरह PDF से data extract नहीं कर पाने की झुंझलाहट में मैंने एक library बनाई, जो कुछ हद तक वैसा ही काम करती है
      उसमें कई miscellaneous features भी हैं, लेकिन core goal page.find('text:bold:contains("Summary").below().extract_text() जैसे ज़्यादा इंसानों जैसे तरीके से interact करना है
      हर PDF अपनी custom nightmare है, इसलिए मैं extraction के कठिन examples इकट्ठा करके उन्हें methodology library की बुनियाद बनाने की कोशिश कर रहा हूँ
      https://jsoma.github.io/natural-pdf/
      https://badpdfs.com/
    • Official government documents में मुझे वे मामले सबसे पसंद हैं जहाँ rendered text और सामान्य तरीके से extract करने पर मिलने वाला text बिल्कुल अलग होता है
    • उम्मीद है कि किसी दिन मेरे data cleaning software में PDF से table data extraction हो सकेगा
      अगर किसी को ऐसी PDF table extraction library पता हो जो C++ app में integrate हो सके और free हो या कुछ सौ dollars से कम की हो, तो बताएं
    • PDF मूल रूप से markup/XML format है और इसका standard भी public है, इसलिए इसे सीखा जा सकता है
      एक ही PDF बनाने के सचमुच बहुत सारे तरीके हैं
      कुछ tools graphics editor से text और graphics वाला layout export करने जैसे होते हैं, जबकि दूसरे tools word processor की तरह words-first text और graphics export करने के ज्यादा करीब होते हैं
      generating app जिस नजरिए से information को handle करता है, वह अक्सर PDF output के तरीके को भी प्रभावित करता है
      अगर आप off-the-shelf utility खोज रहे हैं, तो cisdem जैसे tools local user के लिए structured data काफी अच्छी तरह extract करने के स्तर तक यह समस्या हल कर चुके हैं
      ऐसे tools बहुत हैं, और कई structured data support का वादा भी करते हैं, लेकिन उन्हें आपके काम के साथ अच्छी तरह fit होना चाहिए

  • PDF एक display format है
    यह इंसानी आंखों और printers के लिए optimize किया गया है, और इसके features लगातार बढ़ते गए हैं
    मशीनों के बीच data transfer के साधन के रूप में यह बहुत खराब है, लेकिन इंसानों के पढ़ने या A4 के एक पेज को save करने के लिए बहुत अच्छा है
    अगर आप इस premise से शुरू करते हैं कि .pdf text store करता है, इसलिए आपको वही text चाहिए, तो बात बस इतनी है कि अपनी आंखें बड़ा लीजिए
    वरना आपको बेहद जटिल चीज़ से निपटना पड़ेगा
    सबसे पहले तो यही सवाल है कि वह text सचमुच text है या image
    इंसानी आंखें चश्मा फिर से लगा लें तो किसी भी तरह पढ़ लेती हैं, लेकिन parser segmentation errors देकर टूट सकता है
    PDF इंसानों के पढ़ने के लिए है, इसलिए PDF पढ़ने के लिए इंसान की नकल करनी पड़ती है

  • पहले मैंने एक toy PDF parser बनाया था, और यह जानने के बाद कि format कैसे काम करता है, मैं काफी हैरान रह गया
    यह देखते हुए, text-heavy कामों में PDF का अक्सर इस्तेमाल होना और भी अजीब लगता है
    खासकर invoices जैसे मामलों की याद आती है
    digital systems को file से data आसानी से extract कर पाना चाहिए, और साथ ही उसे इंसानों के लिए अच्छे format में दिखना भी चाहिए
    अगर tech industry किसी बेहतर format पर चली जाए तो बहुत सुधार हो सकता है

    • XML+XSLT लगभग ऐसा ही solution था, लेकिन अफसोस कि browsers अब local XML files के लिए support नहीं करते और सिर्फ remote server की XML support करते हैं