PDF email में attach क्यों नहीं होता

PDF ईमेल से अटैच नहीं होती: सीमा असल में कहाँ है

स्थिति सीधी दिखती है: फ़ाइल बताई गई सीमा से छोटी है और संदेश जाता नहीं। या जाता है और पहुँचता नहीं। कारण लगभग हमेशा दो में से एक होता है, जिनके बारे में मेल सेवाएँ बात नहीं करतीं: अटैचमेंट संदेश के भीतर डिस्क से ज़्यादा वज़नी होता है, और सीमा एक नहीं होती।

बीस मेगाबाइट की फ़ाइल यानी लगभग सत्ताईस मेगाबाइट का संदेश

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

सुविधाजनक गणित: फ़ाइल का आकार 1.37 से गुणा कीजिए, संदेश का अनुमानित आकार मिल जाएगा।

इससे व्यावहारिक निष्कर्ष: 25 मेगाबाइट की सीमा भरोसे से लगभग अठारह की फ़ाइल स्वीकारती है। 20 मेगाबाइट की सीमा लगभग चौदह की।

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

सीमाएँ दो हैं, और छोटी वाली जीतती है

भ्रम का दूसरा स्रोत। आपकी मेल सेवा जाने वाले संदेश को सीमित करती है, प्राप्तकर्ता का सर्वर आने वाले को, और ये दोनों संख्याएँ आपस में जुड़ी नहीं हैं।

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

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

अगर किसी ने शर्त नहीं बताई, तो दस मेगाबाइट समझदार लक्ष्य है। यह मान व्यावहारिक रूप से हर जगह गुज़र जाता है।

सीमा में कैसे आएँ

1. फ़ाइल का असली आकार अनुमान से नहीं, गुणों में देखिए। 2. उसे 1.37 से गुणा करके अपनी मेल सेवा की सीमा से मिलाइए। 3. न आए तो compress-pdf खोलकर दस्तावेज़ दबाइए। 4. नया आकार जाँचिए: डिफ़ॉल्ट सेटिंग्स पर कंप्रेशन स्कैन से अच्छा-ख़ासा हिस्सा हटाता है और टेक्स्ट दस्तावेज़ों से लगभग कुछ नहीं। 5. उसके बाद भी बड़ी रहे तो split-pdf से काटकर हिस्सों में भेजिए। 6. पते वाले को भेजने से पहले संदेश ख़ुद को भेजिए; लौटा हुआ संदेश आप उनसे पहले देख लेंगे।

जब कंप्रेशन काम न आए

कंप्रेशन एक ख़ास हालत में बेबस है: फ़ाइल पहले से ही अनुकूल है। यह उन दस्तावेज़ों के साथ होता है जो सीधे किसी संपादक से निर्यात हुए, और उन फ़ाइलों के साथ जो पहले एक बार कंप्रेस हो चुकी हैं।

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

आगे तीन रास्ते बचते हैं, और वे बराबर नहीं हैं।

दस्तावेज़ को हिस्सों में बाँटना। हमेशा काम करता है, पर प्राप्तकर्ता को कई संदेश मिलते हैं और उसे ख़ुद जोड़ना पड़ता है। हिस्सों के नाम ऐसे रखिए कि क्रम एक नज़र में पढ़ा जाए: भाग 1 का 3, भाग 2 का 3।

जो वहाँ का नहीं, उसे हटाना। अगर फ़ाइल में ऐसे पेज हैं जिनकी पते वाले को ज़रूरत नहीं, तो remove-pages उनका पूरा वज़न ले जाता है, अंश भर नहीं। अक्सर यह किसी भी कंप्रेशन से बेहतर है।

रंग हटाना। धूसर स्कैन रंगीन के मुक़ाबले लगभग आधा वज़नी होता है, क्योंकि तीन रंग चैनलों की जगह एक चमक चैनल आ जाता है। pdf-to-grayscale ठीक यही करता है। ध्यान रखिए कि वह पेजों को तस्वीरों के रूप में दोबारा बनाता है, इसलिए टेक्स्ट लेयर चली जाती है: जिसे इंसान पढ़ेगा उस दस्तावेज़ के लिए यह मायने नहीं रखता, जिसमें खोज होगी उसके लिए रखता है।

अटैचमेंट की जगह लिंक: कब उचित है

बड़ी मेल सेवाएँ हद से बड़े अटैचमेंट को क्लाउड लिंक से बदलने का प्रस्ताव देती हैं। मान लेने का लालच बड़ा है, पर इस चुनाव की एक क़ीमत है जिस पर पहले सोच लेना बेहतर है।

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

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

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

जिसे आकार की सीमा समझ लिया जाता है

कुछ अस्वीकृतियाँ आकार की समस्या जैसी दिखती हैं और कारण कुछ और होता है।

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

ऐसा एक्सटेंशन जो सामग्री से मेल न खाए। फ़ाइल `.pdf` कहलाए और भीतर संग्रह या तस्वीर हो, तो कुछ मेल फ़िल्टर फ़ाइल की हस्ताक्षर-पंक्ति और नाम के बीच के अंतर पर प्रतिक्रिया करते हैं।

एक अटैचमेंट नहीं, पूरे संदेश का कुल आकार। चार-चार मेगाबाइट की पाँच फ़ाइलें कूटबद्धता से पहले बीस मेगाबाइट और बाद में क़रीब सत्ताईस देती हैं। सीमा पूरे संदेश पर गिनी जाती है, इसलिए अटैचमेंट के पुलिंदे को merge-pdf से एक PDF में जोड़ लेना या कई संदेशों में बाँट देना बेहतर है।

भेजने से पहले की जाँच

एक तरक़ीब है जो पत्राचार का एक चक्कर बचा देती है। संदेश पहले ख़ुद को भेजिए, और प्रतिलिपि में किसी दूसरी मेल सेवा का अपना दूसरा पता रखिए।

एक मिनट में तीन बातें दिख जाएँगी: संदेश आपकी बाहर जाने वाली सीमा पार कर पाया या नहीं, वह किसी पराए सर्वर तक पहुँचा या नहीं, और दूसरी ओर अटैचमेंट कैसा दिखता है। आख़िरी बात छोटी नहीं है: कुछ गेटवे अटैचमेंट के नाम बदल देते हैं या उन्हें संग्रह में लपेट देते हैं, और पते वाले को वह नहीं मिलता जो आपने भेजा था।