Markdown तालिका के स्रोत को पढ़ने योग्य रखने के लिए, सेल में रिक्त स्थान जोड़ें और लंबे बदलावों के बाद हर कॉलम को फिर से संरेखित करें। Mac पर Obsidian इस्तेमाल करते हुए, मूल तालिका संपादक में बदलाव करें, फिर Source mode देखें। स्रोत में रिक्त स्थानों और रेंडर किए गए पाठ के संरेखण की अलग-अलग जाँच करनी होगी।

यह तरीका डेस्कटॉप नोट में छोटी Markdown तालिका का रखरखाव करने वाले व्यक्ति के लिए है: जैसे पठन सूची, स्टेशनरी की सूची या परियोजना की जाँच सूची। लक्ष्य है कि प्रविष्टियाँ बदलने पर वास्तविक पाठ को स्कैन करना आसान रहे और इच्छित रेंडरर में तालिका भी सही ढंग से काम करे।

Markdown तालिका का स्रोत पढ़ने योग्य किससे बनता है?

पढ़ने योग्य स्रोत तालिका में कॉलम की सीमाएँ स्पष्ट होती हैं, रिक्त स्थान लगातार एक जैसे होते हैं और हर पूरी पंक्ति एक ही लाइन में होती है। मोनोस्पेस फ़ॉन्ट में देखने पर इसके पाइप चिह्न लंबवत एक पंक्ति में आते हैं। GitHub का दस्तावेज़ स्पष्ट करता है कि सेल की चौड़ाई एक जैसी होना या स्रोत में कॉलम का पूरी तरह संरेखित होना ज़रूरी नहीं है। इसलिए यह संरेखण वैध तालिका की आवश्यकता के बजाय संपादन को सुविधाजनक बनाता है। तालिकाओं से जानकारी व्यवस्थित करना.

उदाहरण के लिए, यह काल्पनिक तालिका छोटी है, लेकिन किसी लंबे आइटम का नाम डालने पर इसे स्कैन करना कठिन हो जाता है:

| Item | Finish | Count |
| --- | --- | ---: |
| Pencil | Matte | 4 |
| Large sketchbook | Linen | 12 |

रिक्त स्थान जोड़ने से सादा पाठ देखते समय वही सामग्री जाँचना आसान हो जाता है:

| Item             | Finish | Count |
| ---------------- | ------ | ----: |
| Pencil           | Matte  |     4 |
| Large sketchbook | Linen  |    12 |

GFM में पाइप की सीमाओं और सेल की सामग्री के बीच के रिक्त स्थान हटा दिए जाते हैं। इसलिए रिक्त स्थान जोड़ने से रेंडर किए गए कॉलम की चौड़ाई तय नहीं होती। ----: में लगा कोलन रेंडर किए गए कॉलम को दाईं ओर संरेखित करता है; 4 से पहले के रिक्त स्थान केवल इस स्रोत उदाहरण को स्कैन करना आसान बनाते हैं। GitHub Flavored Markdown विनिर्देश, तालिकाएँ.

इन्हें दो अलग-अलग निर्णय मानें: स्रोत पढ़ने के लिए रिक्त स्थान चुनें और रेंडर किए गए पाठ को संरेखित करने के लिए सीमांकक पंक्ति में कोलन चुनें। अगर संपादक में केवल पाइप असमान दिख रहे हैं, तो कोलन बदलने से समस्या हल नहीं होगी।

तालिका किस रेंडरर में दिखाई जाएगी?

पाइप तालिकाएँ एक विस्तार हैं, core CommonMark की सुविधा नहीं। मौजूदा CommonMark विनिर्देश संस्करण 0.31.2 पर है, जबकि GitHub का प्रकाशित GFM विनिर्देश स्पष्ट रूप से तालिकाओं को CommonMark का विस्तार बताता है। केवल CommonMark-संगत बताए गए रेंडरर से पाइप तालिका का समर्थन मिलने की गारंटी नहीं होती। जाँचें कि उसमें तालिका का कोई विस्तार भी समर्थित है या नहीं। CommonMark विनिर्देश, GitHub Flavored Markdown विनिर्देश.

नोट को अलग-अलग अनुप्रयोगों में ले जाते समय ये अंतर मायने रखते हैं:

गंतव्य दस्तावेज़ में बताया गया व्यवहार व्यावहारिक चुनाव
Core CommonMark मूल विनिर्देश में पाइप तालिका का सिंटैक्स नहीं है पुष्टि करें कि तालिका का कोई विस्तार उपलब्ध है
GitHub उसके तालिका मार्गदर्शक में सीमांकक के हर सेल में कम से कम तीन हाइफ़न आवश्यक हैं --- या उससे अधिक इस्तेमाल करें
Obsidian उसका तालिका मार्गदर्शक कम से कम दो हाइफ़न स्वीकार करता है और स्रोत सेल के संरेखण की माँग नहीं करता GitHub को भी लक्ष्य बनाते हों तो तीन या अधिक इस्तेमाल करें

ऊपर हाइफ़न की आवश्यकताएँ संबंधित उत्पाद मार्गदर्शकों से ली गई हैं। इन दोनों गंतव्यों के लिए कम से कम तीन का इस्तेमाल एक सुविधाजनक साझा परिपाटी है; इससे सभी Markdown रेंडरर एक जैसे नहीं हो जाते। GitHub तालिका दस्तावेज़, Obsidian का उन्नत फ़ॉर्मैटिंग सिंटैक्स.

Obsidian और GitHub दोनों के लिए बनी तालिका में शुरुआत और अंत के पाइप इस्तेमाल करें, रिक्त स्थान जोड़ने के लिए सामान्य स्पेस रखें और तालिका से पहले तथा बाद में एक खाली पंक्ति रखें। GitHub का मार्गदर्शक तालिका से पहले खाली पंक्ति की माँग करता है; GFM विनिर्देश बताता है कि खाली पंक्ति तालिका को समाप्त करती है। दोनों सीमाएँ स्पष्ट रखने से स्रोत में तालिका पहचानना भी आसान होता है। GitHub तालिका दस्तावेज़, GFM तालिका की सीमाएँ.

Mac पर Obsidian में तालिका का रखरखाव कैसे करें

Obsidian उन लोगों के लिए एक उपयोगी तरीका देता है जो सेल को आसानी से संपादित करना और बाद में पढ़ने योग्य Markdown देखना चाहते हैं। उसके डेस्कटॉप संस्करण 1.5.8 के रिलीज़ नोट्स में टाइप करते समय अपने आप तालिका फ़ॉर्मैट करने की सुविधा शामिल की गई थी। नोट्स में खास तौर पर Source mode में साफ़ कॉलम दिखने की बात कही गई है। यह संपादक का दर्ज व्यवहार है, Markdown सिंटैक्स की सुविधा नहीं। Obsidian 1.5.8 डेस्कटॉप रिलीज़ नोट्स.

सामान्य नोट के लिए यह क्रम अपनाएँ:

  1. नोट को Live Preview में खोलें। ज़रूरत हो तो संपादक के स्टेटस आइकन से यह मोड चुनें।
  2. Insert Table कमांड का इस्तेमाल करके तालिका जोड़ें, या दायाँ क्लिक करके Insert → Table चुनें।
  3. तालिका संपादक में सेल की सामग्री दर्ज करें या संशोधित करें। पंक्तियाँ और कॉलम जोड़ने, हटाने, खिसकाने या क्रमबद्ध करने के लिए तालिका पर दायाँ क्लिक करें।
  4. स्टेटस आइकन से Source mode चुनें और बनी हुई Markdown तालिका देखें।
  5. दिखाई गई तालिका जाँचने के लिए Reading view पर जाएँ।

मोड के नियंत्रण दृश्य और संपादन मोड में और तालिका जोड़ने तथा कॉन्टेक्स्ट मेनू की कार्रवाइयाँ उन्नत फ़ॉर्मैटिंग सिंटैक्स में दर्ज हैं।

बार-बार मोड बदलने के लिए Toggle Live Preview/Source mode को हॉटकी दें। macOS पर Cmd+E से रीडिंग और संपादन दृश्य बदलते हैं; अगर आपका उद्देश्य खास तौर पर दोनों संपादन मोड के बीच जाना है, तो संबंधित मोड कमांड का इस्तेमाल करें। Obsidian दृश्य और संपादन मोड.

अगर Source mode में सीधे टाइप करने से रिक्त स्थान असमान हो जाते हैं, तो आगे के बदलावों के लिए मूल तालिका संपादक पर लौटें और बाद में स्रोत देखें। उद्धृत दस्तावेज़ अपने आप तालिका फ़ॉर्मैट करने और स्रोत को बारीकी से जाँचने की सुविधा का समर्थन करते हैं, लेकिन यह सार्वभौमिक गारंटी नहीं देते कि स्रोत में हर मनमाने बदलाव के बाद रिक्त स्थान तुरंत फिर से जोड़ दिए जाएँगे। छोटी तालिका में रिक्त स्थान असमान रहें तो नीचे दिया मैन्युअल तरीका आपको सीधा नियंत्रण देता है।

लंबे बदलाव के बाद स्रोत के कॉलम को फिर से कैसे संरेखित करें

एक सरल नियम अपनाएँ: हर स्रोत कॉलम की चौड़ाई उसकी सबसे लंबी मौजूदा प्रविष्टि, शीर्षक समेत, के लिए पर्याप्त रखें। उस कॉलम के बाकी सेल में रिक्त स्थान जोड़ें। कोई प्रविष्टि मौजूदा जगह से लंबी हो जाए तो चौड़ाई फिर से तय करें।

यहाँ केवल सादे ASCII पाठ का इस्तेमाल करके एक उदाहरण दिया गया है। इस तालिका से शुरू करें:

| Item   | Finish | Count |
| ------ | ------ | ----: |
| Pencil | Matte  |     4 |
| Folder | Linen  |    12 |

अब Folder को Large sketchbook से बदलें। नए आइटम में 16 वर्ण हैं, इसलिए पहले कॉलम में सामग्री के लिए 16 वर्णों की जगह चाहिए। हर सीमा वाले पाइप के ठीक अंदर एक रिक्त स्थान छोड़ें, फिर सामग्री क्षेत्र भरने के लिए उतने पीछे के रिक्त स्थान जोड़ें जितने आवश्यक हों:

  • Item में 4 वर्ण हैं, इसलिए उसके बाद 12 रिक्त स्थान जोड़ें, फिर सीमा वाला रिक्त स्थान रखें।
  • Pencil में 6 वर्ण हैं, इसलिए उसके बाद 10 रिक्त स्थान जोड़ें, फिर सीमा वाला रिक्त स्थान रखें।
  • Large sketchbook 16 वर्णों की जगह भरता है, इसलिए उसके बाद केवल सीमा वाला रिक्त स्थान चाहिए।
  • दृश्य मार्गदर्शक से मेल खाने के लिए पहले सीमांकक सेल में 16 हाइफ़न करें।

नतीजा वह रिक्त स्थानों वाली तालिका है जो पहले दिखाई गई है। केवल पहले कॉलम को चौड़ा करना पड़ा। बाकी कॉलम में उनके रिक्त स्थान और संरेखण चिह्न वैसे ही रहते हैं।

यह बताए गए ASCII उदाहरण को मैन्युअल रूप से फ़ॉर्मैट करने का तरीका है, सामान्य वर्ण-चौड़ाई का एल्गोरिदम नहीं। रोज़मर्रा के संपादन के लिए नतीजा मोनोस्पेस स्रोत प्रदर्शन में जाँचें। अगर सेल में काफ़ी इनलाइन फ़ॉर्मैटिंग हो, तो स्रोत की चौड़ाई लिखे गए वास्तविक वर्णों के आधार पर तय करें, जिनमें बैकटिक और तारक जैसे विराम चिह्न भी शामिल हैं।

कई बदलावों के बाद हर कीस्ट्रोक के बाद हर पंक्ति को ठीक करने के बजाय एक बार तालिका संरेखित करें। अगर प्रविष्टियाँ अक्सर अनुच्छेद जितनी लंबी हो जाती हैं, तो तालिका में केवल छोटा लेबल रखें और उसकी व्याख्या नीचे सामान्य गद्य में लिखें। इससे मूल जानकारी घटाए बिना रिक्त स्थानों के रखरखाव का काम कम होता है।

तालिका बिगड़ने पर क्या जाँचें?

रिक्त स्थान ठीक करने से पहले संरचना जाँचें। GFM के तहत शीर्षक और सीमांकक पंक्तियों में सेल की संख्या बराबर होनी चाहिए। बॉडी पंक्तियों में सेल कम हों तो खाली सेल जोड़ दिए जाते हैं; ज़्यादा हों तो अतिरिक्त सेल अनदेखे हो जाते हैं। इसलिए तालिका देखने में ठीक लग सकती है, जबकि रेंडर किए गए नतीजे से सामग्री गायब हो। GFM तालिका पार्सिंग के नियम.

बड़े बदलाव के बाद जाँच का यह क्रम अपनाएँ:

  1. शीर्षक और सीमांकक पंक्तियों की तुलना करें। हर शीर्षक के लिए एक संबंधित सीमांकक सेल रखें।
  2. बॉडी की हर पंक्ति देखें। कोई मान खाली हो तब भी सेल की इच्छित संख्या बनाए रखें।
  3. सामग्री में सीधे लिखे पाइप ढूँढ़ें। बिना एस्केप वाला पाइप दूसरी सीमा के रूप में समझा जा सकता है।
  4. पंक्तियों की सीमाएँ देखें। हर तालिका पंक्ति स्रोत की एक लाइन में रखें और तालिका के भीतर खाली पंक्तियों से बचें।
  5. गंतव्य का पूर्वावलोकन करें। दिखाई गई वैल्यू और तालिका का रूप, दोनों जाँचें।

सीधे लिखे पाइप के लिए GitHub उस वर्ण से पहले बैकस्लैश लगाने का निर्देश देता है। यह पूरा उदाहरण Blue | Green को एक ही सेल में रखता है:

| Item   | Options       |
| ------ | ------------- |
| Folder | Blue \| Green |

एस्केप संरचनात्मक है; बिना एस्केप वाले पाइप के आसपास और रिक्त स्थान जोड़ने से समस्या हल नहीं होगी। GitHub का सीधे लिखे पाइप का उदाहरण.

Obsidian तालिका में आंतरिक लिंक के एलियास के लिए इस्तेमाल किए गए पाइप को एस्केप करने की सुविधा भी बताता है। यह Obsidian-विशिष्ट सिंटैक्स का मामला है, इसलिए एस्केप किया गया एलियास अपने आप यह साबित नहीं करता कि GitHub पर लिंक उसी तरह काम करेगा। Obsidian तालिका फ़ॉर्मैटिंग मार्गदर्शन.

लंबे सेल के स्रोत को संकरा दिखाने के लिए बीच में Enter न दबाएँ। GFM तालिकाएँ इनलाइन सामग्री स्वीकार करती हैं और ब्लॉक-स्तर के तत्वों को बाहर रखती हैं; इनमें सेल के स्रोत को कई लाइनों में लिखने का कोई सामान्य फ़ॉर्मैट नहीं है। जब एक-लाइन वाली पंक्तियाँ अव्यावहारिक हो जाएँ, तो लंबी व्याख्याएँ तालिका से बाहर लिखें। GFM तालिका की सामग्री के नियम.

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

स्रोत