PDF से Markdown

कॉलम गटर खोजकर पहचाने जाते हैं: खड़ी पट्टियाँ जिन्हें कोई पंक्ति नहीं काटती और जो टेक्स्ट की पट्टी के बड़े हिस्से तक फैली रहती हैं। चौड़ाई अकेले कुछ साबित नहीं करती। एक कॉलम वाली रिपोर्ट में दो खानों की एक ग्रिड हो, तो पूरे पन्ने पर छोटे-छोटे अंतराल बिखरे मिलते हैं, और चौड़ाई पर टिकी कोई सीमा उनमें से हर एक को कॉलम की सीमा कह देगी; इसलिए बात यह तय करती है कि असली गटर वह है जिसका आदर हर मुख्य पंक्ति करती है, और फ़ैसला दोनों किनारों पर ढकी ऊँचाई का हिस्सा करता है। दोहराते बैनर अंकों को हटाकर मिलाए जाते हैं, क्योंकि "Page 3 of 40" और "Page 4 of 40" एक ही फ़ुटर हैं। दस में से छह पन्ने। उससे कम पर पंक्ति बनी रहती है। ग्रिड सबसे ईमानदार हिस्सा हैं। तीन या उससे अधिक लगातार पंक्तियाँ, जिनके टुकड़े लगभग एक ही x स्थिति से शुरू होते हैं, एक तालिका बनाती हैं; गद्य ऐसा नहीं करता। सीमाएँ टाइप के आकार के अनुपात में एक सहनशीलता के साथ गुच्छे बनाती हैं, और हर तालिका विश्वास का एक आँकड़ा साथ लेकर निकलती है: उसकी उन पंक्तियों का हिस्सा जो इन सीमाओं का सचमुच आदर करती हैं। 0.6 से नीचे भी वह लिखी जाती है, उस पर निशान लगता है और चेतावनी उठाई जाती है। खाने गढ़ना इससे बुरा होता। तस्वीरें मूल स्ट्रीम से निकाली नहीं जातीं, बल्कि रेंडर किए गए पन्ने से 216 dpi पर काटी जाती हैं। इसमें मूल रिज़ॉल्यूशन की कीमत लगती है, और बदले में PDF जो भी एन्कोडिंग ढो सकता है, उन सबके पार टिकाव मिलता है। बंडल में JSONL की हर पंक्ति पर एक खंड होता है, हर एक के साथ उसका शीर्षक-पथ, पन्ने, टोकन का अनुमान और SHA-256, और साथ में एक नक्शा जो बताता है कि कौन सा ब्लॉक किस पन्ने से आया। खंड ब्लॉक की सीमाओं पर टूटते हैं। हमेशा। टोकन की गिनती पूरी करने के लिए किसी पैराग्राफ़ को वाक्य के बीच से काटने पर ऐसे टुकड़े बनते हैं जिन्हें कोई अकेले नहीं पढ़ता, और इससे पुनर्प्राप्ति का पूरा मकसद ही मर जाता है।