pdfly - PDF फ़ाइलों के लिए Swiss Army knife

 (chezsoi.org)
30 पॉइंट द्वारा GN⁺ 2025-10-14 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • py-pdf टीम द्वारा बनाया गया Python-आधारित open source PDF फ़ाइल मैनिपुलेशन CLI टूल
  • metadata दिखाना, page extract और merge करना, page delete करना, images को PDF में convert करना, document compression, booklet बनाना आदि जैसी विविध PDF editing features प्रदान करता है
  • PDF से images और annotation text extract करना या manual editing के दौरान क्षतिग्रस्त हुए PDF के xref को recover करना जैसी उन्नत सुविधाएँ भी समर्थित हैं
  • हाल ही में जारी 0.5.0 version में PDF document sign और verify करना, annotation वाले pages ही extract करना, specific pages rotate करना जैसी नई सुविधाएँ जोड़ी गई हैं

open source PDF CLI टूल pdfly

  • pdfly, py-pdf organization का नवीनतम project है, जो Python environment में चलने वाला PDF फ़ाइल मैनिपुलेशन के लिए command-line tool है
  • यह fpdf2 और pypdf libraries पर आधारित है, और install व use करना आसान होने से विभिन्न platforms पर उपयोग किया जा सकता है
  • pdfly की सबसे बड़ी ताकत है प्रतिस्पर्धी open source tools की तुलना में व्यापक feature support, और ऐसा intuitive interface जिसे शुरुआती developers भी आसानी से इस्तेमाल कर सकें
  • अन्य projects की तुलना में, एक ही tool से अधिकांश PDF काम आसानी से किए जा सकते हैं, इसलिए इसकी efficiency बहुत अच्छी है

प्रमुख सुविधाएँ

  • metadata दिखाना

    • pdfly meta और pdfly pagemeta commands के माध्यम से PDF metadata display समर्थित है
    • filename, permissions, size, creation/modification/access time जैसे operating system data प्रदान करता है
    • PDF version, page count, encryption status, font information, attachments, image count जैसी PDF internal data दिखाता है

  • document संयोजन और editing

    • pdfly cat: specific pages extract और document merge करने की सुविधा
    • pdfly rm: चुनिंदा page delete सुविधा
    • pdfly x2pdf: images को PDF document में convert करता है
    • pdfly compress: document compression सुविधा
    • pdfly 2-up और pdfly booklet: booklet creation सुविधा

  • content extraction

    • pdfly extract-images: PDF से images extract करता है
    • pdfly extract-annotated-text: annotation वाले text extract करता है

  • PDF recovery

    • pdfly update-offsets: text editor से manually edit किए गए PDF की xref table को ठीक करके उसे फिर से खोला जा सके ऐसा recover करता है
    • xref table, document के भीतर byte offset index होती है, जो manual editing के दौरान क्षतिग्रस्त हो सकती है

0.5.0 version release और नई सुविधाएँ

  • 13 अक्टूबर 2025 को pdfly 0.5.0 version जारी किया गया
  • pdfly sign: PDF document में आसानी से electronic signature जोड़ सकता है
  • pdfly check-sign: PDF document की signature verification सुविधा
  • pdfly extract-annotated-pages: केवल annotation वाले pages को चुनिंदा रूप से extract करके बड़े documents की बार-बार समीक्षा और rework में सहायता
  • pdfly rotate: document के specific pages rotate करने की सुविधा

आगे की योजना

  • GitHub के up-for-grabs issues में विभिन्न feature ideas तैयार हैं
  • नए contributors के लिए good first issues label वाले issues तैयार हैं, जिससे open source में नए लोगों की भागीदारी को प्रोत्साहन मिलता है
  • pdfly sign और check-sign जैसे electronic signature (sign, check-sign) features के विस्तार पर विशेष ध्यान देकर आगे विकास करने की योजना है
  • user feedback, bug reports और feature suggestions का सक्रिय रूप से स्वागत है

https://github.com/py-pdf/pdfly

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

2 टिप्पणियां

 
ifmkl 2025-10-14

Modooui PDF का इस्तेमाल करते हुए, मैंने अपनी सुविधा के लिए सिर्फ कुछ फीचर्स (extract, merge, remove, rotate, reorder) सपोर्ट करने वाला एक PDF टूल बनाकर इस्तेमाल कर रहा हूँ। इसे मैंने ब्राउज़र में pdf.js / pdf-lib.js का उपयोग करके बनाया है। मैंने भी अपना personal tool बनाने से पहले खोजा था, तो देखा कि PDF से जुड़े टूल और साइट्स सच में बहुत ज़्यादा हैं।
 
GN⁺ 2025-10-14
Hacker News राय

  • यह 10 साल पुरानी राय है, लेकिन मुझे लगता है कि आज भी उतनी ही सही है। सिर्फ Python libraries को ही देखें तो PDF से जुड़े फीचर्स को थोड़ा-थोड़ा overlap करते हुए देने वाली बहुत सारी libraries हैं। दूसरी भाषाओं में भी यही स्थिति है। हर library आखिरकार मिलते-जुलते data structures को transform करने वाले कई functions का bundle ही होती है। इसलिए जटिल PDF काम करने के लिए दो-तीन libraries को मिलाकर इस्तेमाल करना पड़ता है, और यह developer के नज़रिए से भी और computing resources के हिसाब से भी inefficient है। अगर कोई Rust में in-memory के लिए अच्छी तरह design किया गया low-level PDF read/write struct बना दे, तो पूरे ecosystem में बहुत सुधार हो सकता है। किसी भी language या PDF library में उस struct का इस्तेमाल किया जा सकता है, और इसे अपनाने पर code कम हो सकता है, speed और safety भी बेहतर हो सकती है। और अगर सिर्फ get_structure_pointer() और set_structure_pointer() दे दिए जाएँ, तो libraries के बीच भी आसानी से interoperability संभव हो जाएगी। ऐसी संरचना में छोटी libraries भी आसानी से features जोड़ सकेंगी और जल्दी adoption पा सकेंगी। व्यावहारिक रूप से कौन यह काम करेगा, पता नहीं, लेकिन मुझे सच में लगता है कि इसकी ज़रूरत है

    • PDF library बनाते समय, उसके use case के अनुसार लगातार design trade-offs मौजूद रहते हैं। "in-memory" खुद में ही एक बड़ा चुनाव है। क्योंकि PDF format को इस तरह design किया गया है कि पूरे PDF को एक साथ memory में लाना ज़रूरी नहीं है। और जो लोग minimal interface वाले deep modules को पसंद करते हैं, उनके लिए shallow लेकिन wide functionality वाले module को जवाब नहीं माना जा सकता। अंत में, JVM जैसे managed environments में C interface से बनी library अतिरिक्त complexity और overhead भी लाती है, यह भी ध्यान रखना चाहिए। संबंधित लिंक

    • "अगर कोई Rust में अच्छी in-memory PDF struct बना दे तो ecosystem बदल जाएगा"—इस बात से मैं सहमत हूँ। लेकिन अभी मौजूद सभी libraries से कहीं बेहतर library बनाना ही आसान नहीं है, और उसे लगातार update करना, bugs ठीक करना और maintain करना उससे भी कठिन है। मान लें कि पर्याप्त funding भी हो, तब भी हर साल ऐसे व्यक्ति को ढूँढना होगा जो उत्साह के साथ यह काम करता रहे, और अगर उसकी रुचि खत्म हो जाए तो नया maintainer भी ढूँढना पड़ेगा, और उस बीच शिकायतें भी झेलनी होंगी। संक्षेप में, जो भी volunteer जीवन भर यह बनाकर maintain करेगा, मैं उसे पहले से ही धन्यवाद कहना चाहता हूँ

    • "Rust में बना शानदार in-memory PDF struct अच्छा होगा" जैसी बात देखकर, मैं वास्तव में मौजूद open source lopdf साझा कर रहा हूँ

    • मैं अभी भी PDF parsing issues debug करते-करते आखिरकार खुद parser लिखने तक पहुँच गया। मैंने मौजूदा parser को समझने की कोशिश की, लेकिन code इतना बेतरतीब था कि अंत में खुद implementation करनी पड़ी। सच कहूँ तो PDF format, समय के साथ हुए विस्तार में तरह-तरह के अस्थायी उपायों और जरूरत से ज्यादा features के जुड़ते जाने से काफी जटिल हो गया है। विचार अपने आप में अच्छा है, लेकिन PDF में बहुत सारे object types और खास properties होने की वजह से, हर binding के साथ आखिरकार FFI की complexity दोहराई जाती है। शायद PDF और JSON के बीच कोई आधिकारिक mapping बना दी जाए, तो memory समस्या न होने पर बड़ी libraries आपस में data exchange कर सकें। आखिर object model पूरी तरह अलग तो नहीं है

    • मज़ाक में कहा गया कि इस पूरी चर्चा को एक XKCD comic में समेटा जा सकता है, और उससे जुड़ा लिंक साझा किया गया

  • Poppler अपनी official homepage पर भले बहुत विस्तार से नहीं दिखता, लेकिन वास्तव में यह कई tools के साथ आने वाली library है और Linux distributions में भी आसानी से उपलब्ध है। मैंने इसके tools कई बार अच्छे से इस्तेमाल किए हैं। संबंधित wiki लिंक

    • इन tools का इस्तेमाल करके मैंने लाखों PDF payslips का analysis किया और data को नए financial system में upload किया। मैं इसे 10 में से 10 दूँगा

    • मैं भी नियमित रूप से poppler tools का इस्तेमाल करता हूँ। मुझे ये सच में बेहतरीन लगते हैं

  • low-level कामों के लिए qpdf काफी उपयोगी है

    • मैं भी यही कहने आया था। Qpdf वह tool है जिसे मैं command line पर PDF files के लिए सबसे ज़्यादा इस्तेमाल करता हूँ। encryption, decryption, page extraction, merge—कई तरह के कामों में काम आता है। यह Apache license के तहत है और C++ में लिखा गया है

  • pdfcpu.io भी है। लेकिन अगर सिर्फ सरल PDF बदलाव चाहिए हों, तो cross-platform open source GUI app ढूँढना बहुत मुश्किल है। सच कहूँ तो मुझे अभी तक नहीं मिला

    • मैंने PDF SAM basic ("split and merge") अच्छे से इस्तेमाल किया है। साइट लिंक यह open source है, multi-platform है, और कुछ अतिरिक्त features paid version में मिलते हैं

    • अगर self-hosting संभव हो, तो Signature PDF भी काफ़ी अच्छा लगा। प्रोजेक्ट लिंक

    • शायद pdf24 tools ठीक हो सकता है। यह offline installation भी support करता है

    • मैंने pdfcpu images list चलाया था, और वह local पर किसी font को बाहर से download करने लगा, तो मैं चौंक गया। अक्टूबर का महीना है, लेकिन यह इतना डरावना लगा कि मैंने छोड़ दिया

    • आखिर काफी सोचने के बाद मैंने Creative Cloud का paid license लेने का फैसला किया। Acrobat बस ठीक से काम करता है, इसलिए मजबूरी है। मैं सच में कोई alternative चाहता हूँ, लेकिन वास्तविकता में कोई खास विकल्प नहीं है

  • मैं PDFgear का परिचय देना चाहूँगा। यह पूरी तरह high-end नहीं है, लेकिन Adobe alternatives में mid-level PDF editing के लिए लगभग अकेला उपयोगी विकल्प है, free है, और Linux को छोड़कर बाकी सब पर उपलब्ध है

    • जब कहा गया कि Linux को छोड़कर सब support है, तो मज़ाक में पूछा गया कि OpenVMS, Apple II, और DEC Alpha binaries कहाँ हैं

    • Master PDF भी है, और इसका Linux version भी है—यह लिंक साझा किया गया

    • देखने में ठीक लगता है, लेकिन "free है, ads नहीं हैं, data नहीं बेचते, और सिर्फ investment funding से transparent तरीके से चलते हैं"—इस तर्क पर भरोसा करना मुश्किल लगता है। उदाहरण के लिए homepage की वह व्याख्या उद्धृत की गई जिसमें कहा गया है कि PDFgear बिना ads या data revenue के, investment funding और technical optimization से चलता है

    • मुझे PDFgear पर थोड़ा शक है। पहले यह users को बताए बिना cloud upload करता था, और कुछ संकेत हैं कि company अपना subreddit भी खुद manage करती है

  • आज मैंने सीखा: PDF files के लिए पहले से ही बहुत सारे multi-tool मौजूद हैं

  • काश ऐसा feature होता जो अपने-आप table of contents (metadata) generate कर दे। पुरानी किताबों के PDF में यह नहीं होता, इसलिए navigation बहुत असुविधाजनक हो जाती है। Kybook3 में भी इसका एक version है, लेकिन वह ठीक से काम नहीं करता। शायद आजकल की LLM technology से यह संभव हो सके

    • मैं pdf.tocgen इस्तेमाल कर रहा हूँ। यह पूरी तरह automatic नहीं है, लेकिन पूरी manual मेहनत की तुलना में बहुत समय बचाता है

  • मुझे जिज्ञासा है कि PDF signing को automate करने वाली utility वास्तव में कितनी सार्थक है। signature का मूल मतलब यह है कि किसी इंसान ने पढ़कर सहमति दी है, तो फिर उसे automate करना क्या सही है?

    • मुझे नहीं लगता कि कंपनियों के पास अपने ही बनाए दस्तावेज़ों पर automatically sign न करने का कोई कारण है। यहाँ signature से मतलब PDF के अंदर दिखने वाला visual signature नहीं, बल्कि cryptographic signature है जिसे कोई भी issuer verify कर सकता है। यानी user यह जाँच सके कि bank statement सच में उसी bank से आया है

    • CEO के पास कर्मचारियों के ढेर सारे contracts पर खुद sign करने का समय नहीं होता। analog दौर में भी secretary मुहर लगाने का काम करती थी, उसी तरह signing automation व्यवहारिक रूप से सार्थक है

    • बैंक ज़रूरत पड़ने पर account certification documents पर अपने-आप sign करके जारी करते हैं। यह उम्मीद नहीं की जाती कि branch manager खुद बैठकर हर request पर अलग-अलग sign करे

    • उदाहरण के लिए, अगर 25 PDFs पर sign करना हो, तो viewer में एक-एक करके manual काम करने की बजाय screen पर review करके batch sign करना ज़्यादा सुविधाजनक है

  • ऊपर बताए गए tools के अलावा, pdfcpu नाम का एक "Go PDF processor and CLI" भी है। pdfcpu GitHub

  • मेरे दिमाग में जो ultimate PDF tool था, वह Didier Stevens का PDF tool set है। प्रोग्राम लिंक