PDFSyntax - PDF फ़ाइल की आंतरिक संरचना का HTML विज़ुअलाइज़ेशन

 (github.com/desgeeko)
2 पॉइंट द्वारा GN⁺ 2025-02-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • PDFSyntax एक Python लाइब्रेरी है जो PDF Specification के अध्याय 7 “Syntax” पर केंद्रित है, और PDF फ़ाइल की आंतरिक दस्तावेज़ संरचना को byte स्तर तक जांचने और रूपांतरित करने के लिए उपयोग होती है
  • इसे शुद्ध Python में शुरू से लिखा गया है, यह बिना dependencies वाली हल्की लाइब्रेरी है, और सरलता व immutability को महत्व देती है
  • इसका डिफ़ॉल्ट संपादन तरीका PDF स्पेसिफिकेशन द्वारा अनुमत non-destructive incremental update है, जिसमें मूल फ़ाइल के अंत में बदलाव वाला सेक्शन जोड़ा जाता है, और rollback या single revision में merge करना संभव है
  • CLI overview, disasm, text, fonts, browse आदि प्रदान करता है, और browse PDF source को पढ़ने योग्य रूप में दिखाकर hyperlinks सहित static HTML के जरिए आंतरिक संरचना को explore करने देता है
  • फिलहाल यह beta quality वाला work-in-progress प्रोजेक्ट है, इसलिए API कभी भी बदल सकती है, और MIT लाइसेंस होने के बावजूद अभी external contributions स्वीकार नहीं किए जाते

PDF की आंतरिक संरचना की जांच और रूपांतरण

  • PDFSyntax PDF फ़ाइलों की आंतरिक संरचना की जांच और रूपांतरण के लिए एक Python लाइब्रेरी है
  • यह Portable Document Format (PDF) Specification के अध्याय 7, “Syntax” पर केंद्रित है
  • दस्तावेज़ संरचना प्रबंधन को byte स्तर तक लागू करता है, इसलिए इसे निम्न कार्यों में उपयोग किया जा सकता है
    • metadata access
    • page rotation
    • PDF read/write operations
    • internal objects तक access और manipulation

डिज़ाइन दिशा

  • आंतरिक functions को PDF read/write operations के लिए API toolkit के रूप में expose किया गया है
  • कुछ फीचर्स terminal या browser में उपयोग के लिए CLI के रूप में भी उपलब्ध हैं
  • लाइब्रेरी शुद्ध Python में लिखी गई है और इसकी कोई external dependency नहीं है
  • यह सरलता और immutability को महत्व देती है
  • डिफ़ॉल्ट editing तरीका मूल फ़ाइल को सीधे overwrite किए बिना उसके अंत में बदलाव जोड़ने वाला incremental update है
    • जरूरत पड़ने पर revision को rollback किया जा सकता है
    • सभी revisions को एक में merge भी किया जा सकता है

इंस्टॉलेशन और CLI उपयोग

  • इसे PyPI से install किया जा सकता है
pip install pdfsyntax
  • CLI का मूल उपयोग प्रारूप इस प्रकार है
pdfsyntax COMMAND FILE
  • यदि source से install किया हो, तो इसे लंबे प्रारूप में चलाया जा सकता है
python3 -m pdfsyntax COMMAND FILE
  • तेज़ PDF विश्लेषण के लिए प्रमुख commands निम्न हैं
    • overview: संरचना और metadata की text जानकारी दिखाता है
    • disasm: फ़ाइल संरचना dump को terminal में दिखाता है
    • text: scan जैसी spatial layout बनाए रखते हुए निकाला गया text दिखाता है
    • fonts: उपयोग किए गए fonts की सूची दिखाता है
    • browse: PDF source को पढ़ने योग्य रूप में दिखाता है और hyperlinks के साथ static HTML बनाता है, जिससे आंतरिक संरचना को explore किया जा सके

API उपयोग का तरीका

  • PDFSyntax अधिकांशतः सरल functions से बना है
  • readfile से PDF पढ़ा जा सकता है और metadata से Python dict के रूप में metadata प्राप्त किया जा सकता है
>>> from pdfsyntax import readfile, metadata
>>> doc = readfile("samples/simple_text_string.pdf")
>>> metadata(doc)
  • Doc ऑब्जेक्ट लगभग एकमात्र समर्पित class है जो दस्तावेज़ की आंतरिक स्थिति को संग्रहीत करता है
    • मूल फ़ाइल से cached या memoized content
    • content add/modify/delete changes
    • incremental update के जरिए tracked revision history
  • वही metadata function, Doc ऑब्जेक्ट के method के रूप में भी उपयोग किया जा सकता है
>>> doc.metadata()
  • get_object, update_object जैसे low-level functions से दस्तावेज़ के internal objects तक सीधे access और manipulation किया जा सकता है
  • rotate जैसे high-level functions भी उपलब्ध हैं
>>> from pdfsyntax import rotate, writefile
>>> doc180 = rotate(doc, 180)
  • rotation उदाहरण में मूल ऑब्जेक्ट नहीं बदलता, बल्कि दिशा परिवर्तन को लिए एक नया ऑब्जेक्ट बनता है
  • संशोधित PDF को writefile से disk पर लिखा जा सकता है
>>> writefile(doc180, "rotated_doc.pdf")
  • परिणाम फ़ाइल में मूल content के बाद एक नया section जुड़ता है, और इस section को हटाने पर बदलाव वापस लिया जा सकता है

वर्तमान स्थिति और contribution नीति

  • प्रोजेक्ट work in progress है और beta quality software है
  • API कभी भी बदल सकती है
  • आगे के कार्यों की सूची में निम्न शामिल हैं
    • page cropping और joining
    • lossless compression
    • अधिक filters
    • text extraction में सुधार
    • layout detection के जरिए text extraction को बेहतर बनाना
  • PDFSyntax MIT license के अंतर्गत है
  • फिलहाल external contributions स्वीकार नहीं किए जाते
    • यह एक personal project है और समय सीमित है
    • पहले नए features और refactoring roadmap पर ध्यान दिया जाएगा, फिर स्थिर होने पर contributions स्वीकार किए जाएंगे

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-02-11
Hacker News पर राय

  • काफी समय पहले मुझे कई PDF से डेटा निकालने का काम मिला था, और मैंने एक ऐसा टूल बनाया था जो पेज पर अक्षरों की placement और सभी elements के bounding boxes को visualize करता था
    अंत में प्रोजेक्ट पूरी तरह असफल रहा, और अपेक्षित नतीजे न मिलने से कुछ लोग नाराज़ हुए
    आज होता तो मैं PDF से डेटा निकालने के लिए LLM capabilities का इस्तेमाल करने की दिशा में 100% जाता। उस समय ऐसा विकल्प नहीं था

    • किसी भी arbitrary PDF से डेटा parse करना लगभग एक शापित काम है। PDF में images भी हो सकती हैं, इसलिए यह सीधे JPEG को target करने जैसा ही है
      अपेक्षाओं के हिसाब से OCR से काफी आगे तक जाया जा सकता है, लेकिन मेरे अनुभव में यह हमेशा ठीक उतना कम पड़ जाता है जितनी जरूरत होती है
    • LLM पेज से निकाले गए अक्षरों का क्रम सही करने में मदद कर सकता है, लेकिन वास्तविक content निकालना अब भी कठिन है
      मैंने कई बार ऐसे मामले देखे हैं जहां text के अक्षर ASCII जैसी mapping के बिना custom font glyphs में होते हैं, या खासकर CAD output में आम तौर पर जैसे अक्षरों के आकार lines से draw किए गए होते हैं
      तब extract करने लायक पहचानने योग्य text नहीं होता, इसलिए आखिर में पेज को OCR से फिर जांचना पड़ता है
    • पिछली नौकरी में मुझे कुछ ऐसा ही अनुभव हुआ था; rule-based parsing approach को सही बनाना वाकई मुश्किल है और यह अक्सर edge cases पर fail होती थी
      हम https://runtrellis.com/ पर LLM और visual language models पर आधारित PDF processing pipeline शुरू से बना रहे हैं, और मुश्किल PDF पर भी लगभग 100% accuracy देखी है
      मुख्य बात rule-based engine और reference data को साथ इस्तेमाल करके results को cross-validate करना है
    • बहुत पहले मैंने PDF से 2D CAD drawings निकालकर उन्हें पूरे 3D में बदलने का काम किया था, और वह काफी मजेदार था
    • pdfjs यह सब काम कर देता है और काफी robust है। हाल ही में मैंने 10 साल के bank statements से table data निकालने के लिए इसका इस्तेमाल किया था

  • काफी शानदार है। अगर पिछली नौकरी में यह होता तो शायद मैं इसे बहुत इस्तेमाल करता
    आदर्श रूप से, https://lapo.it/asn1js/ की तरह अगर file drop करने पर सारी processing locally हो जाए तो अच्छा होगा

  • PDF से डेटा extract करने वाले code से निपटने के “विशेषाधिकार” की वजह से, मैं कुछ समय से PDF debugging के लिए iText RUPS का free version इस्तेमाल कर रहा हूं
    यहां की internal inspection capability ज्यादा powerful लगती है, इसलिए यह बहुत अच्छा हो सकता है। इसे चलाकर देखने का सोच रहा हूं

  • मुझे याद है GitHub पर कोई similar project था। दिए गए schema से arbitrary binary data visualize कर सकता था, और शायद TCP/IP example था

    • शायद https://kaitai.io/?
      उस role के लिए यह बहुत अच्छा दिखता था, लेकिन पिछले project में serialization भी चाहिए था, इसलिए इस्तेमाल नहीं किया
    • HexFiend में भी binary data visualization के लिए template syntax है। यह Tcl-based है
      https://github.com/HexFiend/HexFiend/blob/master/templates/T...
    • इस context में “arbitrary” शब्द को लेकर सावधान रहना चाहिए
      दिलचस्प बात यह है कि मैं ऐसे file format descriptors को test करते समय PDF को “Hello World” मानता हूं, क्योंकि PDF specification बेहद अजीब है
      अगर कोई description language PDF के layout को सही-सही represent कर सकती है, तो उसे निश्चित रूप से well-designed माना जा सकता है
      अब तक उन चीजों के अलावा मेरी ज्यादा किस्मत नहीं रही, जो declarative mode से बाहर निकलकर “इसके बाद यह code चलाओ” कर सकती हैं

  • यह forensics और watermark ढूंढने में भी handy होगा

    • दिलचस्प लग रहा है। मुझे ज्यादा जानकारी नहीं है, लेकिन इसे watermark detection के लिए कैसे इस्तेमाल किया जा सकता है? क्या इसी तरीके से signatures भी detect किए जा सकते हैं?

  • अच्छा लग रहा है
    अगर PDF का हर byte दिखे तो और बेहतर होगा। endobj और xref दिखाई नहीं दे रहे लगते हैं

    • सही है, जल्द ठीक करूंगा

  • अगर यह browser library के रूप में आए तो बहुत अच्छा होगा। बस file drag-and-drop करके अंदर की चीजें देख सकें। फिर भी impressive है

    • क्या आपका मतलब browser extension से है? बदतमीजी करने की कोशिश नहीं, बस यह confirm करना चाहता हूं कि मैंने सही समझा है

  • बढ़िया बनाया है। बहुत उपयोगी security preview tool है। PDF सच में headache हैं

  • सोच रहा हूं कि visualization संभालने वाला UI tool कोई library है या नहीं
    UI format मुझे वाकई पसंद आया, और मैं इसे video byte streams को decompose और debug करने के लिए भी इस्तेमाल करना चाहूंगा
    Edit: असल में यह काफी simple है। CSS का अच्छा इस्तेमाल किया है! https://github.com/desgeeko/pdfsyntax/blob/main/docs/simple_...

    • सही है। मैं simplicity को अहम मानता हूं, और basic HTML और CSS से मिलने वाली interactivity मेरे use case के लिए काफी है :)

  • इसी संदर्भ में, PDF अब तक replace क्यों नहीं हुआ? XPS, DjVu, XHTML(EPUB) हैं, लेकिन लगता है वे सब अलग-अलग use cases, जैसे packaged HTML file, को target करते हैं
    मुझे Adobe की भारी-भरकम चीजों के बिना एक simple document format चाहिए, जिसमें दूसरी files और metadata embed किए जा सकें
    पेज के अंदर hyperlinks लगाए जा सकें, font size बदलने पर text overflow न हो, और consistent तरीके से print हो सके

    • मुझे नहीं लगता कि editing, device पर reading, और presentation information के बजाय semantic information extraction के लिए PDF का “unfortunate” format बनना Adobe की गलती या bloat की वजह से है
      PDF कोई data format नहीं, बल्कि page description format है, इसलिए इसके सारे फैसले इस जरूरत से निकले कि अलग-अलग operating systems, software, printers और exact paper sizes होने पर भी वही “page” print किया जा सके
      PDF के लंबे समय तक टिके रहने की मुख्य वजह शायद यह है कि बहुत कुछ document paradigm पर चलता है, यानी “document” को “कागज के कई पन्नों का bundle” मानने का तरीका
      hospital visit के बाद मिलने वाले summary sheet से लेकर car registration documents तक, इनके पास पहले से एक खास visual representation होता है जिसे कागज पर अच्छा और ठीक-ठीक fit दिखने के लिए चुना गया है
      HTML, उदाहरण के लिए images और CSS को data URLs में डालकर standalone बनाया गया format, या ePub ज्यादातर मामलों में बेहतर हो सकते हैं
      लेकिन लक्ष्य इतने अलग हैं कि अगर आप आज PDF बनाने वालों को ऐसा switch करने के लिए मनाने जाएं, तो वे शिकायत करेंगे कि content हर device पर थोड़ा अलग दिखता है और settings के हिसाब से page breaks भी बदल जाते हैं
      इससे जुड़ी एक दिलचस्प बात यह है कि Google Docs में भी default page mode है, “pageless” mode नहीं, जबकि शायद उसके documents आधे से बहुत कम मामलों में print होते या PDF में convert होते होंगे
      “Pageless” mode आम web page की तरह window में fit होता है और एक continuous surface पर अंतहीन scroll करता है, इसलिए ज्यादा उपयोगी है
    • use case अलग है
      “text overflow न हो” जैसी requirement के साथ कई details आती हैं
      PDF में text के हर letter, character, glyph की page पर, कभी-कभी page के बाहर भी, exact x,y position हो सकती है
      इसलिए आसपास क्या है, इसकी परवाह किए बिना content को precisely place किया जा सकता है। PDF इस्तेमाल करने वाली application को items को सही जगह रखना और character या word wrapping implement करना पड़ता है
      XPS, PDF को reimplement करने के सबसे करीब था, लेकिन Microsoft को बाकी parties से पर्याप्त समर्थन नहीं मिला और वह चुपचाप गायब हो गया
    • PDF के बारे में हाल तक मुझे जो दिलचस्प बात नहीं पता थी, वह यह है कि PDF PostScript का subset है, और यही कुछ हद तक इसके भारीपन की वजह है
      PostScript अजीब जरूर है, लेकिन एक complete programming language है; PDF ऐसा नहीं है। यानी यह Turing complete नहीं है
      PDF control flow support नहीं करता, इसलिए PostScript में simple loop से व्यक्त की जा सकने वाली चीज भी PDF में expand करके simple declarations या expressions की series के रूप में store करनी पड़ती है
      फायदा यह है कि PDF render करने के लिए पूरा program interpreter चाहिए नहीं होता
    • ऐसी बातचीत शुरू होते ही LaTeX camp सामने आ जाता है, और standard में meaningful योगदान दे सकने वाले सभी लोग उसी चर्चा में अटक जाते हैं
    • एक वजह यह है कि दूसरे formats में से कोई भी जैसा है वैसा commercial printing के लिए उपयुक्त नहीं है