मेरी PDF फ़ाइल इतनी बड़ी क्यों है? (और इसे असल में कैसे ठीक करें)

"यह PDF इतनी बड़ी क्यों है" वाली उलझन आमतौर पर वहीं से शुरू होती है जब PDF को एक जैसा, एकसमान फ़ाइल फ़ॉर्मेट मान लिया जाता है, जैसे कोई प्लेन टेक्स्ट फ़ाइल होती है — जबकि PDF असल में एक कंटेनर फ़ॉर्मेट के ज़्यादा क़रीब है, कुछ-कुछ ZIP आर्काइव जैसी भावना में, जो कई तरह के वाक़ई अलग-अलग कंटेंट को एक साथ बाँधता है: पेज लेआउट के निर्देश, एम्बेडेड फ़ॉन्ट, एम्बेडेड इमेज, वेक्टर ग्राफ़िक्स, और मेटाडेटा, जिनमें से हर एक अपने अलग आंतरिक रूप में स्टोर होता है। कंटेनर की बनावट ख़ुद — जो हिस्सा असल में PDF के लिए ख़ास है — बहुत छोटा होता है; जिस PDF में सिर्फ़ प्लेन टेक्स्ट और सादा लेआउट हो, बिना किसी एम्बेडेड इमेज या असामान्य फ़ॉन्ट के, वह चाहे कितने भी पेज की हो, आमतौर पर बस कुछ किलोबाइट की रहती है। जब भी कोई PDF दसियों या सैकड़ों मेगाबाइट तक फूल जाती है, तो यह साइज़ उस कंटेनर के अंदर एम्बेड की गई चीज़ों से आ रहा होता है, न कि कंटेनर फ़ॉर्मेट से ख़ुद — यही वजह है कि "मेरी PDF इतनी बड़ी क्यों है" का जवाब लगभग हमेशा कोई ख़ास, पहचानी जा सकने वाली वजह होता है, न कि फ़ॉर्मेट का कोई सहज गुण।

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

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

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

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

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

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