PDF से Word बनने पर क्या बचता है और क्या मिट जाता है

वजह समझ लेने पर तय हो जाता है कि कौन सा औज़ार चुनें और उससे कितनी उम्मीद रखें।

PDF दस्तावेज़ नहीं, छपा हुआ काग़ज़ है

PDF के भीतर बस निर्देशों की एक लंबी सूची होती है: 72, 680 पर यह अक्षर छापो। फ़ाइल में कहीं दर्ज नहीं होता कि अनुच्छेद कहाँ ख़त्म हुआ, या कौन सी दो पंक्तियाँ एक ही तालिका की एक ही क़तार में थीं।

दस्तावेज़ को PDF में निर्यात करते ही वह जानकारी फेंक दी जाती है, ठीक वैसे ही जैसे छपे काग़ज़ को उसकी ज़रूरत नहीं होती। इसलिए उसे वापस लाना रूपांतरण नहीं, पुनर्निर्माण है: मूल आकार अक्षरों के बैठने की जगह से निकाला जाता है।

यही एक वाक्य बाक़ी सब समझा देता है। तालिका इसलिए टेढ़ी नहीं निकलती कि औज़ार ने तालिका ग़लत पढ़ी, बल्कि इसलिए कि पढ़ने को तालिका थी ही नहीं और उसे सिर्फ़ जगह देखकर दोबारा गढ़ना पड़ा।

जो अनुमान से निकलता है, और जो कभी था ही नहीं

इन दोनों को अलग कर लें तो पता चल जाता है कि क्या बेहतर हो सकता है और क्या नहीं।

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

सजावट हूबहू उतारने वाले औज़ारों से सावधान

कुछ औज़ार दावा करते हैं कि नतीजा मूल से पिक्सल-दर-पिक्सल मेल खाता है। खोलकर देखिए तो सचमुच खाता है। फिर आप एक पंक्ति बदलते हैं और दस्तावेज़ ढह जाता है।

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

रूपांतरण इसलिए है कि आप बदल सकें। जो नतीजा बदला न जा सके उसका उद्देश्य ही खो जाता है। अगर लक्ष्य हूबहू दिखना है, तो शुरू में बदलने की कोई वजह ही नहीं थी।

तालिका के ग़लत निकलने की असली वजह

PDF की तालिकाओं के चारों ओर बहुत बार कोई लकीर होती ही नहीं। जहाँ होती है वहाँ वे लेख से अलग परत पर खिंची होती हैं, शब्द निकालने वाली किसी भी चीज़ के लिए अदृश्य। इसीलिए लकीरें ढूँढ़ने पर टिके तरीक़े इतनी बार नाकाम होते हैं।

इसलिए जगह पढ़ी जाती है: जिन कोष्ठों का बायाँ किनारा कई पंक्तियों में एक ही जगह खड़ा हो उन्हें तालिका माना जाता है। यह तरीक़ा ख़ाली कोष्ठ पर सबसे कमज़ोर है। ख़ाली कोष्ठ फ़ाइल में कोई निशान नहीं छोड़ता, सो उस क़तार में एक कोष्ठ कम दिखता है और उसके बाद सब कुछ एक खाना खिसक जाता है।

जुड़े हुए कोष्ठों के साथ भी यही होता है। आपकी आँख दो कोष्ठों को मिला हुआ देखती है; फ़ाइल में बस एक लेख-टुकड़ा पड़ोसियों से थोड़ा बाईं ओर बैठा होता है।

स्कैन किए PDF को कोई औज़ार नहीं बदल सकता

दफ़्तर के स्कैनर से बना PDF हर पन्ने के लिए एक तस्वीर भर है। आपकी आँखों को अक्षर दिखते हैं, फ़ाइल में एक भी नहीं। यह औज़ार की सीमा नहीं, स्रोत में जानकारी की अनुपस्थिति है।

अक्षर पहचान (OCR) तस्वीर से लेख गढ़ सकती है। पर वह निकालना नहीं, पहचानना है, और उसमें शून्य को अंग्रेज़ी O पढ़ने जैसी ग़लतियाँ घुल जाती हैं। अनुबंध या जमा किए जाने वाले काग़ज़ में ऐसी ग़लती महँगी पड़ती है। जारी करने वाले से मूल फ़ाइल माँग लेना आम तौर पर तेज़ है।

संक्षेप में

रूपांतरक से पूछने वाला सवाल यह नहीं कि वह कितना मिलता-जुलता है, बल्कि यह कि जो निकला उसे आप बदल सकते हैं या नहीं। और जब नतीजा अधूरा हो, औज़ार की सीमा को प्रारूप की सीमा से अलग पहचान लेना आपको बेकार में औज़ार बदलते रहने से बचा लेता है।