当サイトのデザインとウェブフォント
「コリモセーズ／シラベル のウェブサイト」の各ページのデザイン、とくに視覚的な装飾、外観に関することを書きます。どういう考えで現在のデザインを採用しているかとか、この数年でどんな調整を加えてきたかとか、フォントのこととかを取り上げます。
もちろん、ページの構成のしかたや、どこにどういうリンクを用意するか、読み上げソフト類を使うひとに不親切なところはないか、などなどいろんなことがデザインに絡み合ってくるわけですけれど、それはいつか別の記事で書くことがあるかもしれません。本稿では、（モダンブラウザで閲覧したときの）外観上のデザインの話に絞ります。
どちらかというと、サイトの更新で見た目に関する変更をしたときに、詳細を書く場所が欲しかったのでつくったページです。技術的なことにもすこし触れます。
更新があったり思うところがあったりすれば書き足していきます。内容に濃淡、偏りがあります。解説というよりエッセイとして読んでいただければ。
サイトの見た目に関するおもな更新履歴
日付の新しい順です。たまに微調整をしていますけれど、ここでは取り上げません。サイト開設から2022年まで、外観のスタイルのことに限れば、案外ここに挙げるべき大きな更新がなかった気がします。
- 2023年9月29日 リストのマーカーを、自作のフォントによるよつばマークに変更。ウェブフォントのファイルを一部修正。
- 2023年9月16日 ウェブフォントのファイルを更新し、閲覧環境によってフォントの描画がぎざぎざするのを、なめらかになるようにした。
- 2023年6月1日 ダークモードの閲覧環境に対応。
表示スタイルの方向性
当サイトのページを見ると、音楽系・創作系のサイトというより、取扱説明書、「かんたんガイド」に近い印象を持たれるかもしれません。最優先しているのは「かっこいいこと」ではなく、「簡潔で迷わせずわかりやすいこと」です。やたらスライドしたりせり出してきたりと動きばかりが派手で、どこになにがあるかよくわからず、目当てのコンテンツに辿り着く前に疲れきってしまう、という（企業によくある）ようなサイトにはならないように心がけています。
わたしはウェブデザイナーでもなくウェブエンジニアでもなく、自分でサイトをつくって発信する上で必要になる言語（「HTML」や「CSS」や「Javascript」）を独学で嗜んでいるにすぎないので、あまり凝ったことはできません。
そもそも、文章や音楽やイラストを公開するという目的であれば、そんなに難しいことをする必要もないので、コンテンツ管理システム（「ワードプレス」などの類）に依存せずに、自分でHTMLファイルをこしらえて、そのままアップロードするほうがいいと考えました。また、作品のみならず、紹介しているページの見栄えも、（テンプレートのデザインではなく）自分の意思を隅々まで反映させたものであるべきだという思いもあります。
もちろん、HTMLでのレイアウトと、PDFや紙媒体などでのレイアウトとは、まったく別物です。こまかいところをがちがちに縛ることは無意味です。あくまでHTMLの柔軟さに沿って、シンプルにデザインを組み立てています。
サイトの内容が有益かつ独自のものであれば、白地に黒の文字がびっしりずらりと並んでいるだけでもいい、という考えかたもあると思います。そのへんは取り扱う情報のジャンルにもよるかと思いますし、わたしはさすがにそこまで開き直ることはできません。ある程度、見た目の心地よさが伴っている、気の利いたデザインにしたいと思います。そして、その時代その時代のウェブサイトのありかたに、ちょっとだけでも合わせていく必要もありましょう。
「CSS」という言葉が何度かこのあと出てきます。CSSというのは、文書の体裁、デザインに関する指定をする言語です。当サイトの場合でいうと、ページ本体（HTMLファイル）をブラウザが読み込む際に、「style.css」というファイルが呼び出されます。このファイルに、配色や枠線の形、文字の大きさ・太さや行間などの指定をしたCSSが書いてあって、ブラウザがそれを反映して表示させています。（いわゆるテキストブラウザのように、CSSを使わない閲覧環境もあります。）
サイトの準備段階でデザインをしっかり練り上げたつもりだったので、開設後はCSSファイルをいじることも滅多にないだろう、なんて考えていましたけれど、なかなかどうして、数ヶ月に一度くらいはどうしても修正したいところが出てきて、何度も更新しています。ウェブサイトは生き物ですね。
配色
配色は、青みがかった緑色を基調にしています。一般的に緑は、見ていてストレスの少ない、ホッと落ち着く色だと思います。また、ファビコンに描いたよつばにちなんだ選択でもあります。リンクの色は、通例に逆らわずに青系です。
あと、フォントも含めて、角丸を多用しています。これは単なる好みでもありますし、どことなく親しみやすい雰囲気を醸し出して猫かぶりをしている面もあります。
配色を決めるときには、コントラストに留意する必要があって、たとえば文字の色と下地との色合いが近すぎてはいけません。純白と漆黒ならいちばんコントラストが高くなります。でも、デザインの都合でそこまで正反対の色にできないときもあります。たとえば緑系の色を下地にして文字を白にしている箇所が当サイトにあります。そこで緑をあまり明るくすると視認性が悪くなり、ひとによっては読めなくなります。望ましいコントラスト比かどうかがチェックできるツールを援用しながら、このくらいの明るさの緑ならよかろう、というふうに決めていったわけです。
「ダークモード」での配色の変更については、「ダークモード対応」の節に書きました。
1列レイアウト
PCでブログを閲覧したときによく見かける外観を、画像1で例示してみました。
画像1のなかの記事らしき文章は、無関係なギャグです。
べつにあげつらうつもりはないのですけれど、地方都市の駅前の風景よろしく、似たかよったかなデザインのページが巷に溢れています。（いまはアカウントをつくって記事を投稿するタイプのサービスが主流で、似ているどころか、サービスごとに見た目が固定されていたりもします。）それでも記事に価値や厚みや人間臭さがあればリピート訪問したりもするのですけれど、そういうこともさして多くなく、知りたい情報が得られればそれでさよなら、サイト名も著者もまるで意識になし、というネットサーフィンは、なんとなくむなしいものです。
さて、画像で示したように、本文の右または左、あるいは両側に、いろんなナビゲーションリンクを置くスペース（サイドバー）を設けることが一般的です。当サイトではそういうものを排していて、PCで見たときにもモバイル端末で見たときにも1列レイアウトの形になります。
1列と複数列、それぞれ長所と短所があって、複数列レイアウトの長所については、サイト制作者としてどうもピンとこなくて……という話をします。
スマートフォンの利用が増えてくるにつれて、ウェブデザイン界隈では「レスポンシブ・デザイン」という言葉がしきりに飛び交うようになりました。たとえば、PCのような大きな画面ならサイドバーをつけた複数列のレイアウト、横幅が狭いスマートフォンなら1列レイアウト、というふうに閲覧環境によってデザインを可変にする手法を指す言葉です。
スマートフォンで閲覧したときにサイドバーの内容がページ下部に移っていてもとくに不便でないのなら、PCで観るときだってそれで問題ないのではないのか、というふうに素朴に思います。「PCの場合は、広い画面を活かした複数列レイアウトで表示して、必要な情報を一望しやすくするほうがいい」という通説には懐疑的です。わたしの場合たいていPCでサイトを見ますけれど、本文の記事を読んでいるときに、サイドバーにずらずらリンクや画像が並んでいるのが眼にはいると気が散るから、ブラウザの横幅を狭くすることが多々あります。（横幅によってデザインを可変にしているサイトなら、ブラウザの横幅を狭めればスマートフォン向けの1列レイアウトに切り替わります。）あまり使いたくないけれど「リーダーモード」に切り替えることすらあります。だいたい、サイドバーに並んでいる「新着記事」「よく読まれている記事」「カテゴリ」「カレンダー」などは、たいていの場合、とくに必要な情報ではなく、ノイズですらあります。
公共機関のサイトなどであれば、目当てのページへ素早く行き来できるようにする意味は大きいと思いますけれど、現状の当サイトでは、「アクセスしてから目当てのページを探す」場合より「このページに目当てのものがあるらしいからアクセスした」という場合のほうが多いと予想できます。リピーターにもなれば「アクセスしてから目当てのページを探す」こともあるかもしれませんけれど、リピーターなら「最近の記事」「関連していそうな記事」を見つける要領も掴めてくるはず。（当サイトの場合、トップページからすべての記事に飛べます。）
サイドバーを実現しようとするととたんにCSSを書く難易度が上がりそうだから避けた、という理由もあります。シンプルなほうが、のちのちまで楽です。
サイドバーでの配置に似つかわしい各種リンクや情報は、当サイトの場合そんなにたくさんありません。ページ最下部（フッター）に、トップページや利用規約のページへのリンクや、ほかのウェブサービスで持っているアカウントへのリンクを並べています。フッターにあればそれで充分なのか、という問いが当然浮かびますけれど、ページの末尾まで読まない閲覧者が、サイトの利用規約やらなんやらをチェックするとは思えませんから、フッターだけで充分ではないかと思います。サイドバーをつねに固定するやりかたもありますけれど、それはそれで、邪魔っけに感じることがよくあります。
先の画像で例示したように、多くの場合は本文のスペースが長く下に伸びるので、サイドバーは途中から無駄な空白になりがちです。本文が短いくせにサイドバーのほうにずらずらと余計なリンクが並んでいるのは、もっとみっともないものです。
そういったわけで、当サイトではPCでも1列レイアウトでの表示になっています。いちおう、見出しの幅など細かい部分の調整に関しては、レスポンシブ・デザインを取り入れています。それと、本文の横幅は、1行あたりの文字数が多すぎると読みづらいので、ある程度以上は広くならないようになっています。
ダークモード対応
近年のOSやソフトウェアには、ライトモード・ダークモードを切り替えられるものが増えてきました。
ダークモードにしているときに明るい背景色のウェブページを閲覧すると、まぶしく感じることもあるかもしれません。わたしもどちらかというと暗くしたがりなのですけれど、サイト制作者としては、ダークモードなんて知るかい、色を変えたいなら拡張機能かなにかで勝手になさい、といいたいところ……をぐっとこらえて、ある程度は潮流に合わせていく部分も要るかな、ということでダークモード対応を決めました。
当サイトで実装したのは、2023年6月の初めでした。画像2のように色が切り替わります。
技術的な興味も多少あって、以前にも調べて試作したことがあったので、切り替えること自体は難しくありませんでした。「Internet Explorer」が完全に過去のものになるまで、新しめの仕組みを取り入れることには慎重だったので、そのときは検討しただけで、採用する気にはなれませんでした。ダークモードに対応して閲覧者の滞在時間を引き延ばそうと夢想するより、コンテンツ自体を魅力化するほうがはるかに大事、という考えもありました。ライト・ダークの2択というのがそもそもナンセンス、なんてことも正直思うのですけれど、それはさておき。
この記事では、考えとか経緯とかだけでなく、方法についてもおおざっぱに触れることにします。わりとかんたんそうだな、と思ってもらえたら幸いです。でも、こういうことがちゃんと知りたいかたは、餅は餅屋、もっとくわしいサイトを参照すべきです。CSSに、
@media (prefers-color-scheme:dark){ }という記述を通常時の配色指定よりうしろに置きます。ダークモード時の配色をそこで指定します。さらに、HTMLのほうにも、
<meta name="color-scheme" content="light dark">というように、meta要素を加えておきます。
これで、さっきの画像2のように、ブラウザやOSの設定に応じて、ライトモード（通常時）、ダークモードの配色の出し分けができるようになります。
当サイトのテーマカラーとして位置づけているエメラルド色（《コリモセーズ／シラベル》のアイコン画像の下地とおなじ色、RGB値：24・144・132）を、ダークモード用の配色でどう使うか、とくに見出しのデザインで悩んだ覚えがあります。先述したコントラストの確保と、サイトとしての統一感、なんとか両立できたかなと。リンクの青色をどのくらい明るくするかの加減もだいぶ悩みました。
また、フッターのよつばの絵や外部リンクアイコンで使っているSVGファイルも、ダークモード対応の為につくりなおしました。
ブラウザ「Safari」はSVGファイルの扱いに難があるらしく、ほかのブラウザと違って、img要素として表示したSVGファイルの色指定がダークモード時に切り替わってくれません。ダークモード時の外部リンクアイコンが背景色に近すぎて視認性が悪くなっているのはその為です。SVGを別ファイルに分けているかぎり、現状どうにも解決できそうにありません。（わたしの手持ち環境での、本稿執筆時の状況です。最新版ではすでに改善されているのかもしれません。）ダークモード用のスタイルは補助的な位置づけです。ブラウザごとの挙動の違いのすべてに対応することはできないですし、この点は御了承ください。
ウェブフォント
ブラウザ側の表示設定をとくにいじっていなければ、当サイトの文字は、どの端末で見てもおなじ字体で表示されるはずです。サーバー側でフォントファイルを用意し、それをブラウザがダウンロードして表示させているわけです。サーバー側で用意したフォントをウェブフォントといいます。
当サイトでは、フリーフォントの「Rounded Mgen+ 1c」を、自前でサブセット化（必要な文字だけ抽出して切り分けること）して、ウェブフォントとして用いています。
フォントの詳細は配布サイトを参照していただくといいのですけれど、こちらでもかんたんに説明します。
漢字を含む日本語向けフリーフォントは、いろいろな種類が出ているようですけれど、手書き系のフォントを除けば、実質、ライセンスのゆるい数種類のフォントを改変したものが大半です。「M+ FONTS」というフォントをもとにしたフォントも多数あり、丸ゴシックふうに加工した「Rounded M+」もそのひとつで、ウェブフォントとしてすでによく知られています（「M PLUS Rounded」という名前で「Google Fonts」というウェブフォントサービスに登録されています）。「Rounded Mgen+」は、その「Rounded M+」の派生版で、収録文字数が多めになっています。「1c」というのは、字形のバリエーションのひとつを指す番号です。
「Rounded M+」の場合、JIS第2水準漢字の一部がはいっていない、という難点があります。たとえば「銅鑼」とか「箏による演奏」とか「箍がはずれる」とか「ちからが漲る」とかが漢字で書けません。それで「Rounded Mgen+」のほうを採用しています。こちらはJIS第4水準漢字まで網羅したフォントですので、収録文字に関しての心配がほぼ要りません。
これらのフォントは、ウェイト（太さ）が異なるファイルが7種類もあって、当サイトでは「regular」と「bold」の2種類に絞って使っています。「regular」の字体をそのまま太らせると、ちょっと頼りない見た目になるので、ファイル数が倍増することに眼をつぶって「bold」を併用しています。
「M+ FONT LICENSE」や「SIL Open Font License（OFL）」や「Apache 2.0 License」といったライセンスが適用されているフォント、またはパブリックドメインのフォントなら、安心してウェブフォントとしての利用や改変ができます（場合によってちょっとした条件はつきます）。「Rounded Mgen+」もそういうゆるいライセンスなのでありがたいことです。
閲覧している端末にウェブフォントとおなじ種類のフォントがすでにインストールされているなら、サーバーからダウンロードする必要がなくなり、表示が早くなります。当サイトももともとそうなっていましたけれど、2023年9月に後述の手入れをしたので、現在はインストールの有無にかかわらずダウンロードするようになっています。ちょっと心苦しいところですけれど、「Rounded Mgen+」をインストールしているようなひとというのは、フォントをたくさん集めているようなひとに限られるだろうと想像しますし、好きなフォントを自由にインストールして使える端末ばかりでもないですから、まあいいかなと。もちろん、フォントファイルがブラウザのキャッシュに残っている間は、ページをひらくたびにいちいちダウンロードするというようなことにはなりません。
当サイトで使うウェブフォントファイルを用意する手順を紹介します。くわしく触れる前に、箇条書きで先にまとめておきます。あくまでわたしの、当サイトでの事例であり、もともとのフォントファイルによっては不要な手順もあります。
- 「rounded-mgenplus-1c-regular.ttf」と「rounded-mgenplus-1c-bold.ttf」を、「ttfautohint」で処理し、ヒンティングを除去したフォントファイルをつくる。（コマンドラインオプション：「--dehint --no-info」）
- そのファイルを「FontForge」で開いて、「'maxp'テーブルを編集」、「ゾーン」の値を1にしてから、「フォントを出力」。
- 「サブセットフォントメーカー」で、上の手順でつくったフォントファイルをもとに、収録文字を絞ったフォントファイルを複数つくる。
- それらのファイルを「WOFFコンバータ」でWOFF2形式に変換する。
サブセット化とWOFF2コンバート
さて、日本語向けフォントは、特に漢字が大量に収録されていて、英文向けのフォントなどとくらべてファイルサイズが格段に大きくなっています。ふだん使わない漢字を省けばファイルサイズが減らせます。ウェブフォントとして利用する場合は、なるべく通信データ量を抑える為に、収録文字を絞ってサイズを減らすことが必須といっても過言ではありません。それがブラウザでの素早いページ表示にもつながります。
そこで、さしあたり必要になる文字だけを選び出したフォントファイルをつくることになります。たとえば、ふだんの作文で第3・第4水準漢字なんて使いませんから、それらを除外するだけで、もともとのファイルよりサイズがだいぶ減らせます。
特定の文字だけ抜き出したフォントファイルをつくるには、「サブセットフォントメーカー」というソフトが便利です。
当サイトでは、どのページでも使う「メイン」のフォントファイルと、せいぜい数ページでしか出番がないだろうと見込める文字を小分けにした「サブ」のフォントファイル群とを、標準ウェイト、太字ウェイトのそれぞれで用意して使っています。標準ウェイトの「メイン」に含まれている文字は3339文字（2023年9月末時点）で、ファイルサイズは約580キロバイトです。
とくに漢字について、どの文字を収録してどの文字を省くか、というのがいちばんの問題です。わたしの場合、「常用漢字または第一水準漢字」だけでは漢字が足りず、かといって第二水準漢字をすべて入れるとサイズが大きくなるので、サイトの準備段階からウェブフォントに収録する文字・ファイルの分けかたの吟味にだいぶ時間をかけていましたし、2023年9月には再検討を加えて文字をだいぶ削りました。そのあたりも含めて当サイトの事例を記事として載せるべきか迷ったのですけれど、収録文字の羅列の記事がおもしろいのかどうか、という以上に、なぜこういう文字を選択をしたか、ということを書いてみても、ひたすら個人的な言語感覚の表明の域を出ない上に、文字の選択に穴がまだまだ多いことを思い知ったので、公開は控えました。
本稿公開時点でサイトの全記事で使っている文字の種類は、およそ2200字を超えていて、漢字だけでもだいたい1900字くらいあります（「ゲームのチャットで表示できない文字」を挙げるなどの特殊な例は除いています）。1回しか登場していない文字種が300以上ある一方、10回以上登場している文字種も1000以上あります。ウェブフォントとして3000文字前後用意するのは、べつに過剰な分量ではないと思うけれど、削ろうと思えばもうちょっと削れる、といったところでしょうか。ただ、ひととおり広範囲の漢字を収めておくほうが、この文字は表示できるだろうかと気にしながら作文したり作詞したりするような哀しいことにならずに済みます。
と、そう思う一方、サイト開設以来、数文字あらたに加えたことが一度ならずあったので、結局のところ「この文字を今後使う可能性」をつぶさに検討するより、現在の全記事で使っている文字をすべて拾って1ファイルにまとめ、必要な文字が新たに出てくるたびにフォントファイルを更新する、という方法のほうがすっきりしていてよさそうです（そうした更新作業を半自動化できさえすれば）。
PCで使うフォントファイル（TTF形式やOTF形式）は、ブラウザで表示するぶんには要らない情報もたくさん含んでいるので、ウェブサイトでの表示用途に特化した「WOFF」というフォーマットに変換することで、ファイルサイズを削減できます。さらにデータ圧縮効率を高めた「WOFF2」がいまは主流です。これらの形式に変換してから、サーバーに置いています。
「サブセットフォントメーカー」の姉妹品「WOFFコンバータ」で、両形式に変換できます。入力ファイルを指定し、「WOFF2を作成する」にチェックを入れて「変換開始」するだけです。
これらのフリーソフトの入手先を以下に載せます。どちらもおなじサイトで配布されています。
それで、あとはフォントファイルを、CSSの「@font-face」を使った書きかたで指定すれば、ウェブフォントでの文書表示ができるようになります。複数のサブセットを使う場合、どの文字でどのフォントファイルを使うかをユニコード符号で指定することになりますけれど、そのへんの話は省くことにします。
とにかく、わたしはこういうふうに当サイト用のウェブフォントを用意していましたけれど、気になることがあったので、2023年9月、次項の「ぎざぎざ対策」も加えることになりました。
ぎざぎざ対策
一部のアウトラインフォントは、ウィンドウズの環境で表示した場合に、小さめのフォントサイズだと、ぎざぎざ（ジャギー）が出てつぶれぎみになります。広く使われている「M+ Fonts」の派生フォントにも、そういうフォントが多いようです。「Rounded M+」や、当サイトで使っている「Rounded Mgen+」も同様です。
このぎざぎざ、思っていた以上に批判の的になっているようで、「Rounded M+ は表示が汚い」という評も見られ、心が痛むと同時に、うちのサイトもフォントのぎざぎざのせいで閲覧を敬遠されたりしているとしたら機会損失だなあ、と不安になりました。自分が見るぶんには許容範囲だったし、「ぎざぎざが気になるならブラウザの設定をいじるなり文字サイズを大きくするなりしなさい」と思っていましたけれど、ウェブフォントとして用意している以上、対策すべき課題に思えてきたので、てこ入れをすることにしました。フォントの種類を別の丸ゴシック（たとえば「Kosugi Maru」など）に変える、という手は採らず、いまのフォントのままで解決できないか、いろいろ試しました。
ブラウザによっても違いがあるようですけれど、とりあえず先に結果を書くと、2023年9月16日、ぎざぎざ対策をサイトに反映させて、画像5のように変化しました。わたしとしてはこれをさほど改善や改良だとは捉えていないのですけれど、「ドットがにじんでいない前の表示に戻してくれー」ということをいわれる可能性より、「ぎざぎざで汚い」とケチつけられる可能性のほうが高そうなので、その対策はできましたし、まあ、悪くはないですね。
もちろん、閲覧環境によってはぎざぎざになるものもあります。「Pale Moon」というブラウザについては、いくらか調べたので後述します。
フォントのヒンティング情報を削除する
検索していろいろ調べてみたかぎり、問題の起きるフォントが持つ「ヒンティング」情報が、いまどきのウィンドウズの描画のしかたと折り合いが悪いから、というのが原因のようです。本来、小さいサイズのときにすっきりきれいに表示させる為の仕組みが、かえって災いしてしまっているらしい。むしろ、高解像度でのなめらかな表示が一般的になり、もはやヒンティングが役立つような状況も少なくなっていて、ヒンティング情報を除去したほうが見た目がよくなる場合がある、と。
さきほど書いたように、当サイトではフリーフォントを自前でウェブフォント化しているので、もとのフォント自体をいじることもできる状況にあります。フォントの仕組みはじつに難しく、「こうすればこうなる」という、上っ面の手順の話しかできませんけれど、どういうことをしたか、つらつら書いてみます。
前述の「サブセットフォントメーカー」で処理したとき、OpenTypeフォントのヒンティング情報は消えるものの、おそらくTrueTypeフォントのヒンティング情報は残るのだと思います。
フォントをいじってヒンティング情報を取り去るという解決方法に言及した記事は、後述するべつの解決策にくらべると少なめです。藁にもすがる気持ちでそれらを参照していろいろ試した末、「ttfautohint」というソフトでうまくいきました。以下のサイトで配布されています。
- ttfautohint
（英語）
GUIなら、「Dehint」にチェックをつける（ほかのほとんどの項目がグレーアウトする）。コマンドラインなら、「--dehint」オプションをつける。この設定でフォント（TTFファイル）を入出力するだけです。あるいは、（デフォルトの設定のままで）ヒンティング情報を自動でつけ直すだけでも、ぎざぎざ解消の効果が見られましたけれど、その場合、横書きの文字が縦方向にずれてがたがたになってしまうようなので、やはりヒンティングを除去するのがよさそうでした。
「ttfautohint」でヒンティング情報を消したフォントをウェブフォント化して、ブラウザ（Firefox）で表示させてみたところ、見た目上は問題ないのですけれど、ブラウザのコンソール（開発ツール）に「downloadable font: maxp: Bad maxZones: 0」云々といったエラーメッセージが出るようになってしまいました。
ヒンティング削除前後のフォントファイルのメタデータを確認してみると、「maxp」テーブルの「maxZones」の値が、0に変わっているのが確認できました。この値を1か2にしておかないといけないようです。（ただ、これが0になっていることによってどういう問題が実際に現れるのかは、わかりません。このままにしてもとくに誰も困らないかもしれませんけれど、サイトの作者としては気がかりな点となります。）
ここで「FontForge」の出番。これはフォントをつくったりいじったりできるソフトです。コリモフォントをつくったときにもちょっと触ったことがありました。
ヒンティング除去後のフォント（TTFファイル）を読み込み、「'maxp'テーブルを編集」で、「ゾーン」を1にする変更だけ加えて、「フォントを出力」します。（2ではなく1でおそらくよいはずですけれど、あまり自信がありません。）
これで、コンソールのエラー表示も出なくなりました。「maxZones」の値を変える前後でフォントの見た目に違いはほぼありませんでした。
CSSでごまかす手法の例
さて、前項のようにフォントそのものを修正して解決できるなら、それに越したことはありません。でも、それは自分でウェブフォントを用意しているからこそ採用できる方法であり、「Google Fonts」などのサービスでウェブフォントファイルを使うような場合だと、フォントをいじるすべがありません。そもそも、フォントファイルを気軽にいじるという発想にはなかなかならないものです。
フォントのぎざぎざを解消する手法を探すと、CSSによる方法のほうがすぐ見つかります。記事の順序が前後しましたけれど、わたしは最初こちらの手法で検討してみて、これではだめだなあ、と思ってさらに調べて、ようやく前述の方法に行き着いたのでした。
「CSSにたった1行書けばジャギーが改善」という枕詞とともによく紹介されているのが、
transform:rotate(0.03deg)というものです。これは、対象要素を0.03度だけ斜めに傾けることで、文字にアンチエイリアスがかかるようにするという小細工です。たしかに0.02度では（自分の使っているブラウザだと）効果が見られませんでした。あるいは0.05度くらいにしてもいいかも。いずれにせよ0.03度程度の傾きは、パッと見た限りではわかりません。
この手法には副作用があります。フォントだけを傾けることはできず、あくまで要素の区画全体を傾けるので、ほかの部分にしわ寄せがきます。まず、枠線や（リンクなどの）下線がぼやけてしまいます。よく見ればわかるレベルだし、ズーム機能で縮小表示すると、ぼやけのせいで枠線や下線が太って醜くなります。
また、これを広範囲に（たとえばbody要素に）適用すると、ページの横幅のとりかたによっては、横幅が広くなって横スクロールバーが出てしまうし、要素内に含まれる画像も傾いてぼやけてしまう、という副作用があるのは有名です。こちらは、p要素とかli要素とかに絞って小刻みに適用することで、ある程度は防げます。
いずれにしても、のちにCSSを微調整したときに、この小細工が思いがけぬところに影響して、泥沼にはまりかねません。つまりメンテナンス性が下がります。
文字だけでは伝えづらいので、画像6で図示してみました。……こんなもの載せて、ウェブデザイナー向け情報サイトじゃないんだから、という感じですけれど、勢いで用意してしまいました。
左が対策前の状態で、CSSを適用した状態をその右に示しました。「transform:rotate」と「transform:skewY」2種類の適用例をそれぞれ示しています。それぞれの本来の効き目がわかりやすいよう、10度ずらした状態を上側に示しました。「rotate」は要素を回転させます。「skewY」は要素を垂直方向に歪ませます。
それを0.03度にすると、フォント（と下線）にアンチエイリアスがかかった以外、もともとの状態とほぼおなじに見えます。この、
transform:skewY(0.03deg)というやりかたのほうは、検索したかぎりでは、世間であまり（まったく？）紹介されていないようです。要素を回転させて傾けるより、縦方向にだけ平行四辺形の形に歪ませるほうが、横幅に影響が出ないぶん有用なのではないかと思うんですけれど、どうなんでしょう。どちらもフォントにアンチエイリアスをかける効果はほぼおなじに見えますし、対応しているブラウザが少ないということもないはず。
それはともかく、いずれにせよリンクの下線がにじむのを回避できそうもないのが致命的。いや、ほとんどの閲覧者は気に留めないかもしれないし、たしかに即効性のある手法ではあります。でも、そもそも表示に問題のない（あるいは別のフォントを適用している）閲覧環境にも無用な小細工を弄することになり、表示品質が逆に下がることにもなり得るし、やはり当サイトでは採用に踏みきれるものではありませんでした。
「Pale Moon」で表示確認をしたときの話
（この項は、2023年11月21日に追加しました。）
もし（ウィンドウズPCで）「Pale Moon」というブラウザで当サイトを閲覧して、フォントの横画が抜けるなどして読みづらい場合、ここの記述が参考になるかもしれません。
「Pale Moon」の初期状態ではなめらかな表示なのに、ちょっと使っているうちに（とくにそれらしい設定項目をいじっていないのに）、なにかのはずみでフォントの表示がぎざぎざになることがあります。検証したところ、プロファイルのフォルダ以下にある「user.js」に、
user_pref("gfx.blacklist.direct2d", 1);を書き加えると治ることがわかりました。バージョン32.5で確認。もっと古いバージョンでも同様のようでした。
……「Pale Moon」は、「Firefox」の派生ブラウザで、メジャーなブラウザとは異なる独自の描画エンジンを実装しているそうです。これで当サイトの動作を確認しておこうと思って試したわけです。
そうしたら、小さめのフォントサイズで横の画線が消えるひどい表示に愕然。フォントのヒンティングを削除したのが悪影響を及ぼしていることがわかりました。CSSでごまかしてなめらかにする手法も効き目なし。
ほかの環境でもこういうことがあり得そうだと思い、最小限の（縦方向ががたがたにならないぎりぎりの）ヒンティングをつけ直したフォントファイルに差し替えることを検討もしました。しかし、いま書いたように、どちらかというとブラウザの動作のほうに問題があるように見えるし、そもそも利用者もごく少数なので、対処法を書くだけにとどめて（「Pale Moon」をあえて使うようなひとなら、なんなりと自力で対処できるでしょうし）、ヒンティングの削除をやめるのは思いとどまりました。なにしろ「ttfautohint」でヒンティングをつけ直した場合、3割ぐらいファイルサイズが増えてしまって都合が悪い、というのもあります。
フォントの表示には、ややこしい問題が多いんだなとつくづく思い知らされました。
よつばグリフ
こういったウェブフォント周りのてこ入れをしたついでに、自作のフォントもつくってしまいました。といっても「✤」（U+2724）と「❖」（U+2756）の2文字だけです。「よつばグリフ」と名づけています。
リストのマーカー（箇条書きの頭につける点）は、もともと、菱形の「◆」を使うスタイル指定をしていました（入れ子のリストは小さな白丸、小さな黒丸になります）。ダークモード対応と同時期に、よつばっぽい「❖」に変えました。これは本当は、よつばではなくてダイアモンドの記号ですけれど。ところが「Rounded Mgen+」での「❖」の字形がいまひとつだったので、差し替えることにしました。せっかくだから自力でデザインしてしまおうということで、「FontForge」でTrueTypeフォントをつくりました。
2文字つくっただけなので手順の詳細は省きますけれど、字形を画像で描いて「FontForge」に取り込んで、「自動トレース」でアウトラインを生成して、……というやりかたです。フォントファイルを書き出してからウェブフォントにするまでの手順は、ほぼ先述のとおりです。
いまのところ、菱形っぽい「❖」ではなく、アスタリスク文字の一種に割り当てた「✤」のほうをリストのマーカーに使っています。この「✤」は、ファビコンのよつばを模した、ちょっと斜めに傾げた形です。
昨今は絵文字も普通に使われるようになっていて、よつばの絵文字「🍀」もモダンブラウザ任せでカラフルに表示できるはずですけれど、まだちょっと、ユニコードの符号位置が5桁の新しめの文字を使うのは怖いなという気分です。閲覧環境による差も大きいですし。