ठीक की गई PDF भी PDF/A की जांच में फेल क्यों हो सकती है
न खुलने वाली PDF को ठीक करना और उसे आर्काइव के लायक बनाना दो बिल्कुल अलग मानक हैं। एक में पास होने से दूसरे के बारे में कुछ पता नहीं चलता।
लेखक: PulsarKit · ·
ज्यादातर नुकसान ढांचे का होता है, और ढांचा ठीक हो सकता है
असल में PDF का ज्यादातर नुकसान, यानी ऐसी फाइल जो बिल्कुल नहीं खुलती या खुलकर गड़बड़ी दिखाती है, टूटी हुई क्रॉस-रेफरेंस टेबल या खराब ट्रेलर की वजह से होता है। इसकी सबसे आम वजह बीच में रुका डाउनलोड या सेव करते समय जवाब देती डिस्क है। ऐसा नुकसान पूरी तरह ठीक हो सकता है। इस हालत में “PDF ठीक करें” को बस फाइल का अंदरूनी ढांचा दोबारा बनाना होता है, और फाइल अपने मूल कंटेंट के साथ लौट आती है, कुछ भी नहीं खोता। वजह यह है कि नीचे का पेज कंटेंट कभी छुआ ही नहीं गया था। टूटा था सिर्फ वह इंडेक्स, जो बताता है कि कंटेंट कहां मिलेगा। जो रीडर फाइल खोलने से मना करता है, वह टूटे नक्शे पर चलने से मना कर रहा है। वह यह नहीं कह रहा कि पेज ही गायब हैं।
पेज के कंटेंट का नुकसान अलग समस्या है
किसी खास पेज की खराब कंटेंट स्ट्रीम टूटे इंडेक्स से अलग तरह की समस्या है। इस हालत में उस पेज का वेक्टर टेक्स्ट और ड्रॉइंग के निर्देश गायब हो चुके हैं, वे सिर्फ मुश्किल से मिलने वाले नहीं हैं। ढांचे की कोई भी मरम्मत उस डेटा को दोबारा नहीं बना सकती, जो अब फाइल में है ही नहीं। व्यावहारिक रास्ता यह है कि उस पेज से जो कुछ अब भी बच सकता है, उसे इमेज के रूप में रेंडर करें और उस पर “PDF में OCR करें” चलाकर पढ़ने लायक टेक्स्ट वापस पाएं। उसी डॉक्यूमेंट के बाकी सभी सही पेज पूरे समय अपना मूल वेक्टर कंटेंट बिना बदलाव के रखते हैं।
ठीक होने लायक होना और PDF/A के मुताबिक होना अलग मानक हैं
जो PDF अब हर रीडर में सही खुलती है, साफ टेक्स्ट के साथ और कहीं कोई गड़बड़ी दिखाए बिना, वह भी PDF/A आर्काइव जांच में पूरी तरह फेल हो सकती है। यह अलग काम है, और इसी के लिए “PDF से PDF/A” बना है। PDF/A अलग और काफी सख्त मानक है, जो दूसरी चीजें जांचता है: फाइल का हर फॉन्ट उसके अंदर एम्बेड हो, सिर्फ नाम से न बुलाया गया हो; रंग किसी घोषित, तय प्रोफाइल से बंधे हों; और कहीं भी ऐसे बाहरी संसाधनों या सॉफ्टवेयर पर निर्भरता न हो, जो दशकों बाद पढ़ने वाले के पास शायद न हों। टूटा ढांचा ठीक करने का मकसद इनमें से किसी चीज की गारंटी देना कभी नहीं था। मरम्मत और आर्काइव मानक एक ही फाइल के बारे में दो अलग सवालों का जवाब देते हैं।
जांच का सच्चा फेल झूठे पास से ज्यादा काम का क्यों है
यहां Ghostscript जानबूझकर इस्तेमाल नहीं होता, उसकी लाइसेंस शर्तों की वजह से। उसके बिना PDF/A ढांचा बनाने का मतलब है जरूरी ढांचे को सीधे जोड़ना, न कि वह आम कन्वर्जन रास्ता अपनाना, जिस पर ज्यादातर टूल टिके हैं। इसलिए यह गारंटी वाली प्रक्रिया नहीं, बल्कि पूरी कोशिश वाली प्रक्रिया है। हर कन्वर्जन veraPDF से जांचा जाता है। यह वह रेफरेंस वैलिडेटर है, जिस पर असली आर्काइव और अदालतें भरोसा करती हैं। तसल्ली देने वाले सही के निशान की जगह उसका फैसला दिखाया जाता है, इसलिए फेल तभी दिखता है जब वह सच है। यह उस टूल से कहीं ज्यादा काम का है, जो ऐसी सफलता का दावा करता है जिसे वह साबित नहीं कर सकता।
खास गड़बड़ी को पढ़ना पास या फेल मानने से ज्यादा काम का है
जो जांच ठीक-ठीक वे नियम गिनाती है जिन्हें डॉक्यूमेंट पूरा नहीं कर पाया, जैसे कोई खास फॉन्ट जो एम्बेड नहीं हुआ या कोई कलर स्पेस जो सही से घोषित नहीं हुआ, उसका परिणाम काम का है और उस पर कदम उठाया जा सकता है। सिर्फ पास या फेल बताने वाला निशान ऐसा कभी नहीं कर सकता। जांच का नतीजा जो भी हो, फाइल डाउनलोड करें और पढ़ें कि क्या फेल हुआ। तब पूरे मानक की ओर पंचानवे प्रतिशत रास्ता तय कर चुके डॉक्यूमेंट को उस डॉक्यूमेंट जैसा नहीं माना जाता, जिस पर काम अभी मुश्किल से शुरू हुआ है। फेल हुए नियम बताते हैं कि अभी क्या ठीक करना बाकी है, और पूरे डॉक्यूमेंट पर शुरू से काम करने की जरूरत नहीं पड़ती।
मरम्मत का तरीका और PDF/A का लेवल चुनना
हर टूल पहले एक सवाल पूछता है, और गलत जवाब की कीमत एक बेकार चला काम है। “PDF ठीक करें” में तीन तरीके हैं। “ऑटो”, जो डिफॉल्ट है, ढांचा दोबारा बनाता है और इमेज और OCR का सहारा सिर्फ उस पेज पर लेता है, जिसकी कंटेंट स्ट्रीम टूटी है। “सिर्फ स्ट्रक्चर” ऐसा कभी नहीं करता: टूटा पेज खाली लौटता है। यह तब बेहतर है, जब हर बचे पेज पर असली, चुनने लायक टेक्स्ट रहना जरूरी है। “इमेज बनाकर OCR” हर पेज को, पढ़ने लायक पेजों को भी, पहचाने गए टेक्स्ट वाली इमेज के रूप में दोबारा बनाता है। यह उस फाइल के लिए ठीक है, जिसके शब्द बेमतलब अक्षरों की तरह दिखते हैं। परिणाम वाली स्क्रीन बताती है कि कौन-से पेज इमेज के रूप में वापस आए, इसलिए फाइल आगे भेजने से पहले उसे पढ़ें।
“PDF से PDF/A” लेवल पूछता है। 2b लगभग हर उस फाइल के लिए ठीक है, जो 2010 के बाद बनी है, और पारदर्शिता बनाए रखता है। 1b पारदर्शिता या लेयर वाले हर पेज को सादी इमेज में फ्लैट कर देता है, और नई फाइल को शायद ही कभी इसकी जरूरत होती है। 3b सिर्फ एक अधिकार जोड़ता है: फाइल के अंदर दूसरी फाइल एम्बेड करना, जैसे इनवॉइस की मूल स्प्रेडशीट। लेवल से ज्यादा दो बातें मायने रखती हैं। मानक एन्क्रिप्शन की इजाजत नहीं देता, इसलिए पासवर्ड वाली फाइल पर पहले “PDF से पासवर्ड हटाएं” चलाएं। और स्कैन तब तक सर्च करने लायक नहीं बनता, जब तक OCR का विकल्प चालू न हो। परिणाम आमतौर पर 10 से 40 प्रतिशत बड़ा होता है: जो फॉन्ट एम्बेड नहीं थे, उनकी जगह माप में मेल खाने वाले Liberation या Noto फॉन्ट आते हैं, और रंग sRGB से बांध दिए जाते हैं।
इस लेख में इस्तेमाल हुए टूल
आगे पढ़ें
- PDFgear का विकल्प: क्या मिलता है और आपकी फाइल कहां जाती है20 अक्टूबर 2026 को हमने PDFgear के ऑनलाइन टूल वाले पेज के 37 कार्ड का PulsarKit से मिलान किया। उनके पीछे के 36 टूल में से 34 का विकल्प मिला; PDF to PSD और PSD to PDF का कोई विकल्प नहीं था।
- स्कैन की गई किताब को कंप्रेस करना: 60 पेजों पर हर लेवल क्या करता हैएक फोरम पर किसी ने पूछा कि 580 पेज वाली किताब के स्कैन को टेक्स्ट बिगाड़े बिना छोटा कैसे करें। हमने 60 पेज का एक स्कैन “PDF कंप्रेस करें” के हर लेवल से गुजारा और पिक्सल, साइज और शब्द, तीनों जांचे।
- iPhone की कई फोटो से एक PDF: HEIC, क्रम, साइज और फोन से क्या बाहर जाता हैSafari में iPhone की कई फोटो से एक PDF बन सकती है, बिना ऐप और बिना अकाउंट के। यहां देखें कि “HEIC से PDF” क्रम, पेज का साइज, Live Photo, तारीख और लोकेशन को कैसे संभालता है, और क्या आपके फोन से बाहर नहीं जाता।