Myna - प्रतीक-केंद्रित प्रोग्रामिंग भाषाओं के लिए डिज़ाइन किया गया monospace फ़ॉन्ट

 (github.com/sayyadirfanali)
2 पॉइंट द्वारा GN⁺ 2025-11-09 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • यह एक monospace फ़ॉन्ट है जो प्रोग्रामिंग भाषाओं में अक्सर इस्तेमाल होने वाले प्रतीकों को अक्षरों के बराबर महत्व देता है, और code editor में दृश्य सामंजस्य को लक्ष्य बनाता है
  • ASCII प्रतीक-केंद्रित डिज़ाइन के ज़रिए ->, ::, =~ जैसे multi-character symbols के alignment को बेहतर बनाता है, और संतुलित मोटाई व स्पष्ट भेद प्रदान करता है
  • भाषा-विशिष्ट पठनीयता को ध्यान में रखते हुए Perl, Haskell, C आदि में symbols और operators के रूप को स्पष्ट रूप से दिखाता है
  • अभी यह single weight और non-ligature रूप में उपलब्ध है, तथा Linux के fontconfig·pango वातावरण में synthetic bold को support करता है
  • SIL Open Font License 1.1 के तहत वितरित किया गया है, इसलिए इसे स्वतंत्र रूप से उपयोग और संशोधित किया जा सकता है

Myna का परिचय

  • Myna एक monospace फ़ॉन्ट है जो प्रतीकों को first-class glyphs की तरह संभालता है, और प्रोग्रामिंग भाषाओं में प्रतीकों की visual consistency बढ़ाने पर केंद्रित है
    • यह ->, $, @, % जैसे प्रतीकों के उन असहज दिखने वाले रूपों की समस्या को हल करता है जो पारंपरिक फ़ॉन्ट्स में अक्सर दिखते हैं
    • ASCII की सरलता बनाए रखते हुए Ligature के aesthetic effect की नकल करता है

प्रमुख विशेषताएँ

  • Symbol-First Design: प्रोग्रामिंग भाषाओं में व्यापक रूप से उपयोग होने वाले ASCII प्रतीकों को केंद्र में रखकर डिज़ाइन
  • alignment की सटीकता: ->, >>=, :: जैसे multi-character symbols की alignment सटीकता बढ़ाकर code readability में सुधार
  • संतुलित मोटाई (Weight): प्रतीकों और अक्षरों के बीच contrast को सामंजस्यपूर्ण बनाए रखता है
  • न्यूनतम रूप: quotation marks और comma जैसी चीज़ों को geometric रूप में सरल किया गया है
  • स्पष्ट भेदयोग्यता: 1, l, I, |, 0, O, o जैसे भ्रमित करने वाले characters के बीच भेद को मजबूत किया गया है
  • भाषा-संवेदी डिज़ाइन: Perl के Sigil, Haskell के operators, और C के symbolic expressions को अलग-अलग स्पष्ट रूप से दर्शाता है

विकास पृष्ठभूमि और वर्तमान स्थिति

  • मौजूदा monospace फ़ॉन्ट्स के सूक्ष्म glyph details से असंतुष्ट होकर इसे सीधे स्वयं बनाया गया
  • डेवलपर ने इसे पेशेवर और व्यक्तिगत प्रोजेक्ट्स में लंबे समय तक इस्तेमाल करने के बाद सार्वजनिक किया
  • वर्तमान में यह single weight, non-Ligature version के रूप में उपलब्ध है, और भविष्य में मांग के अनुसार इसका विस्तार संभव है
    • Linux वातावरण में fontconfig और pango के माध्यम से synthetic bold support
  • SIL Open Font License 1.1 लागू
  • शुरुआती संस्करण Hera (Source Code Pro आधारित customization) से शुरू हुआ
  • Fira Mono, Inconsolata, Plex Mono, Office Code Pro, Anonymous Pro जैसे विभिन्न फ़ॉन्ट्स की खूबियों से प्रेरित होकर इसे आगे विकसित किया गया

आगे की योजना

  • terminal और editor दोनों में व्यापक उपयोग को लक्ष्य बनाया गया है
  • कुछ non-ASCII glyphs (जैसे geometric और mathematical symbols) शामिल हैं
  • community feedback के आधार पर glyph विस्तार और feature additions की योजना है

संबंधित पढ़ाई

2 टिप्पणियां

 
bobross0 2025-11-11

मैं JetBrains फ़ॉन्ट इस्तेमाल करता हूँ, इसलिए यह दिलचस्प लग रहा है।
 
GN⁺ 2025-11-09
Hacker News की राय

  • मैंने हाल ही में Iosevka (उच्चारण Joseph) पर स्विच किया, और वजह यही सादगी थी
    Iosevka GitHub लिंक
    मज़ेदार बात यह है कि इस फ़ॉन्ट का source code इतना साफ़-सुथरा है कि उसे सच में पढ़ा जा सकता है

    • Iosevka वाकई बहुत खूबसूरत फ़ॉन्ट है। Myna का condensed look भी दरअसल Iosevka से प्रेरित था
      इसका पिछला संस्करण Hera, Source Code Pro को customize करके बनाया गया non-condensed संस्करण था
    • Iosevka में custom build का सपोर्ट है, इसलिए अलग-अलग glyph variants और ligature options चुने जा सकते हैं। यह काफ़ी प्रभावशाली है
    • मुझे अभी पता चला कि Iosevka, Joseph का एक रूप है। मैं इसे सालों से इस्तेमाल कर रहा हूँ, लेकिन इसका उच्चारण तक नहीं जानता था। जबकि README में यह लिखा भी था
    • Pragmasevka भी एक बार आज़माने लायक है। मैं Iosevka से उसी पर गया था, और readability थोड़ी बेहतर लगी
    • मैं Iosevka Orw इस्तेमाल करता हूँ। इसकी चौड़ाई standard Iosevka और सामान्य monospace के बीच की है, इसलिए यह आदर्श लगती है

  • सच कहूँ तो “symbol-heavy भाषा के लिए फ़ॉन्ट” वाली बात मुझे ठीक से समझ नहीं आई। symbols तो काफ़ी सामान्य दिखते हैं। क्या बस spacing थोड़ा ज़्यादा है?

    • GitHub पेज पर पहला focus item “Near-Perfect Alignment” है। यानी ->, >>=, :: जैसे multi-character symbols एकदम सही aligned दिखते हैं
    • मैं डिज़ाइनर हूँ। यहाँ symbol-heavy भाषा से मतलब Perl या Haskell जैसी symbols का ज़्यादा उपयोग करने वाली भाषाएँ हैं। मैं ऐसा फ़ॉन्ट बनाना चाहता था जिसमें ligatures के बिना भी alignment साफ़ रहे
    • डिज़ाइन का फ़र्क समझाने के लिए असली comparison examples चाहिए। comparison images न होने से भ्रम होना स्वाभाविक है

  • फ़ॉन्ट काफ़ी सुंदर है। बस sample में emdash (—) character शायद नहीं दिख रहा। मैं Markdown बहुत इस्तेमाल करता हूँ, और कई programming fonts इस character को ठीक से नहीं दिखाते
    screenshot दूसरी fonts की तुलना में काफ़ी मूल्यांकन में मददगार है

    • सही बात है, em-dash सिर्फ़ एक character नहीं है। मैं इसे अच्छी writing का मुख्य तत्व मानता हूँ (आधा मज़ाक, आधा सच)
    • feedback के लिए धन्यवाद। इस फ़ॉन्ट में en-dash को चौड़ा बनाया गया है, इसलिए em-dash से फर्क करना मुश्किल है। मैं em-dash लगभग कभी इस्तेमाल नहीं करता, इसलिए मुझे यह ज़रूरत महसूस नहीं हुई
      फिर भी अगर इसकी मांग है, तो मैं सुधार पर विचार करूँगा

  • कई दूसरे fonts की तरह इस फ़ॉन्ट में भी vertical arrows (↑↓) का alignment अटपटा लगता है
    ^ character मूल रूप से typewriter दौर के circumflex accent के लिए था। इसलिए इसकी ऊँचाई असममित है। मुझे लगता है कि caret का निचला हिस्सा v के साथ symmetric होता तो बेहतर होता

    • मैंने caret को ऊपर-नीचे के arrows की तरह इस्तेमाल होते कभी नहीं देखा। मुझे नहीं लगता symmetry यहाँ ज़रूरी है
    • caret को vertical arrow की तरह इस्तेमाल करना व्यावहारिक नहीं है। उसे दो लाइनों में टाइप करना पड़ेगा। यह भी सोच रहा हूँ कि क्या कोई भाषा सच में ऐसा करती है
    • क्या आप line-breaking ligature बनाने की सोच रहे हैं? सीधे Unicode का ↑ इस्तेमाल करना बेहतर नहीं होगा?
    • मैं डिज़ाइनर हूँ। ऐसे combinations detect करना मुश्किल है, और caret मूल रूप से एक operator symbol है, इसलिए उसका programmatic meaning नहीं टूटना चाहिए। v से तुलना करना भी ठीक नहीं है
    • caret की ऐतिहासिक वजह अब उतनी मायने नहीं रखती। आज सब लोग उसके मौजूदा आकार के आदी हैं। ऐसे special case के लिए फ़ॉन्ट बदलना उल्टा भ्रम पैदा करेगा
      फ़ॉन्ट को predictable shapes बनाए रखने चाहिए

  • “-> तीर जैसा नहीं दिखता” वाली शिकायत का असली हल यह है कि ←→ जैसे असली arrows इस्तेमाल किए जाएँ। उम्मीद है कि कभी languages बेहतर typography quality को support करेंगी

    • मैं डिज़ाइनर हूँ। elegance और consistency दोनों एक साथ पाना संभव नहीं है। हम ligatures के बिना भी ASCII-based code को अच्छा दिखाने की कोशिश कर रहे हैं
    • ligatures मौजूद हैं

  • JuliaMono Julia भाषा के पूर्ण Unicode support के लिए बनाया गया फ़ॉन्ट है

    • लिंक के लिए धन्यवाद। glyphs काफ़ी समृद्ध लग रहे हैं। फ़ॉन्ट की सीमाएँ पार करने के लिए JuliaMono2, 3, 4 जैसी fallback system का उपयोग भी दिलचस्प है
    • मैं डिज़ाइनर हूँ। मैं मुख्य रूप से ASCII range पर काम करता हूँ, लेकिन Myna में JuliaMono को auxiliary font की तरह सेट करके Unicode coverage बढ़ाई जा सकती है

  • फ़ॉन्ट सुंदर है, लेकिन ऊपर दिख रहे “Lorem” में अक्षरों के बीच spacing कुछ ज़्यादा लग रही है, इसलिए kerning थोड़ा अजीब लगता है। व्यक्तिगत रूप से यह मुझे खटकता है

    • मैं डिज़ाइनर हूँ। रोज़ इस्तेमाल करते-करते मैं इसकी कमियों के प्रति सुस्त हो गया हूँ। फिर भी यह point सही है। अगले version में kerning fix पर विचार करूँगा। अगर कोई ठोस example हो तो issue दर्ज करें

  • Ligatures डेवलपर्स के बीच काफ़ी विवादास्पद विषय हैं
    कुछ लोगों को लगता है कि इससे code ज़्यादा सुंदर और पढ़ने में आसान हो जाता है, जबकि कुछ का मानना है कि “symbols छिपाना बेकार या बेईमानी” है
    और कुछ लोग कहते हैं कि “अगर languages Unicode को ठीक से support करतीं, तो ligatures की ज़रूरत ही नहीं पड़ती”
    आख़िरकार इस project ने तीनों पक्षों को एक साथ छेड़ दिया, और शायद इसी वजह से यह और दिलचस्प लग रहा है। मैंने GitHub पर star दे दिया

    • ज़्यादातर editors में ligatures optional होते हैं, इसलिए कोई भी बाहर नहीं रह जाता

  • लगता है symbols, lowercase letters के बगल में कुछ ज़्यादा ऊँचाई पर रखे गए हैं। शायद brackets के alignment से match कराने की कोशिश का असर है। visual balance थोड़ा कमज़ोर लगता है

    • मैं डिज़ाइनर हूँ। सामान्य fonts text-केंद्रित होते हैं, इसलिए वे पारंपरिक alignment का पालन करते हैं, लेकिन code text नहीं है
      परंपरा तोड़ने से readability बेहतर हो सकती है। hyphen को > के साथ align करके arrow shape बनाने के लिए डिज़ाइन किया गया है

  • Myna UI नाम का एक icon font पहले से मौजूद है। इससे भ्रम हो सकता है

    • मैं डिज़ाइनर हूँ। बताने के लिए धन्यवाद। फिर भी मुझे नहीं लगता कि इससे कोई बड़ा भ्रम होगा