मेरा PDF मुश्किल से छोटा क्यों हुआ?

मैंने अपना PDF एक कम्प्रेसर से गुज़ारा और वह 4.1 MB से 4.0 MB हो गया। क्या टूल खराब है?

5 मिनट का पठन · 17 अगस्त 2026 को समीक्षित

PDF एक फ़ाइलिंग कैबिनेट है

निराशा की जड़ यही सोच है कि PDF किसी डॉक्यूमेंट की तस्वीर है। वह तस्वीर नहीं है। ISO 32000 में परिभाषित PDF नंबर वाले ऑब्जेक्ट का एक कंटेनर है: पेज ट्री, ड्रॉइंग ऑपरेटर से भरी कंटेंट स्ट्रीम, एम्बेड किए गए फ़ॉन्ट प्रोग्राम, इमेज XObject, फ़ॉर्म फ़ील्ड, एनोटेशन, आउटलाइन, और एक क्रॉस-रेफ़रेंस टेबल जो बताती है कि हर ऑब्जेक्ट कहाँ से शुरू होता है।

इनमें से ज़्यादातर ऑब्जेक्ट पहले से कम्प्रेस्ड होते हैं। कंटेंट स्ट्रीम आम तौर पर Flate से एन्कोड की जाती हैं, यानी वही एल्गोरिदम जो ZIP फ़ाइल इस्तेमाल करती है। एम्बेड की गई तस्वीरें आम तौर पर DCT स्ट्रीम के रूप में रखी जाती हैं, यानी JPEG डेटा ज्यों का त्यों। इसलिए जब कोई सामान्य कम्प्रेसर PDF को देखता है, तो वह ऐसे डिब्बे को देख रहा होता है जिसकी हर चीज़ पहले ही एक बार कम्प्रेस हो चुकी है।

कम्प्रेस करने से पहले पता करें कि बाइट कहाँ हैं

सबसे काम की जाँच यही है कि आपके पास किस तरह का डॉक्यूमेंट है, क्योंकि इसी से नतीजा लगभग पूरा का पूरा पहले ही तय हो जाता है।

स्ट्रक्चरल सेव असल में क्या हटाता है

स्ट्रक्चरल सेव डॉक्यूमेंट को दोबारा लिखता है, बिना यह बदले कि कोई पन्ना कैसा दिखता है। यह उन ऑब्जेक्ट को हटा सकता है जिन्हें अब कोई रेफ़र नहीं करता और जो हर बार डॉक्यूमेंट के एडिट और इंक्रीमेंटल सेव के साथ जमा होते जाते हैं। यह क्रॉस-रेफ़रेंस टेबल को कम्प्रेस कर सकता है और छोटे ऑब्जेक्ट को ऑब्जेक्ट स्ट्रीम में समेट सकता है। यह डॉक्यूमेंट मेटाडेटा, थंबनेल और वह एडिटिंग हिस्ट्री हटा सकता है जो कुछ प्रोड्यूसर पीछे छोड़ जाते हैं।

जिस डॉक्यूमेंट को कई बार एडिट करके दोबारा सेव किया गया हो, उसमें यह बड़ी बचत दे सकता है। लेकिन जो डॉक्यूमेंट वर्ड प्रोसेसर से एक ही बार, साफ़-सुथरा एक्सपोर्ट हुआ हो, उसमें बटोरने को कुछ है ही नहीं: फ़ाइल पहले से अपने सबसे छोटे रूप के करीब है, और चार मेगाबाइट में से सौ किलोबाइट कम होना ठीक वही नतीजा है जिसकी उम्मीद करनी चाहिए।

टेक्स्ट डॉक्यूमेंट क्यों नहीं दबता

टेक्स्ट वाले PDF में फ़ाइल का बड़ा हिस्सा आम तौर पर एम्बेड किए गए फ़ॉन्ट होते हैं। फ़ॉन्ट प्रोग्राम एक सघन बाइनरी होता है जिसमें ग्लिफ़ आउटलाइन और हिंटिंग निर्देश होते हैं, और वह इसलिए वहाँ है क्योंकि डॉक्यूमेंट को उस मशीन पर भी बिल्कुल वैसा ही दिखना है जहाँ वह टाइपफ़ेस इंस्टॉल नहीं है। आप उसे कम्प्रेस करके हटा नहीं सकते — या तो उसे और सबसेट करना होगा या हटाना होगा, और हटाने से पन्ने की शक्ल बदल जाती है।

टेक्स्ट खुद बहुत छोटा होता है। सौ पन्नों का गद्य कम्प्रेशन से पहले भी कुछ सौ किलोबाइट के अक्षर भर है। अगर आपका टेक्स्ट PDF बड़ा है, तो शब्दों की जगह फ़ॉन्ट देखिए और टेक्स्ट के पीछे छिपी इमेज देखिए — हेडर में दोहराया गया लोगो, बैकग्राउंड में लगा वॉटरमार्क।

स्कैन क्यों धड़ाम से सिकुड़ता है

स्कैन किया गया पन्ना कागज़ के एक टुकड़े की एक बड़ी तस्वीर होता है, अक्सर 300 डॉट प्रति इंच या उससे ज़्यादा पर लिया गया। 300 DPI पर A4 पन्ना करीब 2480 × 3508 पिक्सेल का होता है — यानी करीब 90 लाख पिक्सेल, ऐसे पन्ने के लिए जिसकी असल सूचना कुछ किलोबाइट टेक्स्ट भर है। यही वजह है कि स्कैन रास्टराइज़्ड कम्प्रेशन पर इतना नाटकीय असर दिखाते हैं: रेंडर रेज़ॉल्यूशन घटाना और पन्नों की इमेज दोबारा एन्कोड करना फ़ाइल के ठीक उसी हिस्से पर वार करता है जो असल में बड़ा है।

और यही वजह है कि वह मोड विनाशकारी है। एक बार पन्ना तस्वीर बन गया, तो खोजा जा सकने वाली टेक्स्ट लेयर, लिंक, फ़ॉर्म फ़ील्ड, एनोटेशन, एक्सेसिबिलिटी वाला टैग्ड स्ट्रक्चर और कोई भी डिजिटल हस्ताक्षर — सब जा चुके होते हैं। FileSlimmer रास्टराइज़ेशन को स्ट्रक्चरल सेव के निराश करने पर चुपचाप अपनाया जाने वाला विकल्प नहीं मानता, बल्कि उसे इसी चेतावनी के साथ एक अलग और साफ़ लेबल वाले मोड के रूप में रखता है।

कोई आपको कोई नंबर क्यों नहीं दे सकता

PDF के लिए टारगेट साइज़ रेंडर रेज़ॉल्यूशन और इमेज क्वालिटी पर की गई एक खोज है, और इस खोज की एक तली है: किसी रेज़ॉल्यूशन से नीचे स्कैन का टेक्स्ट पढ़ने लायक ही नहीं रहता। उस तली से ऊपर कोई डॉक्यूमेंट किसी तय बजट तक पहुँचेगा या नहीं, यह पन्नों की संख्या, स्याही की मात्रा, फ़ोटो वाली सामग्री और स्कैनर के नॉइज़ पर निर्भर करता है। एक ही पन्ना-संख्या वाले दो डॉक्यूमेंट बहुत अलग साइज़ पर जाकर रुक सकते हैं।

ईमानदार बर्ताव यही है कि तली पर रुका जाए और बताया जाए कि खोज कहाँ रुकी — FileSlimmer के PDF टारगेट प्रीसेट यही करते हैं। जो टूल हमेशा आपके टाइप किए नंबर पर पहुँच जाता है, वह या तो नंबर के बारे में झूठ बोल रहा है या उस तक पहुँचने के लिए डॉक्यूमेंट को बर्बाद कर रहा है।

टूल को दोष देने से पहले

• देखें कि PDF स्कैन तो नहीं है। टेक्स्ट की एक लाइन चुनकर देखें: अगर कर्सर कुछ भी सेलेक्ट नहीं करता, तो हर पन्ना एक इमेज है।
• साइज़ के मुकाबले पन्नों की संख्या देखें। तीन पन्नों वाली 40 MB फ़ाइल इमेज से भरी है; 900 पन्नों वाली 40 MB फ़ाइल पूरी तरह वाजिब हो सकती है।
• देखें कि डॉक्यूमेंट एन्क्रिप्टेड तो नहीं है। पासवर्ड से सुरक्षित PDF को अनलॉक किए बिना उसका ढाँचा बदला ही नहीं जा सकता।
• देखें कि उस पर हस्ताक्षर तो नहीं है। हस्ताक्षरित डॉक्यूमेंट को दोबारा लिखने पर हस्ताक्षर अमान्य हो जाता है, और यह आम तौर पर बड़ी फ़ाइल से भी बुरा नतीजा है।
• देखें कि आपको असल में चाहिए क्या। जो छह पन्ने भेजने हैं उन्हें अलग निकाल लेना अक्सर पूरे नब्बे पन्ने कम्प्रेस करने से बेहतर पड़ता है।

इसके लिए टूल

• PDF संपीड़ित करें
• PDF विभाजित करें
• PDF पृष्ठ निकालें

स्रोत

• ISO 32000-2 — Document management, Portable Document Format
• Adobe — PDF 32000-1:2008, the freely published PDF 1.7 specification
• PDF Association — ISO 32000 and the PDF standards family

और गाइड

सभी FileSlimmer गाइड