tawara

v1.5.0で対応していました。お声がけしておけばよかったですね、すみません。

残念ながら私の手元の環境にmacが無いため、再現調査ができません…。 推測で話をすると、丸数字記号はEast Asian Ambiguous Widthに該当する文字ですので、以下の問題が発生しているのではないかと思います。 [East Asian Ambiguous Width問題](https://github.com/hamano/locale-eaw) これはフォント側では全角幅で定義されていても、特定アプリケーションではその幅が無視され異なる幅で表示されることが原因で起こる事象です。 よって、この問題であればフォントの不具合ではありません。 なお、この問題に対処する方法は以下のいずれかだと思われます。 - アプリケーションのEast Asian Ambiguous Width関連設定を見直す - East Asian Ambiguous Widthの記号が半角となるフォントを使う（JPDOC版で無いものが概ねこれに該当します） - フォント側の設定幅を正しく認識するアプリケーションを使用する 私のところにmac環境が無いのでググっただけで試せていませんが、以下の記事も参考になるかもしれません。 https://qiita.com/seto-r/items/706d2c4d795dba7d42ed

提案ありがとうございます。 ターミナルアプリによっては日本語部分を等幅に扱うためにそのような見た目で表示するものも見かけますし、そういった需要があるのは理解しますが、日本語の表示幅が広くなりすぎるためターミナル以外で常用するのは厳しくなると考えています。過去に実験的に作ったこともありますが、あまりに間延びして見づらかったので断念しました。 そういったことがあり正直なところ、英数字オリジナルの幅のまま1:2にするバリエーションを用意するのはあまりモチベーションがありません。 可能性としてあるとすれば、HackGenやPlemolJP、Moralerspaceの1:2幅版のように、通常の半角幅より1.2倍程度に広げるものです。これであれば半角英数字のタイトさを多少は軽減しつつ、日本語グリフの間延び感も許せる程度には抑えられます。 とはいえ、そもそもUDEV Gothicの1:2幅でHackGen等の前例にならっていないのは、「日本語グリフの間延び間を出さない ＝ 日本語の読みやすさ優先」を隠れコンセプトとして持っていたためです。それもあり、日本語グリフの幅を広げることには消極的です。

現状、仕様通りです。 本フォントにおいて、基本的に「全角幅を半角幅に縮小」の加工は行っていません。半角幅になっているグリフのほとんどは、JetBrains Mono由来のものが合成時に優先されているのが理由です。例えば `U+01D1` の近辺である `U+01D0` や `U+01D2` が半角になっているのは、JetBrains Monoに含まれているからです。 こういった仕様であることを踏まえると、BIZ UDゴシックとJetBrains Monoのいずれかにしか含まれていないグリフは、必ず存在する方が優先されます。 `U+01D1` は、BIZ UDゴシック側にのみ含まれるため、全角となっています。 左がBIZ UDゴシック、右がJetBrains Mono