रेंडर टाइम पर PDF पार्स करना बंद करें
अधिकांश फ्रंटएंड PDF एक्सट्रैक्शन टूल्स विफल हो जाते हैं।
डेवलपर्स विजुअल आउटपुट से डॉक्यूमेंट स्ट्रक्चर का अनुमान लगाने की कोशिश करते हैं। वे कॉलम, टेबल या लिस्ट खोजने के लिए रेंडर किए गए पिक्सेल को देखते हैं। वे यह तय करने के लिए कि बॉक्स कहाँ से शुरू होता है, कंप्यूटर विजन या पिक्सेल प्रॉक्सिमिटी का उपयोग करते हैं।
यह बनाने का गलत तरीका है।
एक PDF में उसके ऑपरेटर स्ट्रीम (operator stream) में पहले से ही स्पष्ट स्ट्रक्चरल डेटा होता है। एक टेबल केवल पास के पिक्सेल का समूह नहीं है। इसे moveTo, lineTo, या rectangle जैसे विशिष्ट कमांड के साथ ड्रा किया जाता है। आप जिन सीमाओं को खोजना चाहते हैं, वे पहले से ही सोर्स में एनकोडेड हैं।
यदि आपका एक्सट्रैक्टर 100% ज़ूम बनाम 150% ज़ूम पर अलग-अलग कॉलम देता है, तो आप स्ट्रक्चर नहीं निकाल रहे हैं। आप विजुअल आर्टिफैक्ट्स का पैटर्न-मैचिंग कर रहे हैं।
विजुअल ह्यूरिस्टिक्स का उपयोग करना बंद करें। ऑपरेटर स्ट्रीम को पार्स करना शुरू करें।
ऑपरेटर स्ट्रीम बेहतर क्यों है:
- यह डिटरमिनिस्टिक (deterministic) है। यह स्केल या फ़ॉन्ट हिंटिंग की परवाह किए बिना एक ही तरह से काम करता है।
- यह वास्तविक डेटा का उपयोग करता है। आप क्रिएटर द्वारा परिभाषित वास्तविक पाथ और कोऑर्डिनेट्स का उपयोग करते हैं।
- यह गणितीय त्रुटियों से बचाता है। उदाहरण के लिए, ज़ोन खोजने के लिए टेक्स्ट सेंटर्स के बीच मिडपॉइंट्स का उपयोग करने से राउंडिंग बग्स (rounding bugs) आ जाते हैं। बाउंडिंग बॉक्स के वास्तविक ऊपरी किनारे का उपयोग करना ही एकमात्र सही तरीका है।
कठिन रास्ता ही सही रास्ता है।
आपको CTM स्टैक को समझना होगा। आपको मैट्रिक्स स्टेट्स को ट्रैक करना होगा और सबपाथ्स को वर्गीकृत करना होगा। इसमें महारत हासिल करने के लिए आपको PDF स्पेसिफिकेशन और सोर्स कोड पढ़ना होगा।
इसमें शुरुआत में अधिक प्रयास लगता है। लेकिन यह उपयोगकर्ता द्वारा अपलोड किए गए हर PDF के लिए काम करता है। पिक्सेल-आधारित टूल्स केवल आपके टेस्ट सुइट की कुछ ही फाइलों के लिए काम करते हैं।
एक वास्तविक एक्सट्रैक्टर बनाएं, डेमो नहीं।