माझी PDF जेमतेमच लहान का झाली?
कॉम्प्रेसरमधून PDF काढली तर ती 4.1 MB वरून फक्त 4.0 MB झाली. टूलमध्ये काही बिघाड आहे का?
PDF म्हणजे एक फाइलिंग कॅबिनेट
निराशा घडवणारी कल्पना अशी की PDF म्हणजे दस्तऐवजाचं चित्र. तसं नाही. ISO 32000 मध्ये व्याख्या केल्याप्रमाणे PDF हा क्रमांकित ऑब्जेक्टचा कंटेनर असतो: पेज ट्री, ड्रॉइंग ऑपरेटरनी भरलेले कंटेंट स्ट्रीम, एम्बेड केलेले फॉन्ट प्रोग्राम, इमेज XObject, फॉर्म फील्ड, ॲनोटेशन, आउटलाइन, आणि प्रत्येक ऑब्जेक्ट कुठून सुरू होतो हे सांगणारा क्रॉस-रेफरन्स टेबल.
यांपैकी बहुतांश ऑब्जेक्ट आधीच कॉम्प्रेस केलेले असतात. कंटेंट स्ट्रीम सहसा Flate मध्ये एन्कोड केलेले असतात — तोच अल्गोरिदम ZIP फाइल वापरते. एम्बेड केलेले फोटो सहसा DCT स्ट्रीम म्हणून साठवलेले असतात, म्हणजे जसाच्या तसा पुढे दिलेला JPEG डेटा. त्यामुळे सर्वसाधारण कॉम्प्रेसर जेव्हा PDF कडे बघतो, तेव्हा तो अशा वस्तूंच्या पेटीकडे बघत असतो, ज्यातली प्रत्येक वस्तू आधीच एकदा कॉम्प्रेस होऊन बसलेली आहे.
काहीही कॉम्प्रेस करण्याआधी बाइट्स कुठे आहेत ते शोधा
सर्वात उपयोगी एकच तपासणी म्हणजे आपल्याकडे कोणत्या प्रकारचा दस्तऐवज आहे हे ओळखणं, कारण त्यावरूनच निकाल जवळपास पूर्णपणे ठरतो.
| दस्तऐवजाचा प्रकार | बाइट्स कुठे आहेत | स्ट्रक्चरल सेव्ह काय करू शकतं |
|---|---|---|
| वर्ड प्रोसेसरमधून आलेला मजकुरी अहवाल | एम्बेड केलेले फॉन्ट प्रोग्राम आणि लहान कंटेंट स्ट्रीम | फार थोडं; मजकूर आधीच घट्ट बसलेला आहे |
| स्कॅन केलेली पानं | प्रत्येक पानामागे एक मोठी इमेज | इमेजना हात लावल्याशिवाय जवळपास काहीच नाही |
| प्रेझेंटेशनमधून केलेला एक्स्पोर्ट | एम्बेड केलेले फोटो आणि ग्रेडियंट | काहीसं, जर एकच इमेज अनेक स्लाइडवर पुन्हा पुन्हा असेल तर |
| इंजिनिअरिंग ड्रॉइंग | लांबलचक व्हेक्टर कंटेंट स्ट्रीम | काहीसं — स्ट्रीम पुन्हा एन्कोड करून आणि न वापरलेले ऑब्जेक्ट काढून |
| जोडपत्रं असलेला फॉर्म | एम्बेड केलेल्या फाइल, JavaScript, ॲनोटेशन डिक्शनरी | बरंच, जर ती जादाची सामग्री काढता येण्याजोगी असेल तर |
स्ट्रक्चरल सेव्ह प्रत्यक्षात काय काढून टाकतं
स्ट्रक्चरल सेव्ह कोणत्याही पानाचं दिसणं न बदलता दस्तऐवज पुन्हा लिहितं. ज्यांचा आता कुठेच संदर्भ उरलेला नाही असे ऑब्जेक्ट ते काढून टाकू शकतं — दस्तऐवज एडिट करून टप्प्याटप्प्याने सेव्ह केला की असे ऑब्जेक्ट दर वेळी साचत जातात. ते क्रॉस-रेफरन्स टेबल कॉम्प्रेस करू शकतं आणि लहान ऑब्जेक्ट ऑब्जेक्ट स्ट्रीममध्ये एकत्र बांधू शकतं. दस्तऐवजाचा मेटाडेटा, थंबनेल आणि काही प्रोड्युसर मागे सोडून जातात तो एडिटिंगचा इतिहासही ते काढून टाकू शकतं.
अनेकदा एडिट करून पुन्हा पुन्हा सेव्ह केलेल्या दस्तऐवजात हा मोठा फायदा ठरू शकतो. वर्ड प्रोसेसरमधून एकदाच, स्वच्छपणे एक्स्पोर्ट केलेल्या दस्तऐवजात मात्र गोळा करण्यासारखं काहीच नसतं: फाइल आधीच स्वतःच्या सर्वात लहान रूपाच्या जवळ असते, आणि चार मेगाबाइटमधून शंभर किलोबाइट कमी होणं हाच अपेक्षित निकाल आहे.
मजकुराचा दस्तऐवज दाद का देत नाही
मजकुराच्या PDF मध्ये फाइलचा मोठा वाटा सहसा एम्बेड केलेल्या फॉन्टचा असतो. फॉन्ट प्रोग्राम म्हणजे ग्लिफची रेखाटनं आणि हिंटिंग सूचना असलेली एक आटोपशीर बायनरी, आणि ती तिथे असते कारण तो टाइपफेस इन्स्टॉल नसलेल्या मशीनवरही दस्तऐवज हुबेहूब तसाच दिसला पाहिजे. तो आणखी सबसेट केल्याशिवाय किंवा काढून टाकल्याशिवाय कॉम्प्रेस करून घालवता येत नाही, आणि तो काढला की पानाचं दिसणं बदलतं.
मजकूर स्वतः मात्र नगण्य असतो. शंभर पानांचं गद्य म्हणजे कॉम्प्रेशनआधीही जेमतेम काहीशे किलोबाइट अक्षरं. तुमची मजकुराची PDF मोठी असेल, तर शब्दांकडे बघण्याऐवजी फॉन्टकडे आणि मजकुरामागे दडलेल्या इमेजकडे बघा — हेडरमध्ये पुन्हा पुन्हा येणारा लोगो, पार्श्वभूमीतला वॉटरमार्क.
स्कॅन मात्र धडाधड लहान का होतो
स्कॅन केलेलं पान म्हणजे कागदाच्या एका तुकड्याचा मोठा फोटो, आणि तो बऱ्याचदा 300 डॉट्स प्रति इंच किंवा त्याहून जास्त रिझोल्यूशनवर घेतलेला असतो. 300 DPI वरचं A4 पान साधारण 2480 × 3508 पिक्सेलचं असतं — म्हणजे जवळपास नऊ दशलक्ष पिक्सेल, आणि त्या पानावरची माहिती मात्र काही किलोबाइट मजकुराएवढीच. म्हणूनच रास्टराइज्ड कॉम्प्रेशनला स्कॅन इतका नाट्यमय प्रतिसाद देतात: रेंडर रिझोल्यूशन कमी करून पानांच्या इमेज पुन्हा एन्कोड केल्या की फाइलमधल्या खरोखरच मोठ्या असलेल्या भागावरच घाव बसतो.
आणि म्हणूनच तो मोड विध्वंसक आहे. पान एकदा चित्र झालं की शोधता येणारा मजकुराचा थर, लिंक, फॉर्म फील्ड, ॲनोटेशन, ॲक्सेसिबिलिटीसाठीची टॅग केलेली रचना आणि कोणतीही डिजिटल स्वाक्षरी — हे सगळं संपतं. म्हणूनच स्ट्रक्चरल सेव्हने निराशा झाल्यावर गुपचूप वापरला जाणारा पर्याय म्हणून नव्हे, तर तो इशारा जोडलेला वेगळा आणि स्पष्ट नाव दिलेला मोड म्हणून FileSlimmer रास्टरायझेशन हाताळतं.
ठराविक आकड्याचं वचन कोणीच का देऊ शकत नाही
PDF साठी ठरवलेला लक्ष्य आकार म्हणजे रेंडर रिझोल्यूशन आणि इमेज क्वालिटी यांच्यातला शोध, आणि या शोधाला एक तळ असतो: एका ठराविक रिझोल्यूशनखाली स्कॅनवरचा मजकूर वाचता येईनासा होतो. त्या तळाच्या वर राहून एखादा दस्तऐवज ठराविक मर्यादेपर्यंत पोहोचेल की नाही, हे पानांची संख्या, शाईचं प्रमाण, फोटोसदृश मजकुराचं प्रमाण आणि स्कॅनरचा नॉइज यांवर अवलंबून असतं. सारख्याच पानसंख्येचे दोन दस्तऐवज अगदी वेगवेगळ्या आकारांवर येऊन थांबू शकतात.
प्रामाणिक वर्तन म्हणजे तळाशी थांबणं आणि शोध कुठे थांबला हे सांगणं — FileSlimmer चे PDF टार्गेट प्रीसेट नेमकं तेच करतात. जे टूल तुम्ही टाइप केलेला आकडा दर वेळी गाठतं, ते एक तर त्या आकड्याबद्दल खोटं बोलत आहे, किंवा तो गाठण्यासाठी दस्तऐवजाची नासाडी करत आहे.
टूलला दोष देण्याआधी
- PDF हा स्कॅन आहे का ते तपासा. मजकुराची एक ओळ निवडून बघा: कर्सरने काहीच निवडलं जात नसेल, तर प्रत्येक पान ही एक इमेज आहे.
- आकाराच्या तुलनेत पानांची संख्या तपासा. तीन पानांची 40 MB फाइल इमेजनी गच्च भरलेली आहे; 900 पानांची 40 MB फाइल पूर्णपणे रास्त असू शकते.
- दस्तऐवज एनक्रिप्ट केलेला आहे का ते तपासा. पासवर्डने संरक्षित 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