PDF से Word

किसी PDF पेज में "पैराग्राफ़" या "हेडिंग" जैसी कोई अवधारणा नहीं होती जैसे Word दस्तावेज़ में होती है — अंदरूनी रूप से यह पोज़िशन किए गए टेक्स्ट रन का एक सेट है, हर एक असल में यह कहता है, "इन कैरेक्टर को इस x,y कोऑर्डिनेट पर, इस फ़ॉन्ट में बनाओ।" इसमें कोई आउटलाइन नहीं, कोई दस्तावेज़ स्ट्रक्चर नहीं, यहाँ तक कि यह भी भरोसे के साथ तय नहीं होता कि एक लाइन कहाँ ख़त्म होती है और अगली कहाँ शुरू होती है; कोई PDF व्यूअर किसी पेज की विज़ुअल शक्ल को हर टेक्स्ट रन उसकी बताई गई पोज़िशन पर पेंट करके दोबारा बनाता है, और नतीजा पढ़ने वाला व्यक्ति लाइन और पैराग्राफ़ इसलिए महसूस करता है क्योंकि पोज़िशन संयोग से उसी तरह मेल खाती हैं। PDF को एडिट करने लायक़ दस्तावेज़ में कन्वर्ट करने का मतलब है उससे उल्टा काम करना: मिलती-जुलती वर्टिकल पोज़िशन वाले टेक्स्ट रन को लाइन में जोड़ना, फिर यह देखना कि एक लाइन और अगली के बीच वर्टिकल गैप कहाँ असामान्य रूप से बड़ा है — यह संकेत कि अभी एक पैराग्राफ़ ख़त्म हुआ — और उसे पैराग्राफ़ ब्रेक मानना। यह मूल रूप से पोज़िशन डेटा से दोबारा बनाना है, फ़ाइल में छुपे किसी दस्तावेज़ स्ट्रक्चर को पढ़ना नहीं, और यही वजह है कि मूल फ़ॉर्मेटिंग वापस नहीं पाई जा सकती: फ़ाइल में शुरू से ही कोई स्ट्रक्चर्ड फ़ॉर्मेटिंग जानकारी नहीं थी जिसे वापस पाया जा सके, सिर्फ़ यह कि स्याही कहाँ रखी गई थी।

"PDF पढ़ना" और "स्कैन किया पेज पढ़ना" को एक ही काम मान लेना आसान है जिसके लिए एक ही टूल चाहिए, लेकिन ये असल में अलग-अलग समस्याएँ हल करते हैं। टेक्स्ट एक्सट्रैक्शन, जो यह टूल करता है, वह टेक्स्ट पढ़ता है जिसे PDF पहले से टेक्स्ट के रूप में स्टोर करती है — कैरेक्टर कोड और पोज़िशन, वही डेटा जिसे PDF व्यूअर किसी वाक्य को सिलेक्ट और कॉपी करने देने के लिए इस्तेमाल करता है। OCR (ऑप्टिकल कैरेक्टर रिकग्निशन) एक कहीं ज़्यादा मुश्किल समस्या हल करता है: किसी ऐसे पेज को देखना जो सिर्फ़ एक तस्वीर है, फ़ाइल में कहीं भी टेक्स्ट डेटा नहीं, और इमेज रिकग्निशन का इस्तेमाल करके अंदाज़ा लगाना कि वह तस्वीर कौन-से अक्षर और शब्द दिखाती है। यह एक असल में भारी काम है — इसमें इमेज प्रोसेसिंग, कैरेक्टर रिकग्निशन मॉडल, और "सही" जवाब क्या है इसकी अंतर्निहित अनिश्चितता शामिल है, इनमें से कुछ भी तब लागू नहीं होता जब टेक्स्ट पहले से टेक्स्ट के रूप में मौजूद हो। किसी ऐसे टूल में पूरा OCR इंजन जोड़ना जिसकी पूरी अपील ब्राउज़र में तुरंत चलना है, उस स्पीड और सादगी को गँवा देगा जो इस टूल को उन चंद PDF के लिए उपयोगी बनाती है जो संयोग से स्कैन होती हैं। स्कैन की गई, सिर्फ़-इमेज वाली PDF एक असली और आम मामला है, और यह टूल चुपचाप ख़ाली दस्तावेज़ बनाने की बजाय अपने नतीजों में यह साफ़ तौर पर बताता है — लेकिन इसे सही तरीक़े से हल करने के लिए एक डेडिकेटेड OCR टूल चाहिए, इस टूल को उससे आगे खींचना नहीं जो यह ईमानदारी से करता है।

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