Markdown फ़ाइलें: नियमों वाला प्लेन टेक्स्ट, और ये नियम एक नहीं, कई हैं

उलझन यह है कि Markdown एक नहीं है। 2004 के मूल इम्प्लीमेंटेशन ने बहुत-सी स्थितियाँ अपरिभाषित छोड़ दी थीं, इसलिए हर रेंडरर ने उन्हें अपने ढंग से तय किया; CommonMark इन्हीं अस्पष्टताओं को पक्का करने के लिए बना, और GitHub Flavored Markdown उसके ऊपर टेबल, टास्क लिस्ट और स्ट्राइकथ्रू जोड़ता है। यह हालत आधिकारिक रूप से भी मानी गई है: मार्च 2016 में जब RFC 7763 में text/markdown को मीडिया टाइप के रूप में रजिस्टर किया गया, तो उसमें एक variant पैरामीटर रखा गया, ठीक इसलिए कि किसी फ़ाइल को Markdown कहने से यह पता नहीं चलता कि वह कौन-सा Markdown है। यह साइट UTF-8 वाला text/markdown बनाती है, और सिर्फ़ वही ढाँचे इस्तेमाल करती है जिन पर हर डायलेक्ट सहमत है — हैश वाली हेडिंग, ख़ाली लाइन से अलग पैराग्राफ़, हाइफ़न वाले बुलेट और हॉरिज़ॉन्टल रूल।

PDF को Markdown में बदलने का मतलब है ऐसा ढाँचा गढ़ना जो PDF में कभी था ही नहीं। PDF हेडिंग नहीं, टाइप साइज़ दर्ज करती है, इसलिए पेज के साइज़ों की रैंकिंग की जाती है और सबसे बड़े छह साइज़ हेडिंग के छह लेवल बन जाते हैं; जो लाइन बस बॉडी टेक्स्ट से बड़ी है, वह हेडिंग बन जाती है, चाहे लेखक ने उसे हेडिंग माना हो या नहीं। लिस्ट के साथ हालत और ख़राब है: PDF में लिस्ट जैसी कोई चीज़ होती ही नहीं, और जो बुलेट आपको दिखता है वह सचमुच टेक्स्ट का एक कैरेक्टर है, इसलिए लिस्ट बचाने का एक ही तरीक़ा है — उस कैरेक्टर को पहचानकर हाइफ़न में बदलना। नंबर वाले आइटम को ऐसी किसी मदद की ज़रूरत नहीं — "1. " और "1) " पहले से ही Markdown हैं, और पहले से ही लिस्ट के रूप में लिखे गए हैं।

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