PDF संपीड़ित करने पर वाकई क्या होता है
PDF123 Compress qpdf से स्ट्रीम पुनःसंपीड़न और ऑब्जेक्ट-स्ट्रीम पैकिंग करता है, पर इमेज डाउनसैंपल नहीं करता, बिटमैप को कम JPEG गुणवत्ता में पुनः-एन्कोड नहीं करता और फ़ॉन्ट सबसेट नहीं करता। लीनियराइज़ेशन से फ़ाइल का आकार लगभग नहीं बदलता।

दो PDF स्क्रीन पर एक जैसी दिख सकती हैं, फिर भी उनके आकार में तीन कोटि का फ़र्क़ हो सकता है: 50 KB बनाम 50 MB। यह फ़र्क़ लगभग कभी टेक्स्ट ऑपरेटरों से नहीं आता। बीस पेज के एक कॉन्ट्रैक्ट में ये ऑपरेटर आम तौर पर कुछ दसियों किलोबाइट के होते हैं; बाकी सब इमेज सैंपल, पूरा एम्बेड किया गया फ़ॉन्ट प्रोग्राम, और स्ट्रीम तथा ऑब्जेक्ट कितने कसकर पैक हैं, इनसे बनता है।
इसका एक नतीजा है जो शुरू में ही कह देना चाहिए: "PDF संपीड़ित करना" एक काम नहीं, चार अलग-अलग काम हैं। वे अलग-अलग चीज़ें छोटी करते हैं और उनकी कीमत अलग होती है; चारों को एक मान लेने पर अनुभव परस्पर विरोधी बन जाता है: फ़ाइल संपीड़ित हुई पर छोटी नहीं हुई, या छोटी हुई पर पेजों की धार खत्म हो गई।
आकार असल में कहाँ से आता है
"यह PDF इतना बड़ा क्यों है?" के ज़्यादातर मामले किसी हाई-रिज़ॉल्यूशन स्कैन या फ़ोटो से शुरू होते हैं जो अब भी कैप्चर आकार में एम्बेड है। एक बार यह गणित कर लेना उपयोगी है: Letter पेज, 8.5 × 11 इंच, 300 DPI पर लगभग 2550 × 3300 पिक्सल बनता है, और तीन बाइट प्रति पिक्सल के हिसाब से वह बिना संपीड़न के करीब 25 MB होता है। ऐसे बीस पेज अक्सर 60 से 80 MB तक पहुँच जाते हैं, इससे पहले कि कोई संपीड़न छुए।
दूसरा स्रोत फ़ॉन्ट हैं। कोई PDF पूरा फ़ॉन्ट प्रोग्राम एम्बेड कर सकता है ताकि हर मशीन पाठ को एक ही तरह दिखाए, और इसकी कीमत ग्लिफ़ टेबल के आकार से तय होती है, इससे नहीं कि पाठ कितना पढ़ा गया। इसीलिए फ़ॉन्ट सबसेटिंग एक अलग आकार-लीवर है।
तीसरा स्रोत पैकिंग ख़ुद है। एक ही सामग्री फ़िज़ूल संपीड़न सेटिंग्स के साथ रखी जा सकती है, या उसके ऑब्जेक्ट फ़ाइल में बिखरे पड़े रह सकते हैं, हर एक अपना अलग बही-खाता ढोता हुआ। इनमें से कोई भी चीज़ एक पिक्सल या ग्लिफ़ नहीं बदलती, और यही वह हिस्सा है जहाँ स्ट्रीम पुनःसंपीड़न पहुँच सकता है।
"संपीड़न" चार अलग-अलग चीज़ें हैं
आकार पर चार लीवर हैं, वे अलग-अलग परतों पर काम करते हैं, और उनकी कीमतें लगभग एक-दूसरे से नहीं टकरातीं। ग़लत लीवर चुनना ही सबसे आम वजह है कि संपीड़न चलाने पर लगता है कि कुछ हुआ ही नहीं।
| लीवर | किसे छूता है | आकार में लाभ | कीमत |
|---|---|---|---|
| स्ट्रीम पुनःसंपीड़न और ऑब्जेक्ट स्ट्रीम | कंटेंट स्ट्रीम कैसे संपीड़ित होती हैं, ऑब्जेक्ट कैसे रखे और पैक होते हैं | निर्भर करता है कि मूल फ़ाइल कितनी ढीली थी | पेज का रूप नहीं बदलता |
| इमेज डाउनसैंपलिंग | पिक्सल की संख्या, यानी रिज़ॉल्यूशन | बड़ा | रिज़ॉल्यूशन हमेशा के लिए घटा |
| लॉसी इमेज पुनः-एन्कोडिंग | बिटमैप का बाइट प्रतिनिधित्व | बड़ा | इमेज क्वालिटी घटी |
| फ़ॉन्ट सबसेटिंग | एम्बेडेड ग्लिफ़ टेबल | मध्यम | इस्तेमाल न हुए ग्लिफ़ अब संपादन-योग्य नहीं |
| लीनियराइज़ेशन | ऑब्जेक्ट का क्रम | लगभग शून्य | बदले में पहले पेज का लोड समय मिलता है |
पहली चारों पंक्तियों को ढीले अर्थों में "संपीड़न" कहा जाता है, पर सामग्री को अछूता सिर्फ़ पहली पंक्ति रखती है। इसी पंक्ति के फ़ायदे को आँकना सबसे आसानी से ग़लत होता है: जिस स्कैन का आकार ज़्यादातर कच्चे इमेज सैंपल से बना है, उसमें हटाने लायक बहुत कम अनावश्यकता बचती है, और जो लीवर उसे सचमुच बहुत छोटा कर सकते हैं वे डाउनसैंपलिंग और लॉसी पुनः-एन्कोडिंग हैं, जिनकी कीमत उस रिज़ॉल्यूशन और क्वालिटी को हमेशा के लिए खो देना है।
PDF123 Compress इनमें से कौन-सा करता है
PDF संपीड़ित करें (POST /api/v1/misc/compress-pdf) सिर्फ़ पहली पंक्ति करता है। यह qpdf को बिना संपीड़ित स्ट्रीम के संपीड़न (--compress-streams=y), पहले से Flate से संपीड़ित स्ट्रीम पर दूसरा दौर (--recompress-flate), और ऑब्जेक्ट को ऑब्जेक्ट स्ट्रीम में पैक करने (--object-streams=generate) के साथ चलाता है।
यह इमेज डाउनसैंपल नहीं करता, बिटमैप को कम JPEG क्वालिटी में पुनः-एन्कोड नहीं करता, और फ़ॉन्ट सबसेट नहीं करता। पेज वैसे ही दिखने चाहिए, और बचत Flate पुनःसंपीड़न तथा ऑब्जेक्ट-स्ट्रीम पैकिंग से आती है।
नाकामी की शर्त भी उतनी ही साफ़ कहनी चाहिए। जब किसी फ़ाइल का ज़्यादातर आकार JPEG जैसी पहले से संपीड़ित इमेज डेटा हो, तो Flate के पास निचोड़ने को कुछ नहीं बचता, क्योंकि वे इमेज बाइट ऊपर के तीन स्विचों की पहुँच से बाहर हैं। इसीलिए कोई स्कैन पैक सिर्फ़ कुछ प्रतिशत छोटा लौट सकता है, जबकि मिलते-जुलते आकार की टेक्स्ट-भारी PDF को साफ़ दिखने वाला ज़्यादा फ़ायदा मिलता है।
उलटा रास्ता PDF डीकंप्रेस करें है, जो जाँच के लिए स्ट्रीम खोलता है (--qdf, ऑब्जेक्ट स्ट्रीम बंद) और वह भी पेजों का रूप नहीं बदलता।
कब दूसरा रास्ता सही होता है
| आपको क्या चाहिए | कौन-सा रास्ता |
|---|---|
| बिलकुल वैसा ही रूप, बस पैकिंग का बोझ हटाना | संपीड़ित करें |
| स्कैन पैक वाकई बहुत बड़ा है और क्वालिटी की हानि स्वीकार्य है | डाउनसैंपलिंग या लॉसी पुनः-एन्कोडिंग, यह Compress नहीं |
| संपादन-योग्य रहे, पर अगला अक्षर टाइप ही न हो | दूसरी एक्सपोर्ट सेटिंग्स या स्रोत फ़ाइल, देखें फ़ॉन्ट सबसेटिंग |
| ब्राउज़र पहला पेज जल्दी दिखाए | लीनियराइज़ेशन पहले पेंट को हल करता है, आकार को नहीं |
| फ़ाइल खुलती ही नहीं | मरम्मत, यह आकार नहीं, ढाँचे की समस्या है |
आख़िरी पंक्ति में एक जाल है: यहाँ PDF लीनियराइज़ करें कोई अलग कार्यान्वयन नहीं, Compress का उपनाम है। दोनों एक ही ऑपरेशन की ओर इशारा करते हैं, मानक id misc/compress-pdf है और linearize-pdf केवल उपनाम, पोर्टल उस टूल के लिए हमेशा linearize=true और optimizeLevel=1 भेजता है, सर्वर इनमें से कोई फ़ील्ड नहीं पढ़ता, और qpdf को --linearize कभी नहीं दिया जाता। जो ऑपरेशन फ़ाइल को सचमुच लीनियराइज़ करता है वह सुरक्षित करें है, जब वह एन्क्रिप्ट करता है।
तो अगर आपको वही रूप छोटी फ़ाइल में चाहिए, तो संपीड़ित करें ही पूरा जवाब है। अगर लॉसी इमेज छोटा करना या फ़ॉन्ट सबसेटिंग चाहिए, तो यह रास्ता ग़लत लीवर है। फ़ाइल सीधे लौट आती है, किसी खाते की ज़रूरत नहीं। ऑब्जेक्ट, स्ट्रीम और क्रॉस-रेफ़रेंस टेबल असल में कहाँ रहते हैं, यह देखने के लिए PDF के अंदर क्या है पढ़ें।