Myna: Monospace typeface designed for symbol-heavy programming languages
Design goals and scope
- Font is positioned as an ASCII-first, monospace typeface tuned for symbol‑heavy languages (Perl, Haskell, etc.).
- Key idea: multi‑character operators like
->,>>=,::,<$>, etc. should look visually cohesive without using ligatures, so it works in terminals and editors that don’t support them. - Designer emphasizes adjusted angles, weights, and spacing of operators (
<,>,-,~, backtick, colon) to better match real-world code usage, rather than traditional text typography. - Font is condensed horizontally to show more code per line; derived from a customized Source Code Pro with influences from other mono fonts and built in FontForge.
Symbol alignment and readability
- Some commenters say they can’t see what’s special about the symbols and request side‑by‑side comparisons with other monospaced fonts.
- A comparison table was later added, which helps some readers see the differences and motivates trying it for Perl/Haskell.
- Others feel aligning symbols to brackets and caps makes dashes, colons, and angle brackets look too high next to lowercase letters, especially in HTML/XML/C++ generics.
Glyph choices: mixed reactions
- Curly braces are the most polarizing: some find the “S‑shaped” style noisy and distracting; others like how clearly they differ from parentheses and how they match how they’re handwritten. A “disambiguated braces” variant is suggested.
- Multiple comments criticize
lvs1similarity; the designer is open to a variant that changesl. - Kerning in text samples (e.g. “Lorem”) bothers some; designer prioritised strict centering over nuanced kerning.
- Caret
^height and vertical “ASCII arrows” (^/v+|) trigger a long subthread; many consider that use extremely niche and prefer preserving the traditional elevated caret. - Em dash is acknowledged as poorly distinguished from dash due to monospace constraints.
Ligatures, Unicode, and arrows
- Font intentionally avoids programming ligatures; designer and some users prefer explicit ASCII sequences for portability and clarity.
- Long debate over whether
->should just be a Unicode arrow:- Pro‑Unicode side: languages and tools increasingly support Unicode identifiers and symbols; editor macros or keybindings can insert arrows directly.
- Anti‑Unicode side: typing such symbols is awkward on standard keyboards; ligatures and Unicode arrows can break search, selection, and semantics in languages where
->and=>are distinct tokens.
- Several note that Unicode and full‑width glyphs don’t fit well with monospace constraints; Myna covers Latin extended and a subset of Unicode but is not trying to be a Julia‑style full‑Unicode code font.
Comparisons and usage preferences
- Many compare Myna to Iosevka, Ubuntu Mono, JetBrains Mono, Intel One Mono, Cascadia Code, Go Mono, IBM Plex Mono, JuliaMono, and others.
- Some love its compactness and aesthetics; others find it less legible than their current choices.
- Discussion branches into broader topics: monospaced vs proportional fonts for coding, font size and high‑DPI displays, and how much font choice matters versus actual coding.