1 Punkte von GN⁺ 2023-11-10 | 1 Kommentare | Auf WhatsApp teilen
  • Monaspace ist ein neues Schriftsystem, das das Monospace-Raster beibehält und zugleich eine reichhaltigere typografische Ausdrucksform in Codeansichten ermöglicht
  • Die Kernfunktion Texture Healing korrigiert unausgewogene Abstände zwischen benachbarten Zeichenpaaren mit alternativen Glyphen und reduziert so Dichteunterschiede in Monospace-Text
  • Dieser Ansatz überträgt OpenTypes contextual alternates auf Schriften für Code, funktioniert ohne separates Editor-Plug-in in den meisten Editoren und bietet auch Einstellungen für Visual Studio Code
  • Monaspace bietet Achsen für Gewicht von 200 bis 800, Neigung von 0 bis -11° und Breite von 100 bis 125; sprachspezifische Code-Ligaturen lassen sich über Style Sets ein- und ausschalten
  • GitHub Next entwickelt diese Schrift seit 2022 gemeinsam mit Lettermatic und will die Darstellung von Code zu einem breiteren Ausdrucksmittel erweitern, das Entwicklungstools nutzen können

Ein Schriftsystem, das Monospace-Codeansichten erweitert

  • Monaspace ist eine „Superfamily“ für Code-Schriften und konzentriert sich darauf, die Darstellung von Code auf dem Bildschirm weiterzuentwickeln
  • Code wird seit den frühen Teletype-Zeiten in Monospace-Schriften dargestellt; Monaspace will dieses Raster beibehalten und zugleich mehr Bedeutung transportieren
  • Bestehende Editoren vermitteln Informationen jenseits farbbasierter Syntaxhervorhebung häufig über Interface-Elemente wie Hover, Unterstreichungen oder grafische Verzierungen
  • Monaspace stellt auf Schriftebene eine ausdrucksstärkere Palette bereit, die Code und Entwicklungstools nutzen können

Copilot-Vorschläge und Typografie

  • Codevorschläge wie die von Copilot können durch Monaspace eine eigene typografische Stimme erhalten
  • Ghost Text kann es erschweren, vorgeschlagenen Code zu parsen und zu bewerten
  • Wenn die Schriftdarstellung selbst zeigt, welcher Teil vorgeschlagener Code ist, lassen sich vorgeschlagene Codefragmente auch später leichter unterscheiden

Die Grenzen von Monospace-Schriften, auf die Texture Healing abzielt

  • Monospace-Schriften setzen jedes Zeichen in eine gleich breite Box, wodurch die Textdichte ungleichmäßig wird
  • Schmale Zeichen wie l und i brauchen überzeichnete Serifen, um die Box auszufüllen, und dennoch bleibt mehr Leerraum als nötig
  • Breite Zeichen wie m und w werden in die Box gedrückt, wodurch ihre Form verzerrt wird, Striche dünner werden und auch die Binnenräume begrenzt sind
  • Diese Einschränkungen sind ein strukturelles Problem von Monospace-Schriften, das bis in die Teletype-Ära der 1960er-Jahre zurückreicht

So funktioniert Texture Healing

  • Texture Healing findet Zeichenpaare, bei denen einem Zeichen Platz fehlt und beim benachbarten Zeichen Platz übrig ist, und ersetzt die Glyphen
  • Schmale Zeichen werden durch alternative Glyphen ersetzt, die einen Teil ihres Leerraums an den Nachbarn abgeben; breite Zeichen werden durch alternative Glyphen ersetzt, die bis an den Rand der Box erweitert sind
  • Die Funktion ist über OpenTypes contextual alternates implementiert
    • Contextual alternates werden typischerweise bei arabischer Schrift oder Schreibschrift-Fonts genutzt, bei denen sich Glyphenformen je nach umgebenden Zeichen ändern
    • Monaspace wendet diese Technik auf Monospace-Schriften für Code an
  • Der resultierende Text folgt weiterhin einem Monospace-Raster
  • Wie sich Texture Healing in Visual Studio Code aktivieren lässt, steht in der Monaspace-Dokumentation

Schriftachsen und Stile

  • Die Gewichtsachse von Monaspace reicht von 200 bis 800
    • 200: Extra Light
    • 300: Light
    • 400: Regular
    • 500: Medium
    • 600: Semibold
    • 700: Bold
    • 800: ExtraBold
  • Die Neigungsachse reicht von 0 bis -11°
    • 0: Normal
    • -5,5°: Zwischenpunkt, an dem einige Zeichen von Oblique- zu Italic-Formen wechseln
    • -11°: Italic
  • Die Breitenachse reicht von 100 bis 125
    • 100: Normal
    • 112,5: Semiwide
    • 125: Wide
  • Monaspace umfasst Familiennamen wie Neon, Argon, Xenon, Radon und Krypton

Code-Ligaturen und OpenType-Einstellungen

  • Monaspace enthält Code-Ligaturen für verschiedene Programmiersprachen
  • Die Ligaturen sind als Style Sets organisiert, sodass Nutzer nur die gewünschten Sets ein- oder ausschalten können
  • Jedes Style Set ist grob an den Anforderungen einer bestimmten Sprache ausgerichtet
    • ss01: enthält Ligaturen für Zeichenfolgen, die in JavaScript häufig vorkommen
    • ss05: bietet Ligaturen für F#-Operatoren
  • Außerdem werden weitere OpenType-Funktionen bereitgestellt
    • calt: aktiviert Texture Healing
    • liga: passt die Abstände wiederholter Zeichen wie /// und || an und ist so gestaltet, dass es innerhalb längerer Sequenzen wie //// nicht aktiv wird
  • In Visual Studio Code werden die gewünschten Funktionen und Style Sets in editor.fontLigatures in settings.json angegeben und aktiviert

Erstellung und Bereitstellung

  • Monaspace wurde mit dem Ziel entwickelt, die Darstellung von Code für alle Entwickler zu verbessern
  • GitHub Next begann 2022 mit dieser Arbeit und entwickelte die Schrift gemeinsam mit Lettermatic
  • Die Liste der Mitwirkenden, Dokumentation und Schriftdateien sind im Monaspace-Repository verfügbar
  • Downloads werden über das GitHub-Repository bereitgestellt

1 Kommentare

 
GN⁺ 2023-11-10
Meinungen auf Hacker News
  • Die Funktion Texture Healing nutzt OpenType-Features sehr clever, um problematische Kombinationen in Monospace-Schriften deutlich ansehnlicher zu machen, ohne das Raster auch nur im Geringsten zu brechen.
    Ein einfacher Ansatz wäre, für schwierige Buchstabenpaare wie mi oder lm Ligaturen zu erstellen; hier scheint es aber eher so zu sein, dass je nach umgebenden Buchstaben alternative Glyphen ausgewählt werden, die den festen Zeichenraum unterschiedlich ausfüllen.

    • Commit Mono macht etwas Ähnliches und nennt es Smart Kerning. Details findet man unter https://commitmono.com/ im Tab „04 Intelligent“.
      In der Praxis ist es schwer zu verwenden. Die Zeichenbreite ändert sich je nach folgendem Buchstaben, sodass der Text beim Tippen springt. Beim Lesen sieht es gut aus, beim Schreiben ist es furchtbar.
    • Eine wirklich clevere Technik. Noch erstaunlicher ist, dass das schon seit sehr langer Zeit möglich war und trotzdem niemand darauf gekommen ist.
      Großes Lob an Riley Cran, der diese Technik im Rahmen dieses Projekts entwickelt hat, und an das gesamte Team von https://lettermatic.com.
    • Mich überzeugt das nicht besonders. Wenn man die Checkboxen ein paar Mal ein- und ausschaltet, sieht man die Unstimmigkeiten.
      Im Standardbeispiel time_limit hat etwa das zweite m auf beiden Seiten ein i und damit mehr Platz, um zu „wachsen“, sodass es klar breiter wirkt als das erste m. Ich bin mir nicht sicher, ob das gut ist.
    • Viele Leute loben hier Texture Healing, aber für mich wirkt es wie eine halbherzige Gegenmaßnahme. Warum sträuben wir uns als Community so sehr gegen die Einführung von Proportionalschriften?
      Auch dieses Texture Healing bricht bereits das perfekte Zeichenzellenraster, sodass es sich in gewisser Weise so anfühlt, als hätte es die Nachteile beider Seiten.
      Ausgefallene Ligaturen sehe ich in gewissem Maße ähnlich. Man kann die tatsächlichen Zeichen im Quellcode verwenden, und Unicode wird breit unterstützt. Raku macht das so, aber damit es wirklich glänzt, braucht es besseren Schriftsatz einschließlich Proportionalschriften.
  • Anfangs dachte ich nur: „Schon wieder eine Monospace-Schriftfamilie, sieht nett aus“, aber nachdem ich Texture Healing gesehen habe, möchte ich sie unbedingt ausprobieren.
    Die Idee, je nach Zweck unterschiedliche Schriftstile zu verwenden, gefällt mir wirklich sehr. Da ich allerdings hauptsächlich im Terminal arbeite, weiß ich nicht, welche Terminals das unterstützen, und Befehlszeilen-Texteditoren müssten es wohl ebenfalls unterstützen. Trotzdem halte ich es für eine großartige Idee.

    • Theoretisch sollte es möglich sein, wenn es auf xterm basiert. ESC[<10-19>m ist die Escape-Sequenz, mit der die Schriften 0 bis 9 ausgewählt werden.
      Ob es in der Praxis funktioniert, ist eine andere Frage. Ich nutze Alacritty, konnte aber nicht herausfinden, ob es unterstützt wird, und eigene Versuche haben kein Ergebnis gebracht.
  • Mich würde interessieren, wie andere die Mix & Match-Beispiele sehen.
    Radon, die handschriftliche Variante, wirkt praktisch wie Kursivschrift und passt gut zu den anderen Schriften. Die übrigen sind sich bei Metriken usw. aber so ähnlich, dass Beispiele wie „autoritative Dokumentations-Strings“ oder „Copilot-Stimme“ ziemlich schwer zu unterscheiden sind.

    • Wegen Mix & Match habe ich beschlossen, diese Schrift einmal auszuprobieren. Ich nutze seit Jahren Operator Mono, gerade wegen der echten Kursivschrift.
      Schon lange suche ich nach einer offenen Alternative zu Operator Mono, und dank Mix & Match könnte das endlich diese Alternative sein.
    • Genau das kam mir schon in den Sinn, bevor ich die Seite weiter nach unten gescrollt hatte. Handschriftliche Kommentare sind cool und bieten ein weiteres Unterscheidungsmerkmal, das beim Überfliegen von Code entlastet.
      Manche werden es nicht mögen, aber ich persönlich möchte es ausprobieren.
    • Beim Durchklicken der Samples habe ich in der Code-Beispielbox nicht bemerkt, was sich ändert, bis ich zur Radon-Variante kam.
      Die anderen Varianten sind nicht unterschiedlich genug, um Informationen zu vermitteln.
    • Ich weiß nicht, wie man die verschiedenen Schriften einstellt. Das war das Erste, was ich ausprobieren wollte, aber ich finde nicht heraus, wie es geht. Übersehe ich etwas Offensichtliches?
    • Diese Idee gefällt mir wirklich. Wird sie irgendwo bereits unterstützt, oder ist das eher etwas für die Zukunft?
  • Es sind ziemlich viele Ligaturen enthalten, aber für mich reicht es noch nicht. != und <= sind inzwischen Standard, und mir fällt immer wieder auf, wie gut es ist, dass Fira Code bei *ptr die Höhe von * anpasst, bei X:Y den : zentriert oder bei 0xFF das x anhebt.
    Die Krypton-Variante hätte mir fast gefallen, aber der Querstrich des kleinen t liegt deutlich niedriger als die Höhe von Buchstaben wie dem kleinen c. Daher werde ich vorerst wohl bei Fira Code bleiben und in etwa einem Jahr, nach Nutzerfeedback, noch einmal prüfen, was sich geändert hat.

    • Für eine Beispiel-Website wirkt es seltsam, dass in den Beispielen auf der verlinkten Seite die beiden * in /** nicht ausgerichtet sind.
      Besonders sieht man das in Beispielen wie // What if tentative ideas looked handwritten? und /** * What if docstrings looked authoritative? */.
  • Die Idee ist gut, aber ich frage mich, warum man nicht mehr schmale Schriften wie PragmataPro sieht.
    Ich nutze sie seit fast 10 Jahren und hätte in diesem Bereich gern mehr Auswahl, aber anscheinend will niemand so schmal werden. Berkeley Graphics kündigt seit fast einem Jahr eine schmale Version von Berkeley Mono an, aber bislang ist nichts passiert.
    Auch hier bei Monaspace gibt es einen Breiten-Slider, aber der Startpunkt fühlt sich an wie „breiter als PragmataPro“ und das Ende wie „absurd breit“. Ich frage mich, warum sie ihn nicht auch in Richtung einer schmalen Variante nach unten gehen lassen.

    • Stimme voll und ganz zu. Ich nutze PragmataPro täglich, und alles andere fühlt sich viel zu breit an.
      Das normale Iosevka kommt nahe heran, hat aber einen deutlich größeren Zeilenabstand. Zum Glück kann man es in den Einstellungen mit leading = 1110 fast identisch anpassen. Diesen Wert habe ich durch Ausprobieren gefunden.
    • Hast du Quinze ausprobiert? https://www.programmingfonts.org/#quinze
      Auf der Suche nach der schmalsten Schrift habe ich festgestellt, dass Quinze die Antwort ist. Sie ist ungefähr 20 % schmaler als Iosevka oder M+. Einen einfachen Vergleich mit PragmataPro konnte ich nicht finden, aber wenn Iosevka die kostenlose Interpretation von PragmataPro ist, dürfte Quinze noch schmaler sein.
      Tatsächlich ist Quinze so schmal, dass die Lesbarkeit schlechter statt besser wurde, als ich sie im Browser für sämtlichen Monospace-Text erzwungen habe. Bei gleicher Höhe wirkt sie nämlich viel kleiner als „normale“ Schriften. In der Coding-Umgebung nutze ich sie mit größerer Schriftgröße, und das passt gut zur schmalen Breite.
      Der Nachteil ist, dass Quinze sehr minimalistisch ist. Es gibt fast nur ASCII, keine Ligaturen und keine Anpassungsmöglichkeiten. Mich stört das nicht.
    • Iosevka ist ebenfalls ziemlich schmal und beliebt. Ob sie deinen Kriterien entspricht, weiß ich nicht, aber einen Blick ist sie wert.
    • Ich habe gerade M+ entdeckt, und die Variante „60“ gefällt mir ziemlich gut. Die Standardbreite 50 war mir zu schmal, und nach meinem Geschmack leidet bei der 50er-Variante die Lesbarkeit.
      Trotzdem kann sie so schmal sein, wie du möchtest.
      https://mplusfonts.github.io/
    • Wo wir gerade über schmale Schriften sprechen: Hat jemand Empfehlungen für gute schmale Serifenschriften? Bezahlt oder kostenlos ist beides in Ordnung.
      Im Browser verwende ich statt Times „Bell MT“ und auch als Proportionalschrift in emacs Org mode; sie ist gut, aber eine größere und schmalere Version wäre schön.
      Eine weitere gute schmale Monospace-Schrift ist „The Sans Mono Condensed“, die durch die frühen O’Reilly-Bücher bekannt wurde. Später wechselte O’Reilly zu einer anderen Monospace-Schrift. Der Nachteil ist, dass sie nur den westlichen Zeichensatz hat, aber ich mochte sie sehr.
  • Mich stört, dass das Radon-Symbol auf der Seite Rd ist. Für Radon müsste es Rn sein.
    Radium ist Ra, Radon ist Rn, und ich musste tatsächlich noch einmal prüfen, ob es ein anderes Element gibt, das mit R beginnt und ein d im Namen hat.

    • Das habe ich auch gesehen, und es wurde inzwischen behoben.
    • Es gibt zwar Rhodium, aber sein Symbol ist Rh.
  • Da das mono flag nicht gesetzt ist, musste ich es mit GTK2 gvim versuchen, um die Schrift zu laden.
    Das Ergebnis von % ttfmono MonaspaceArgon-Regular.otf ist monospaced flag = 0, und es heißt 0 = variable-width, otherwise = monospaced.
    Leider scheint wegen dieses Flags keine Ligatur aktiviert zu werden.
    In vim, ausgeführt in einem gepatchten st, konnte ich aber Ligaturen und Texture Healing sehen, und es gefällt mir wirklich sehr. Beim Tippen bewegen sich die Zeilen nur äußerst subtil, und wenn der Cursor vorbeiläuft, bleibt zum Beispiel durch ein verbreitertes m auch kein Nachbild zurück. Für Code ist das gut designt.
    Wenn ich mir ein Feature wünschen dürfte, dann wäre es, einige Varianten auswählen zu können, etwa eine Null mit Backslash in der eckigen 0 oder bei der Ligatur != das ! beizubehalten. Was ich meine, sieht man hier: https://github.com/be5invis/Iosevka/blob/main/doc/stylistic-...
    https://st.suckless.org/patches/ligatures/

    • Sicher? Unter macOS erscheint sie in Font Book unter den „Fixed Width“-Schriften.
      Ich nutze die heute veröffentlichte Version, vielleicht wurde es also kürzlich behoben.
    • In KDE Konsole gibt es dasselbe Problem: https://imgur.com/a/Dj1HZiu
      Man muss die Checkbox „Show all fonts“ explizit aktivieren, damit auch „nicht monospaced“ Schriften angezeigt werden.
  • Auf modernen Systemen könnten Schriften für Code inzwischen wohl über Monospace-Schriften hinausgehen.
    Ich habe sie hier schon mehrfach empfohlen, aber ich nutze Input Sans, eine proportionale Coding-Schrift.
    https://input.djr.com

    • Mich würde interessieren, warum du sie empfiehlst.
      Bei dieser Schrift sieht es so aus, als könnten Tippfehler schwerer zu finden sein.
    • Ich würde beim Coden gern eine Proportionalschrift verwenden, kenne aber kein Vim-Frontend, das das sauber unterstützt.
      Wenn ich Vim über SSH nutze, ist Monospace weiterhin okay, aber obwohl es dank Neovim inzwischen viele Frontends gibt, scheinen nur sehr wenige Proportionalschriften zu unterstützen. Und die, die es tun, sind meist quälend langsam zu benutzen.
    • Unterstützt sie Ligaturen, die >= in umwandeln? Ich habe die Web-Vorschau auf dem Handy ausprobiert, aber das könnte auch eine Einschränkung von Android Firefox sein.
      Zur Referenz: Das sind Ligaturen: https://fonts.google.com/knowledge/glossary/ligature
  • Bei solchen Schriftarten frage ich mich immer, wie die Null mit Punkt quasi zum Standard geworden ist. Ich verwechsle sie immer mit der 8 und bevorzuge die durchgestrichene Null deutlich
    Falls es so eine Variante gibt, würde ich diese Schriftart unbedingt ausprobieren wollen

    • Es gibt Sprachen, in denen ein durchgestrichener Kreis ein Buchstabe ist, daher kann die durchgestrichene Null Verwirrung stiften. Bei einer Null mit Punkt ist die Wahrscheinlichkeit für solche Verwechslungen deutlich geringer
      Ein Schriftdesigner könnte zwar die konvexen Seiten der Null mit Punkt und die konkaven Seiten der 8 betonen, um sie visuell zu unterscheiden, aber ich weiß nicht, ob diese Schriftart das tut
    • Ich habe in einem Issue eine durchgestrichene Null vorgeschlagen, und jemand antwortete, dass eine Null mit Punkt denselben Zweck erfülle. Wirklich nervig
  • Texture healing ist eine wirklich clevere und schöne Idee
    Ich würde das gern auch auf chinesische Handschrift anwenden, die oft in fester Zeichenbreite gesetzt wird. Häufige, aber sehr dichte Zeichen, insbesondere traditionelle Zeichen wie 邊鐵餐廳臺藥機麵顧露樓幫讓, würden stark davon profitieren, wenn sie zusätzlichen Raum bekommen und breiter auseinandergezogen werden könnten