Markdown से PDF और वापस: रूपांतरण क्या बचाता है
Markdown↔PDF शीर्षक, सूचियाँ और सरल तालिकाएँ पिक्सेल से बेहतर बचाता है। असली फ़ॉन्ट, पेजिनेशन और लेआउट बिना-हानि वापसी यात्रा में नहीं टिकते।
Markdown और PDF अलग-अलग अनुबंधों के लिए बने हैं। Markdown संस्करण-नियंत्रण-अनुकूल संरचना है। PDF स्थिर पेज-विवरण है। एक तरफ़ बदलकर वापस लौटना उपयोगी है; यह बिना-हानि संग्रह-चक्र नहीं।
Markdown से PDF: संरचना पेज बनती है
Markdown to PDF (POST /api/v1/convert/markdown/pdf) .md फ़ाइल या Markdown रखने वाला ZIP लेता है। Markdown या ZIP से अलग अपलोड अस्वीकार होते हैं। सादे .md इनपुट के लिए UTF-8 ज़रूरी है। पाइपलाइन Markdown को HTML में रेंडर करती है, तालिकाएँ, स्ट्राइकथ्रू और टास्क सूचियाँ चालू रखते हुए, उसे छपाई-केंद्रित CSS में लपेटती है (बहु-लिपि फ़ॉन्ट स्टैक सहित, और अरबी पहचाने जाने पर RTL), फिर WeasyPrint से PDF छापती है।
आगे की दिशा में आम तौर पर यह बचता है:
- शीर्षक, अनुच्छेद, सूचियाँ और सरल Markdown तालिकाएँ
- वह बहु-लिपि टेक्स्ट जिसे HTML पथ बिछा सकता है (CJK, लातिनी और छपाई CSS के दायरे वाली अन्य लिपियाँ)
- डॉक्स-ऐज़-कोड कार्यप्रवाहों के लिए छापने-योग्य, साझा करने-योग्य PDF
जो नहीं बचता:
- हर व्यूअर में आपके एडिटर के थीम फ़ॉन्ट की गारंटीशुदा समानता
.mdफ़ाइल से स्क्रीन के असली पंक्ति-विराम- ऐसी इंटरैक्टिव Markdown सुविधाएँ जिनका PDF में कोई समतुल्य नहीं (जीवित चेकबॉक्स, संकुचित होने वाले खंड, विकि लिंक)
ZIP इनपुट इसलिए है कि Markdown के साथ वे संपत्तियाँ बाँधी जा सकें जिन्हें HTML पथ दस्तावेज़ के पास हल कर सकता है। इसे पैकेजिंग की सुविधा मानें, इस गारंटी के रूप में नहीं कि हर सापेक्ष इमेज या CSS संदर्भ हर व्यूअर में एक जैसा दिखेगा।
PDF से Markdown: टेक्स्ट परत अंदर, Markdown बाहर
PDF to Markdown (POST /api/v1/convert/pdf/markdown) pdf-inspector के ज़रिए पाठ्य सामग्री को Markdown में निकालता है। प्रतिक्रिया text/markdown होती है, जो .md फ़ाइल के रूप में डाउनलोड होती है। साफ़ टेक्स्ट परत वाली बॉर्न-डिजिटल PDF सबसे अच्छी बदलती हैं। बिना टेक्स्ट परत वाले स्कैन पेज खाली या बेकार Markdown देते हैं जब तक आप पहले OCR न करें—और इस साइट पर OCR भी Markdown लौटाता है, खोजने-योग्य PDF परत नहीं।
अपेक्षा रखें:
- शीर्षक और अनुच्छेद, जब फ़ॉन्ट-आकार के अनुमान ठीक चलें (फिर भी
#स्तर हाथ से दोबारा क्रमांकित करने पड़ सकते हैं) - तालिकाएँ Markdown तालिकाओं के रूप में, जब पहचान काम करे; बहु-स्तंभ लेआउट अलग पठन-क्रम में सीधे हो सकते हैं
- हर पेज पर दोहराए जाने वाले चल शीर्षक और पाद (बाद में काटें)
- इमेज और चित्र-रूप समीकरण अपने-आप स्थानीय संपत्ति या LaTeX नहीं बनते
शीर्षक-अनुमानों के बिना सादा गद्य चाहिए, तो PDF to Text ज़्यादा सपाट निष्कर्षण है। तालिका-आकार के निर्यात जो HTTP 204 लौटाते हैं, का अर्थ है कि कोई स्तंभ-खंड नहीं मिला; खाली तालिका निर्यात (204) देखें।
वापसी यात्रा असल में क्या साबित करती है
| ठीक-ठाक बचता है | आम तौर पर नहीं |
|---|---|
| शब्द, शीर्षक-पदानुक्रम, सूची संरचना | पिक्सेल-सटीक पेज ज्यामिति |
| सरल तालिकाएँ टेक्स्ट के रूप में | असली फ़ॉन्ट और अक्षर-दूरी |
| Git या एजेंट के लिए काम का मसौदा | छपाई-समान पेजिनेशन |
दो बार वापसी यात्रा करने पर खिसकाव बढ़ेगा। Markdown→PDF WeasyPrint से दोबारा बहता है; PDF→Markdown निष्कर्षण-अनुमानों से संरचना दोबारा बनाता है। कोई चरण दूसरे प्रारूप के लेआउट मॉडल का बिना-हानि मध्यवर्ती नहीं रखता।
एक कानूनी दिशा चुनें
अगर छपाई-लेआउट ही अभिलेख-प्रणाली चाहिए, तो PDF रखें और Markdown को निर्यात या एजेंट-फ़ीड मानें। अगर अंतर-दृश्य, कोड समीक्षा और एजेंट-ग्रहण चाहिए, तो Markdown को प्राथमिकता दें और PDF को प्रकाशन-चरण मानें। दोनों को समान “सत्य-स्रोत” मानकर न रखें और न अपेक्षा करें कि संपादन के बाद वे एक जैसे रहेंगे।
व्यावहारिक डॉक्स-ऐज़-कोड चक्र: Git में Markdown संपादित करें → साझा करने-योग्य नतीजे के लिए Markdown to PDF → PDF→Markdown→PDF को रोज़ की आदत न बनाएँ। PDF→Markdown तब इस्तेमाल करें जब कोई बॉर्न-डिजिटल PDF विरासत में मिले और एजेंट के लिए टेक्स्ट चाहिए; फिर उस Markdown को नया मसौदा मानें, मूल पेजिनेशन की गारंटी नहीं।
एन्क्रिप्टेड फ़ाइलों को किसी भी रूपांतरण से पहले अधिकृत Unlock चाहिए। खराब फ़ाइलें जो पार्स नहीं होतीं, उन्हें पहले Get Info / Repair से गुज़ारें। वही एंडपॉइंट HTTP पर इस्तेमाल करने के लिए Developers देखें।