Myna – Monospace-Schriftart für symbolorientierte Programmiersprachen

 (github.com/sayyadirfanali)
2 Punkte von GN⁺ 2025-11-09 | 2 Kommentare | Auf WhatsApp teilen
  • Eine Monospace-Schriftart, die in Programmiersprachen häufig verwendete Symbole gleichwertig mit dem Alphabet behandelt, mit dem Ziel visueller Harmonie im Code-Editor
  • Durch ein ASCII-symbolzentriertes Design wird die Ausrichtung mehrteiliger Symbole wie ->, ::, =~ verbessert und zugleich ausgewogene Strichstärken sowie klare Unterscheidbarkeit geboten
  • Unter Berücksichtigung der sprachspezifischen Lesbarkeit werden Formen von Symbolen und Operatoren in Perl, Haskell, C usw. klar dargestellt
  • Derzeit wird sie in einer einzigen Strichstärke und ohne Ligaturen angeboten; in Linux-Umgebungen wird synthetisches Fett über fontconfig·pango unterstützt
  • Wird unter der SIL Open Font License 1.1 veröffentlicht und kann frei genutzt und angepasst werden

Überblick über Myna

  • Myna ist eine Monospace-Schriftart, die Symbole als Glyphen erster Klasse behandelt, mit Fokus auf einer höheren visuellen Konsistenz von Symbolen in Programmiersprachen
    • Behebt das Problem, dass Symbole wie ->, $, @, % in bestehenden Schriftarten oft unnatürlich wirken
    • Bewahrt die Schlichtheit von ASCII und ahmt zugleich den ästhetischen Effekt von Ligaturen nach

Hauptmerkmale

  • Symbol-First Design: Entworfen mit Fokus auf ASCII-Symbole, die in Programmiersprachen allgemein verwendet werden
  • Präzise Ausrichtung: Verbessert die Ausrichtungsgenauigkeit mehrteiliger Symbole wie ->, >>=, :: und erhöht so die Lesbarkeit von Code
  • Ausgewogene Strichstärke (Weight): Der Kontrast zwischen Symbolen und Buchstaben bleibt harmonisch
  • Minimale Formensprache: Anführungszeichen, Kommas usw. sind zu geometrischen Formen vereinfacht
  • Klare Unterscheidbarkeit: Verwechslungsanfällige Zeichen wie 1, l, I, |, 0, O, o lassen sich deutlicher unterscheiden
  • Sprachbewusstes Design: Perl-Sigils, Haskell-Operatoren und die Symbolnotation in C werden jeweils klar dargestellt

Entwicklungshintergrund und aktueller Stand

  • Die Schriftart wurde direkt erstellt, weil die Entwickler mit den Details der Glyphen bestehender Monospace-Schriften unzufrieden waren
  • Wurde veröffentlicht, nachdem der Entwickler sie über längere Zeit in beruflichen und privaten Projekten verwendet hatte
  • Derzeit als Version mit nur einer Strichstärke und ohne Ligaturen verfügbar; je nach Nachfrage sind Erweiterungen möglich
    • Unterstützung für synthetisches Fett über fontconfig und pango in Linux-Umgebungen
  • Veröffentlicht unter der SIL Open Font License 1.1
  • Die erste Version begann mit Hera (einer auf Source Code Pro basierenden Anpassung)
  • Wurde unter Bezug auf die Stärken verschiedener Schriftarten wie Fira Mono, Inconsolata, Plex Mono, Office Code Pro, Anonymous Pro weiterentwickelt

Weitere Pläne

  • Ziel ist der universelle Einsatz in Terminals und Editoren
  • Enthält teilweise auch nicht-ASCII-Glyphen (geometrische und mathematische Symbole usw.)
  • Je nach Community-Feedback sind Glyphenerweiterungen und zusätzliche Funktionen geplant

Verwandte Beiträge

2 Kommentare

 
bobross0 2025-11-11

Ich nutze die JetBrains-Schriftart, daher finde ich das interessant.
 
GN⁺ 2025-11-09
Hacker-News-Kommentare

  • Ich bin vor Kurzem genau wegen dieser Schlichtheit zu Iosevka gewechselt (ausgesprochen Joseph).
    Iosevka GitHub-Link
    Interessant ist, dass der Quellcode dieser Schrift so klar strukturiert ist, dass man ihn tatsächlich lesen kann.

    • Iosevka ist wirklich eine wunderschöne Schrift. Auch der komprimierte Look von Myna wurde tatsächlich von Iosevka inspiriert.
      Die frühere Version, Hera, war eine nicht komprimierte Variante auf Basis einer angepassten Source Code Pro.
    • Iosevka unterstützt von Haus aus Custom Builds, wodurch verschiedene Glyphenvarianten und die Auswahl von Ligaturen möglich sind. Ziemlich beeindruckend.
    • Ich habe erst jetzt erfahren, dass Iosevka eine Variante von Joseph ist. Ich nutze sie seit Jahren und kannte nicht einmal die Aussprache. Dabei stand es sogar in der README.
    • Pragmasevka ist ebenfalls einen Versuch wert. Ich bin von Iosevka umgestiegen und finde die Lesbarkeit etwas besser.
    • Ich nutze Iosevka Orw. Die Breite liegt ideal zwischen Standard-Iosevka und einer normalen Monospace-Schrift.

  • Ehrlich gesagt verstehe ich die Beschreibung „Schrift für symbol-lastige Sprachen“ nicht ganz. Die Symbole sehen ziemlich gewöhnlich aus. Vielleicht ist nur der Abstand etwas größer?

    • Der erste Fokuspunkt auf der GitHub-Seite ist „Near-Perfect Alignment“. Das heißt, dass mehrteilige Symbole wie ->, >>= oder :: perfekt ausgerichtet sind.
    • Ich bin der Designer. Mit symbol-lastigen Sprachen sind hier Sprachen mit vielen Symbolen wie Perl oder Haskell gemeint. Ich wollte eine Schrift machen, die auch ohne Ligaturen sauber ausgerichtet wirkt.
    • Um Designunterschiede zu erklären, braucht man echte Vergleichsbeispiele. Ohne Vergleichsbilder ist Verwirrung fast unvermeidlich.

  • Die Schrift sieht ziemlich schön aus. Allerdings scheint im Beispiel das Zeichen emdash (—) zu fehlen. Ich nutze oft Markdown, und viele Programmierschriften stellen dieses Zeichen falsch dar.
    Der Screenshot hilft bei der Beurteilung deutlich mehr als bei anderen Schriften.

    • Stimmt, der em-dash ist mehr als nur ein einfaches Zeichen. Ich halte ihn für ein zentrales Element guten Schreibens (halb im Scherz, halb ernst).
    • Danke für das Feedback. In dieser Schrift ist der en-dash breit gestaltet, wodurch er sich schwer vom em-dash unterscheiden lässt. Ich verwende em-dashes fast nie und hatte deshalb keinen Bedarf nach einer klaren Unterscheidung.
      Wenn es gewünscht ist, prüfe ich aber eine Verbesserung.

  • Wie bei vielen Schriften wirkt auch hier die Ausrichtung der vertikalen Pfeile (↑↓) etwas unnatürlich.
    Das Zeichen ^ war ursprünglich für den Circumflex-Akzent aus der Schreibmaschinenzeit gedacht. Deshalb ist seine Höhe asymmetrisch. Ich fände es gut, wenn der untere Teil des Caret symmetrisch zu v wäre.

    • Ich habe noch nie gesehen, dass jemand ein Caret als Pfeil nach oben oder unten verwendet. Ich glaube nicht, dass hier zwingend Symmetrie nötig ist.
    • Ein Caret als vertikalen Pfeil zu verwenden ist unrealistisch. Man müsste ihn über zwei Zeilen hinweg eingeben. Ich frage mich, ob es überhaupt eine Sprache gibt, die so etwas benutzt.
    • Versuchst du vielleicht, eine Ligatur über einen Zeilenumbruch hinweg zu erzeugen? Wäre es nicht besser, einfach das Unicode-Zeichen ↑ zu verwenden?
    • Ich bin der Designer. Solche Kombinationen sind schwer zu erkennen, und das Caret ist ursprünglich ein Operatorzeichen, daher darf seine programmatische Bedeutung nicht verwässert werden. Der Vergleich mit v ist nicht fair.
    • Die historische Herkunft des Caret ist nicht wichtig. Heute sind alle an diese Form gewöhnt. Wenn man die Schrift wegen solcher Spezialfälle verändert, stiftet das eher Verwirrung.
      Eine Schrift sollte vorhersehbare Formen beibehalten.

  • Zur Beschwerde „-> sieht nicht wie ein Pfeil aus“: Die echte Lösung ist, tatsächliche Pfeile wie ←→ zu verwenden. Hoffentlich unterstützen Sprachen irgendwann eine bessere typografische Qualität.

    • Ich bin der Designer. Eleganz und Konsistenz gleichzeitig zu erreichen ist unmöglich. Wir versuchen, ASCII-basierten Code auch ohne Ligaturen gut aussehen zu lassen.
    • Ligaturen gibt es.

  • JuliaMono ist eine Schrift, die für die vollständige Unicode-Unterstützung der Sprache Julia entworfen wurde.

    • Danke für den Link. Die Schrift scheint sehr viele Glyphen zu haben. Interessant ist auch, dass ein Fallback-System wie JuliaMono2, 3 und 4 genutzt wird, um die Grenzen einer einzelnen Schrift zu überwinden.
    • Ich bin der Designer. Ich arbeite hauptsächlich im ASCII-Bereich, aber wenn man JuliaMono in Myna als Sekundärschrift setzt, kann man die Unicode-Abdeckung erweitern.

  • Die Schrift ist schön, aber oben im „Lorem“-Beispiel wirkt der Zeichenabstand zu groß, sodass das Kerning etwas unnatürlich erscheint. Mich persönlich stört das.

    • Ich bin der Designer. Weil ich sie täglich nutze, bin ich gegenüber ihren Schwächen abgestumpft. Der Hinweis ist aber berechtigt. Ich werde in der nächsten Version Kerning-Korrekturen in Betracht ziehen. Wenn du konkrete Beispiele hast, hinterlasse bitte ein Issue.

  • Ligaturen sind unter Entwicklern ein ziemlich umstrittenes Thema.
    Manche sagen, Code werde dadurch schöner und leichter lesbar, andere finden, das Verbergen von Symbolen sei unnötig oder unehrlich.
    Wieder andere sagen, dass Ligaturen gar nicht nötig wären, wenn die Sprache Unicode richtig unterstützen würde.
    Letztlich hat dieses Projekt alle drei Lager gleichzeitig gereizt, und genau deshalb ist es noch interessanter. Ich habe auf GitHub einen Stern vergeben.

    • In den meisten Editoren sind Ligaturen eine Option, die man ein- oder ausschalten kann. Damit wird niemand ausgeschlossen.

  • Die Symbole scheinen neben Kleinbuchstaben zu hoch platziert zu sein. Das wirkt wie ein Nebeneffekt der Ausrichtung an Klammern. An der Balance fehlt es ein wenig.

    • Ich bin der Designer. Gewöhnliche Schriften sind textzentriert und folgen deshalb traditioneller Ausrichtung, aber Code ist kein Text.
      Wenn man mit der Tradition bricht, kann die Lesbarkeit sogar besser werden. Der Bindestrich wurde so entworfen, dass er mit > ausgerichtet ist und dadurch eine Pfeilform bildet.

  • Es gibt bereits eine Icon-Schrift namens Myna UI. Das könnte zu Verwechslungen führen.

    • Ich bin der Designer. Danke für den Hinweis. Ich glaube aber nicht, dass es zu großer Verwirrung kommen wird.