PDF को बिना पठनीयता खोए कैसे compress करें

PDF को पढ़ने-योग्यता खोए बिना कैसे compress करें

Form पर सीमा चालीस megabyte लिखी है और आपकी फ़ाइल बावन की है. Compression यह एक मिनट में हल कर देता है, पर उसकी settings हैं, और default वाली सबसे स्पष्ट नहीं हैं.

पहले यह समझ लेना अच्छा है कि वज़न आता कहाँ से है. PDF में text का वज़न लगभग शून्य होता है. Document को भारी बनाती हैं तस्वीरें: scans, फ़ोटो, screenshots, मूल resolution में छोड़े गए logos. इसलिए compression मुख्य रूप से तस्वीरों पर काम करता है, और शुद्ध text वाले contract पर कम ही देगा.

Compression level और वह profile जो उसे बदल देता है

Levels तीन हैं, और default में सबसे तेज़ वाला है.

बग़ल में दूसरी setting है, processing profile, और यही अटपटा व्यवहार करती है. Profiles भी तीन हैं: तेज़, संतुलित और quality. Default में संतुलित.

अटपटापन यह है कि quality profile सिर्फ़ ज़्यादा सावधानी से process नहीं करता, वह चुने गए compression level को एक पायदान नीचे कर देता है. यानी ऊँचा level quality profile के साथ असल में मध्यम जैसा चलेगा. यह ख़राबी नहीं, बल्कि इस बात से सोची-समझी सुरक्षा है कि कोई एक साथ अधिकतम compression और अधिकतम quality दोनों माँग ले.

तेज़ profile अलग बना है: वह मुख्य processing pass छोड़ देता है. फ़ाइल काफ़ी जल्दी तैयार होती है, पर कम भी होती है. जल्दी भेजने के लिए यह समझदार सौदा है, archive के लिए नहीं.

Target DPI

Document के भीतर तस्वीरों का target resolution अलग से तय होता है, 72 से 600 तक, default 150.

यह वह resolution है जिस पर तस्वीरें दोबारा गिनी जाएँगी. डेढ़ से दो सौ को screen पर पढ़े जाने वाले documents के लिए काम की सीमा माना जाता है: scan का text पढ़ने लायक़ रहता है और वज़न कई गुना गिर जाता है. सौ से नीचे छोटी लिखावट बिखरने लगती है.

Settings के मेल में एक बारीक़ी है. Target DPI मुख्य pass में लगता है, और तेज़ profile उसी pass को छोड़ देता है. यानी तेज़ profile के साथ आपका तय किया DPI काम ही नहीं करेगा, बशर्ते image optimisation चालू न हो, क्योंकि वह तस्वीरें अलग से दोबारा गिनती है.

Image optimisation default में बंद है

यह setting embedded तस्वीरों को दोबारा encode करती है और वहाँ अतिरिक्त फ़ायदा देती है जहाँ वे अकुशलता से सहेजी गई थीं.

वह यूँ ही बंद नहीं है: दोबारा encode करने से pixels ख़ुद बदल जाते हैं. जो document authenticity जाँच, अदालत या विशेषज्ञ परीक्षण में जाएगा, उसके लिए यह अस्वीकार्य हो सकता है. अगर तस्वीरों की सटीकता मायने रखती है, इसे बंद ही रहने दीजिए.

बाक़ी सभी हालात में इसे चालू करना ठीक है. Scans के ढेर पर यह आम तौर पर सबसे साफ़ फ़ायदा देती है, क्योंकि scanners और फ़ोन तस्वीरें ख़ासे मार्जिन के साथ सहेजते हैं.

क़दम दर क़दम

1. compress-pdf खोलें और document अपलोड करें. 2. Level ऊँचे पर ही रहने दें, जब तक पक्का न हो कि नरम pass चाहिए. 3. ऊँचा level और quality profile एक साथ मत लगाइए: वे एक-दूसरे को काट देते हैं. 4. Scans के लिए image optimisation चालू कीजिए. 5. Result डाउनलोड कीजिए और सबसे भरा हुआ पेज खोलिए, पहला नहीं: वह जिसमें छोटी लिखावट, मुहर या table है.

पाँचवाँ क़दम जितना दिखता है उससे ज़्यादा मायने रखता है. Title page compression लगभग हमेशा अच्छे से झेल जाता है; बिखरती आम तौर पर आठवें पेज पर table के नीचे की छोटी लिखावट है.

Result मूल से भारी क्यों कभी नहीं होता

यह अपने आप नहीं, जानबूझकर बनाया गया है, और इसे जानना काम का है.

Compression एक ही pass नहीं करता. वह कई variants आज़माता है और अंत में उन्हें आपस में और मूल फ़ाइल से मिलाता है. बाहर सबसे छोटा जाता है. अगर कोई भी variant मूल से हल्का नहीं निकला, तो मूल जीतता है.

इससे व्यावहारिक निष्कर्ष: compression आज़माने में कोई जोखिम नहीं. सबसे बुरा यही होगा कि आपकी अपनी फ़ाइल ईमानदार सन्देश के साथ लौट आए. «compress किया और बड़ा हो गया» वाली स्थिति यहाँ बनावट से ही नहीं बनती.

इसी से यह भी निकलता है कि चमत्कार की आस में settings बदलते रहने का फ़ायदा कम है. अगर ऊँचे level और चालू image optimisation ने कुछ नहीं दिया, तो कम level तो और भी नहीं देगा: service एक ही run के भीतर variants पहले ही आज़मा चुकी है. बदलनी settings नहीं, बल्कि पहुँच है, यानी content घटाना है.

एक बार में कई फ़ाइलें

एक साथ कई documents compress किए जा सकते हैं, और settings सब पर एक जैसी लगती हैं. यह एक जैसे सेट के लिए सुविधाजनक है: एक ही तरह के दस scans एक ही झटके में निपट जाते हैं.

बाहर archive आता है जिसमें फ़ाइलें आपके मूल नामों के साथ `compressed_` उपसर्ग लिए होती हैं. अगर upload में एक ही नाम की दो फ़ाइलें थीं, तो नामों में नंबर जुड़ जाएँगे ताकि कुछ मिटे नहीं.

Result की रिपोर्ट हालाँकि कुल जोड़ नहीं है: service नाम लेकर बताती है कि कौन सी फ़ाइलें घटाई नहीं जा सकीं. ढेर के लिए यह अहम है, क्योंकि archive का कुल वज़न सफल फ़ाइलों की वजह से गिर सकता है और उस अकेली फ़ाइल को छिपा सकता है जो अड़ गई और अब भी limit में नहीं आती.

अगर सेट मिला-जुला है, उसे समूहों में बाँटिए. Text और scans को अलग settings चाहिए: पहले पर image optimisation बेकार है, दूसरे पर सारा फ़ायदा उसी में है.

वज़न घटाने का एक और तरीक़ा: रंग हटाना

अगर compression ने जो हो सकता था सब निचोड़ लिया और फ़ाइल फिर भी भारी है, तो एक तरीक़ा बचता है जिसे लोग भूल जाते हैं.

काले-सफ़ेद document का रंगीन scan ऐसा रंग सहेजता है जो असल में है ही नहीं: काग़ज़ का धूसर रंग, lamp की पीली आभा, मोड़ की नीली परछाईं. यह सब सार्थक data जितनी ही जगह घेरता है. pdf-to-grayscale से grayscale में बदलने पर यह बोझ पूरा हट जाता है, और scans के ढेर पर फ़ायदा आम तौर पर ख़ुद compression से बड़ा होता है.

Grayscale के तीन profiles हैं, और default में standard रहता है, मिले-जुले दफ़्तरी documents के लिए सुरक्षित. सावधानी वहाँ चाहिए जहाँ रंग अर्थ रखता हो: नीली मुहर, रंगीन हस्ताक्षर, marker से उभारी गई पंक्ति. बदलने के बाद वे पढ़ने लायक़ रहेंगे पर रंगीन नहीं रहेंगे, और अगर लेने वाला पक्ष रंग की उम्मीद करता है तो यह रास्ता ठीक नहीं.

यहाँ क्रम मायने रखता है: पहले grayscale, फिर compression. उल्टा करना कमज़ोर काम करता है, क्योंकि compression उन रंग-data पर मेहनत लगाएगा जिन्हें आप वैसे भी फेंकने वाले थे.

किसे compress करना बेकार है

Text और tables से बना document कुछ प्रतिशत ही घटता है. वहाँ ध्यान देने योग्य फ़ायदे की उम्मीद यथार्थ नहीं, और अगर ऐसी फ़ाइल वज़न की limit पार नहीं कर पाती, तो वजह शायद पेजों की संख्या है, तस्वीरें नहीं.

अलग मामला है पहले से compress की गई फ़ाइल. दूसरा pass वज़न लगभग नहीं घटाता जबकि quality दूसरी बार गिरती है, क्योंकि पिछले pass के निशान नए पर चढ़ जाते हैं. अगर result पसंद न आया, तो तैयार फ़ाइल दोबारा चलाने के बजाय मूल पर लौटकर उसे एक बार दूसरी settings से compress कीजिए.

शुरू से ही कम quality में बना scan भी compress करने लायक़ कम रखता है: उसमें data ही ज़्यादा नहीं. ऐसा document optimise करने से आसान दोबारा लेना है.