Monaspace

 (monaspace.githubnext.com)
1 ポイント 投稿者 GN⁺ 2023-11-10 | 1件のコメント | WhatsAppで共有
  • Monaspaceは、等幅グリッドを維持しながらコード画面により豊かなタイポグラフィ表現を取り入れるための新しいフォントシステム
  • 中核機能のTexture Healingは、隣接する文字ペアの余白の不均衡を代替グリフで補正し、等幅テキストの密度差を減らす
  • この方式はOpenTypeのcontextual alternatesをコード用フォントに適用したもので、別途エディタープラグインなしに多くのエディターで利用でき、Visual Studio Code向け設定も提供されている
  • Monaspaceはウェイト200〜800、傾き0〜-11°、幅100〜125の軸を備え、言語別のコードリガチャをスタイルセットとしてオン・オフできる
  • GitHub Nextは2022年からLettermaticとともにこのフォントを制作しており、コード表示を開発ツールが活用できるより広い表現手段へ拡張しようとしている

等幅コード画面を拡張するフォントシステム

  • Monaspaceはコード用フォントの「superfamily」で、画面上でコードを表示する方法を進化させることに重点を置く
  • コードはテレタイプの初期から等幅フォントで表示されてきたが、Monaspaceはこのグリッドを維持しながらより多くの意味を込めようとしている
  • 既存のエディターは、色ベースのシンタックスハイライトを超える情報を、hover、下線、グラフィック装飾のようなインターフェース要素で伝えることが多い
  • Monaspaceは、コードと開発ツールが活用できるより表現力のあるパレットをフォントのレベルで提供する

Copilotの提案とタイポグラフィ

  • Copilotのようなコード提案は、Monaspaceによって独自のタイポグラフィ上の声を持てる
  • ゴーストテキストは、提案されたコードの解析や評価を難しくすることがある
  • フォント表現自体がどの部分が提案されたコードなのかを示せば、提案されたコード片を後からでも区別しやすくなる

Texture Healingが対象とする等幅フォントの限界

  • 等幅フォントはすべての文字を同じ幅の箱に入れるため、テキスト密度が均一でなくなる
  • 幅の狭い文字であるl、iは箱の中を埋めるために誇張されたセリフが必要になり、それでも必要以上の余白が残る
  • 幅の広い文字であるm、wは箱の中に圧縮されて形が歪み、ストロークが細くなり、内部余白も制限される
  • こうした制約は、1960年代のテレタイプ時代から続く等幅フォントの構造的な問題である

Texture Healingの仕組み

  • Texture Healingは、スペースが足りない文字とスペースが余る隣接文字のペアを見つけ、グリフを置き換える
  • 狭い文字は余白の一部を隣の文字に譲る代替グリフに変わり、広い文字は箱の端まで拡張される代替グリフに変わる
  • この機能はOpenTypeのcontextual alternatesとして実装されている
    • contextual alternatesは、周囲の文字に応じてグリフの形が変わるアラビア文字や筆記体フォントで一般的に使われる
    • Monaspaceはこの技術をコード用の等幅フォントに適用している
  • 結果のテキストは引き続き等幅グリッドに従う
  • Visual Studio CodeでTexture Healingを有効にする方法は、Monaspaceドキュメントで確認できる

フォント軸とスタイル

  • Monaspaceのウェイト軸は200から800まで提供される
    • 200: Extra Light
    • 300: Light
    • 400: Regular
    • 500: Medium
    • 600: Semibold
    • 700: Bold
    • 800: ExtraBold
  • 傾き軸は0から-11°まで提供される
    • 0: Normal
    • -5.5°: 一部の文字がobliqueからitalicの形へ変わる中間地点
    • -11°: Italic
  • 幅軸は100から125まで提供される
    • 100: Normal
    • 112.5: Semiwide
    • 125: Wide
  • MonaspaceにはNeon、Argon、Xenon、Radon、Kryptonといったファミリー名が含まれる

コードリガチャとOpenType設定

  • Monaspaceはさまざまなプログラミング言語向けのコードリガチャを含む
  • リガチャはスタイルセットとして構成されており、ユーザーが必要なセットだけをオン・オフできる
  • 各スタイルセットは、特定言語のニーズをおおまかな基準として設計されている
    • ss01: JavaScriptでよく見られる文字シーケンス向けのリガチャを含む
    • ss05: F#演算子向けのリガチャを提供
  • 追加のOpenType機能も提供される
    • calt: Texture Healingを有効化する
    • liga: ///、||のような繰り返し文字の間隔を調整し、////のようなより長いシーケンス内では有効化されないよう設計されている
  • Visual Studio Codeでは、settings.jsonのeditor.fontLigaturesに必要な機能とスタイルセットを指定して有効化する

制作と配布

  • Monaspaceは、すべての開発者のためにコード表示を改善することを目標に作られた
  • GitHub Nextは2022年にこの取り組みを開始し、Lettermaticとともにフォントを制作した
  • コントリビューター一覧、ドキュメント、フォントファイルはMonaspace repoで確認できる
  • ダウンロードはGitHubリポジトリで提供されている

関連記事

1件のコメント

 
GN⁺ 2023-11-10
Hacker News の意見

  • Texture Healing 機能は OpenType 機能をとても賢く使い、問題になりがちな等幅フォントの組み合わせを、グリッドをまったく崩さずにはるかに見栄えよくしている
    単純な方法なら mi や lm のような扱いにくい文字ペアにリガチャを作るところだが、ここでは周囲の文字に応じて固定幅の中を別の形で埋める 代替グリフ を選んでいるように見える

    • Commit Mono も似たことをしており、Smart kerning と呼んでいる。詳しくは https://commitmono.com/ の「04 Intelligent」タブを見るとよい
      実際には使いにくい。文字幅が後続の文字によって変わるため、入力中にテキストが跳ねる。読むときは格好いいが、書くときは最悪
    • 本当に賢い手法だ。さらに驚くのは、これがかなり昔から可能だったにもかかわらず、誰も思いつかなかった点
      このプロジェクトの一環としてこの手法を考案した Riley Cran と https://lettermatic.com チーム全体はすばらしい
    • あまり説得力は感じない。チェックボックスを何度かオン・オフすると、不一致が見え始める
      たとえば基本例の time_limit では、2つ目の m は両側に i があるため「育つ」余地がより多く、1つ目の m より明らかに幅広く見える。これが良いことなのかはよく分からない
    • ここでは多くの人が texture healing を称賛しているが、私には 中途半端な対策 のように見える。なぜ私たちはコミュニティとして、可変幅フォントの導入をこれほど嫌がるのだろうか？
      この texture healing も、すでに完全な文字セルのグリッドを壊しているので、ある意味では両方の欠点を併せ持っているように感じる
      派手なリガチャもある程度同じように見ている。ソースコードには実際の文字を使えばよく、Unicode は広くサポートされている。Raku はそうしているが、本当に輝くには可変幅フォントを含むより良い組版が必要だ

  • 最初は「また別の等幅フォントファミリーか、見た目はいいね」くらいだったが、texture healing を見てからはぜひ試してみたくなった
    用途ごとに異なるスタイルのフォントを使うというアイデアが本当に気に入った。ただ、主にターミナルを使っているので、どのターミナルがこれをサポートしているのか分からず、コマンドラインのテキストエディタも対応する必要がありそうだ。それでも素晴らしいアイデアだと思う

    • 理論上は xterm ベースなら可能なはず。ESC[<10-19>m がフォント 0〜9 を選ぶ エスケープシーケンス だ
      実際に動くかは別問題。Alacritty を使っているが対応しているか見つけられず、自分で試しても結果は出なかった

  • Mix & Match の例をどう見るべきなのか気になる
    手書き系の Radon は実質的にイタリックのように見えるので、他のフォントとうまく合う。しかし残りはメトリクスなどがあまりに似ていて、「権威あるドキュメント文字列」や「Copilot の声」の例はかなり見分けにくい

    • Mix & Match のために、このフォントを一度使ってみることにした。本物のイタリックがあるから Operator Mono を何年も使っていた
      以前から Operator Mono のオープンな代替を探していたが、Mix & Match のおかげで、ついにこれがその代替になり得ると思えた
    • ページを下にスクロールする前からすぐに思い浮かんだ考えだ。手書きコメント は格好よく、コードをざっと読むときの負担を減らすもう一つの区別要素になる
      嫌う人もいるだろうが、個人的には試してみたい
    • サンプルを切り替えて見ていても、Radon のバリエーションに到達するまで、コードサンプルのボックスで何が変わっているのか気づかなかった
      他のバリエーションは、情報を伝えるには十分に違っていない
    • 異なるフォントをどう設定するのか分からない。真っ先に試したかったのがこれなのに、方法が見つからない。明らかなものを見落としているのだろうか？
    • このアイデアは本当に気に入った。すでにどこかでサポートされているのか、それとも将来のためのものなのだろうか？

  • リガチャはかなり多く入っているが、私にはまだ足りない。今では != と <= は基本で、Fira Code が *ptr の * の高さを合わせたり、X:Y の : を中央に置いたり、0xFF の x を持ち上げたりするのがどれほど良いかが、ずっと目に入ってしまう
    Krypton バリエーションの見た目は気に入りかけたが、小文字 t の横棒が小文字 c のような文字の高さより低すぎる。だから今のところは Fira Code を使い続けると思うし、ユーザーフィードバック後の1年ほどで何が変わったかはまた確認するつもりだ

    • 例示用のホームページにしては、リンク先サイトの例で /** の2つの * がずれているのが不自然だ
      // What if tentative ideas looked handwritten? や /** * What if docstrings looked authoritative? */ といった例で特に目立つ

  • アイデアは良いけれど、なぜ PragmataPro のような幅の狭いフォントをもっと見かけないのか不思議
    もう10年近く使っていて、この領域にもっと選択肢があるといいのに、誰もそこまで狭くしようとはしていないように見える。Berkeley Graphics は Berkeley Mono の狭幅版をほぼ1年にわたって予告しているが、まだ何も起きていない
    ここ Monaspace にも幅スライダーはあるけれど、開始点が「PragmataPro より広い」で、終点は「ばかげて広い」へ向かう感じ。なぜ狭い版のほうにも下げられるようにしなかったのか不思議

    • まったく同意。PragmataPro を毎日使っていて、ほかは全部広すぎると感じる
      標準の Iosevka は近いが、行間がずっと大きい。幸い設定で leading = 1110 にすると、ほぼ同じようにカスタマイズできる。この値は試行錯誤で見つけた
    • Quinze は試したことある？ https://www.programmingfonts.org/#quinze
      最も狭いフォントを探していて、Quinze が答えだと分かった。Iosevka や M+ よりおおよそ20%狭い。PragmataPro と簡単に比較した資料は見つけられなかったが、Iosevka が PragmataPro の無料版解釈だとすれば、Quinze もさらに狭いはず
      実際、Quinze は狭すぎて、ブラウザのすべての等幅テキストに強制的に使わせてみたところ、可読性は良くなるどころか悪くなった。同じ高さでは「普通」のフォントよりずっと小さく見えるため。コーディング環境ではフォントサイズを大きくして使っていて、狭い幅とうまく合う
      欠点は Quinze が非常にミニマルなこと。ほぼ ASCII だけで、合字もカスタマイズもない。自分はそうした点は気にならない
    • Iosevka もかなり狭く、人気もある。求めている基準に合うかは分からないが、見てみる価値はある
    • たった今 M+ を知ったが、「60」バリアントがかなり気に入った。標準幅の 50 は自分には狭すぎて、好みとしては 50 バリアントでは可読性が落ちるように感じる
      それでも望むだけ狭くできる
      https://mplusfonts.github.io/
    • 狭いフォントの話が出たついでに、良い 狭幅のセリフ体 のおすすめはある？ 有料でも無料でも構わない
      ブラウザで Times の代わりに “Bell MT” を使っていて、emacs Org mode の可変幅フォントとしても使っている。良いのだけれど、もっと大きくて狭い版があるといい
      それから、良い狭幅の等幅フォントの一つに “The Sans Mono Condensed” があり、初期の O’Reilly 本のおかげで有名になった。その後 O’Reilly は別の等幅フォントに変えた。欠点は西欧文字セットしかないことだが、自分はかなり気に入っていた

  • ページの Radon の元素記号が Rd になっているのが気になる。Radon なら Rn のはず
    Radium は Ra、Radon は Rn だが、実際に R で始まり名前に d が入るほかの元素があるのか、思わず確認し直した

    • それは自分も見たし、その後修正された
    • Rhodium はあるが、記号は Rh だ

  • mono flag が設定されていないので、フォントを読み込むには GTK2 gvim で試す必要があった
    % ttfmono MonaspaceArgon-Regular.otf の結果が monospaced flag = 0 で、0 = variable-width, otherwise = monospaced と出る
    残念ながら、このフラグのせいで合字が有効にならないようだ
    それでも、パッチを当てた st 上で実行した vim では合字と texture healing を見ることができ、本当に気に入った。入力時に行がごくわずかに動くだけで、カーソルが通過するときにも、たとえば広くなった m のせいで残像が残ることもない。コード用としてよく設計されている
    機能を一つ要望できるなら、角張った 0 にバックスラッシュを入れるとか、!= の合字で ! を残すといった、一部のバリアントを選べると嬉しい。言っていることはここで見られる: https://github.com/be5invis/Iosevka/blob/main/doc/stylistic-...
    https://st.suckless.org/patches/ligatures/

    • 確か？ macOS では Font Book の “Fixed Width” フォントの下に表示される
      今日配布されたバージョンを使っているので、最近修正されたのかもしれない
    • KDE Konsole でも同じ問題がある: https://imgur.com/a/Dj1HZiu
      “Show all fonts” チェックボックスを明示的にオンにしないと、「等幅ではない」フォントまで表示されない

  • 現代のシステムでは、コード用フォントもそろそろ 等幅フォント を超えられると思う
    ここで何度かおすすめしているが、自分はプロポーショナルなコーディングフォントである Input Sans を使っている
    https://input.djr.com

    • おすすめする理由が気になる
      このフォントではタイプミスを見つけるのがより難しくなるかもしれないように見える
    • コーディングにプロポーショナルフォントを使いたいが、それをきれいにサポートする Vim フロントエンドをよく知らない
      SSH で Vim を使うときは等幅を使い続けてもよいが、Neovim のおかげでフロントエンドはかなり増えたにもかかわらず、プロポーショナルフォントをサポートするものはほとんどないように見える。対応しているものも、使うのが苦痛なほど遅い傾向がある
    • >= を ≥ に変える合字をサポートしている？ スマホで Web プレビューを試したが、Android Firefox の制限かもしれない
      ちなみに合字とはこういうもの: https://fonts.google.com/knowledge/glossary/ligature

  • このようなフォントで、ドット付きの0がどうして標準のようになったのか、いつも不思議に思います。私はいつも8と混同してしまうので、スラッシュ付きの0のほうがずっと好みです
    そういうバリエーションがあるなら、このフォントをぜひ使ってみたいです

    • スラッシュ付きの円が文字である言語もあるので、スラッシュ付きの0は混乱を招くことがあります。ドット付きの0は、その方向での混同の可能性がずっと低いです
      フォントデザイナーがドット付きの0の凸の側面と 8 の凹の側面を強調して視覚的に区別することもできるでしょうが、このフォントがそうしているかは分かりません
    • Issueでスラッシュ付きの0を提案したら、ある人がドット付きの0も同じ目的を果たすと返信してきました。本当にイライラします

  • Texture healing は本当に賢く、美しいアイデアです
    等幅で使われることの多い中国語の手書き文字にも適用してみたいです。一般的ながら非常に密な文字、特に 邊鐵餐廳臺藥機麵顧露樓幫讓 のような繁体字は、追加のスペースを得て広く展開できれば大きなメリットがあるでしょう