当サイトのデザインとウェブフォント

「コリモセーズ／シラベル のウェブサイト」の各ページのデザイン、とくに視覚的な装飾、外観に関することを書きます。どういう考えで現在のデザインを採用しているかとか、この数年でどんな調整を加えてきたかとか、フォントのこととかを取り上げます。

もちろん、ページの構成のしかたや、どこにどういうリンクを用意するか、読み上げソフト類を使うひとに不親切なところはないか、などなどいろんなことがデザインに絡み合ってくるわけですけれど、それはいつか別の記事で書くことがあるかもしれません。本稿では、（モダンブラウザで閲覧したときの）外観上のデザインの話に絞ります。

どちらかというと、サイトの更新で見た目に関する変更をしたときに、詳細を書く場所が欲しかったのでつくったページです。技術的なことにもすこし触れます。学習目的でちゃんと知りたいかたは、餅は餅屋、もっとくわしいサイトを参照してください。

更新があったり思うところがあったりすれば書き足していきます。内容に濃淡、偏りがあります。解説というよりエッセイとして読んでいただければ。

サイトの見た目に関するおもな更新履歴

日付の新しい順です。微調整については取り上げていません。サイト開設から2022年まで、外観のスタイルのことに限れば、案外ここに挙げるべき大きな更新がなかった気がします。

• 2024年8月22日　ウェブフォントのファイルを全面的に修正。印刷時のみ、外部リンクにURL文字列を添えるようにした。
• 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択というのがそもそもナンセンス、なんてことも正直思うのですけれど、それはさておき。（コントラストを上げるモードや反転モードでも色が変わるから、「ライト・ダークの2択」と書いてしまうと、語弊があるというか短絡的かもしれませんけれど。）

方法についておおざっぱに触れます。わりとかんたんそう、と思ってもらえたら幸いです。CSSのほうに、

@media (prefers-color-scheme:dark){ }

という記述を通常時の配色指定よりうしろに置きます。ダークモード時の配色をそこで指定します。さらに、HTMLのほうにも、

<meta name="color-scheme" content="light dark">

というように、meta要素を加えておきます。

これで、さっきの画像2のように、ブラウザやOSの設定に応じて、ライトモード（通常時）、ダークモードの配色の出し分けができるようになります。

当サイトのテーマカラーとして位置づけているエメラルド色（《コリモセーズ／シラベル》のアイコン画像の下地とおなじ色、RGB値：24・144・132）を、ダークモード用の配色でどう使うか、とくに見出しのデザインで悩んだ覚えがあります。先述したコントラストの確保と、サイトとしての統一感、なんとか両立できたかなと。リンクの青色をどのくらい明るくするかの加減もだいぶ悩みました。

ダークモードで背景色を漆黒に、文字色を真っ白にすると、閲覧環境によって、かえってまぶしく感じることもあるので、心持ち薄めに調整しています。背景色に限らず、年に1回か2回くらい、誰も気づかない程度に色の指定をいじることがあります。

また、フッターのよつばの絵や外部リンクアイコンで使っているSVGファイルも、ダークモード対応の為につくりなおしました。

ブラウザ「Safari」はSVGファイルの扱いに難があるらしく、ほかのブラウザと違って、img要素として表示したSVGファイルの色指定がダークモード時に切り替わってくれません。ダークモード時の外部リンクアイコンが背景色に近すぎて視認性が悪くなっているのはその為です。SVGを別ファイルに分けているかぎり、現状どうにも解決できそうにありません。（わたしの手持ち環境での、本稿執筆時の状況です。最新版ではすでに改善されているのかもしれません。）ダークモード用のスタイルは補助的な位置づけです。ブラウザごとの挙動の違いのすべてに対応することはできないですし、この点は御了承ください。

ウェブフォント

ブラウザ側の表示設定をとくにいじっていなければ、当サイトの文字は、どの端末で見てもおなじ字体で表示されるはずです。サーバー側でフォントファイルを用意し、それをブラウザがダウンロードして表示させているわけです。サーバー側で用意したフォントをウェブフォントといいます。

採用しているフォント

当サイトでは、フリーフォントの「Rounded Mgen+ 1c」を、自前でサブセット化（必要な文字だけ抽出して切り分けること）して、ウェブフォントとして用いています。

• Rounded Mgen+ (ラウンデッド ムゲンプラス) | 自家製フォント工房

フォントの詳細は配布サイトを参照していただくといいのですけれど、こちらでもかんたんに説明します。

漢字を含む日本語向けフリーフォントは、いろいろな種類が出ているようですけれど、手書き系のフォントを除けば、実質、ライセンスのゆるい数種類のフォントを改変したものが大半です。「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+」もそういうゆるいライセンスなのでありがたいことです。

2024年8月にウェブフォントを更新した際、「regular」のほうのみ、「Rounded-X Mgen+ 1c」に変更しました。通常バージョンに比べて「X」は、角の丸みがわずかに強めになっています。この些細な変更については、以降の記述に反映していません。

なぜウェブフォントを使うのか

そもそも、なぜウェブフォントを使うのか、という問いがあります。

収録文字数の多い日本語フォントは、どうしてもファイルサイズが大きくなってしまいます。ウェブサイトにアクセスするひとがみんな、よい回線環境を持っているわけではありません。1枚の画像のダウンロードにさえ時間がかかる、という環境では、ウェブフォントの読み込み待ちが閲覧者にとって苦痛となり得ます。

だから、ウェブフォントなんか使わずに、各ユーザーの閲覧環境で使われている既定のフォントで表示すべきだ、という考えかたもあります。

ただ、いちばん肝腎な大前提は、ウェブフォントが読み込まれなかった状態でも、あるいはスタイルがすべてブラウザの初期値になっていても、コンテンツの意図が伝わるようなまっとうな文書をつくることです。そうなっていれば大きな間違いは起こらないはずです。

その前提の上で、コンテンツをつくる側も読む側も、ページの表示をカスタマイズする手段を各自の判断でうまく利用すればいいと思います。昨今のブラウザには「リーダーモード」なんていうのも用意されています。誰にでもおなじように自分の設計したとおりにページが表示される、なんて信じている制作者はいないでしょう。だからといって、スタイルづけをあきらめてプレーンテキストだけを届けるのでは、ただの電報になってしまいます。（……いや、むしろただの電報でいい場合もあるかもしれません。ソーシャルメディアも似たようなものですし。）

紙の本やPDFファイルのようにはデザインが固定できませんし、音声読み上げソフトでページを読むひとにとって視覚的な演出は関係のないことです。制作者がどこまで見た目のスタイルを突き詰めるべきかについては結局、程度の問題、趣味の問題になってしまいます。制作者はそれぞれの理由のもとで（あるいはウェブの流行り廃れにもいくらか足並みを揃えつつ）、自身のサイトに似合うスタイリングとともにコンテンツを届けようとします。

当サイトのスタイルは、角丸を多用しているから、フォントのほうもそれに馴染むものを使いたい、と思いました。別の節に書いたように、ページの見栄えも、自分の意思を隅々まで反映させたものにしたい思いがあり、フォントだけ例外にするのもおかしいわけです。紙の本の発想に過ぎないといわれれば、そうなのかもしれません。

それと、当サイトはサーバー外のリソースをたくさん読み込むサイトではなく、当世の（アプリ的な）ウェブサイトよりページ表示は素早く済むはずなので、ウェブフォントでちょっと重くなってもそれほどひどいことにはなるまい、とも思います。ただ、ひどいことというのがどれくらい想定できているかが怪しく、日本在住の平均的（よりすこし貧弱）なユーザーの環境を基準にしてしまっている面は否めません。

それともうひとつ。ユーザーの好きなフォントで読めるようにすべし、というのは正論だとはいえ、モバイル端末だと、PCのように設定をカスタマイズする余地があまりない傾向があると思います。たとえばアイフォーンに好きなフォントをインストールしてブラウザで表示させているユーザーがどれくらいいるのかどうか。そう思うと、やはりコンテンツ提供者の側からフォントを送りたくなってしまいます。

逆に、フリーフォントが好きで手書き系フォントなどをインストールして閲覧環境の既定値にしているひともいると思います。第2水準漢字をカバーしていないフォントはけっこうあります。そのようなフォントで表示できない漢字が当サイトの記事にあった場合は、端末のシステムフォントが代わりに使われるのだと思いますから、読めるには読めるとしても、おそらく不恰好な表示になるでしょう。これも、コンテンツ提供者の側からフォントを送りたくなる理由になります。なんだかおせっかいみたいですけれど。

必ずしも「見せ」の効能だけを考えてウェブフォントを採用したわけではなく、文章コンテンツとセットで考えています。とはいえ、自分で用意しているウェブフォントに入れていなかった文字を記事のなかに含めたまま、しばらく気づかずにいたことが一度ならずともあるから、あまり大きなことはいえません。

フォントの読み込み

閲覧している端末にウェブフォントとおなじ種類のフォントがすでにインストールされているなら、サーバーからダウンロードする必要がなくなり、表示が早くなります。当サイトも以前はそうなっていましたけれど、2023年9月以降は、インストールの有無にかかわらずダウンロードする設定にしました。

本来、あまり好まれないやりかたであり、ちょっと心苦しいところですけれど、「Noto Sans」（「源ノ角ゴシック」）などと違って、「Rounded Mgen+」をインストールしているようなひとというのは、フォントをたくさん集めているようなひとに限られるだろうと想像しますし、さっき書いたように好きなフォントを自由にインストールして使える端末ばかりでもないですから、まあいいかなと。もちろん、フォントファイルがブラウザのキャッシュに残っている間は、ページをひらくたびにいちいちダウンロードするというようなことにはなりません。

ページの内容が表示されるタイミングより、ウェブフォントの読み込みが終わるタイミングが遅れることが多々あります。そのときどうするか、待つのか、代わりのフォントで一時的に描画するのか、それともあきらめるのか。これについてはブラウザ任せにしています。ほか、フォントファイルの読み込みの優先順位を上げる、などいろいろ最適化のテクニックがあって、いろいろ試行錯誤しましたけれど、とくになにもしなくても大差ないようでした（あるいは違いに気づけていないだけかも）。

ウェブフォントが読み込まれなかった場合の、代わりとなるフォントもCSSに指定する必要があります。当サイトではシンプルに「sans-serif」とだけ指定しています。サンセリフというのは日本語フォントでいえばゴシック体のことです。端末のシステムフォントのうち、なんでもいいけれど、（明朝体などではなく）ゴシック体のフォントで表示しておくれ、という意味の指定です。「リーダーモード」などのときは別のCSSに切り替わる（と思う）ので、この指定は効きません。

ウェブフォントファイルを用意する手順の概要

当サイトで使うウェブフォントファイルを用意する手順を紹介します。くわしく触れる前に、箇条書きで先にまとめておきます。あくまでわたしの、当サイトでの事例であり、もともとのフォントファイルによっては不要な手順もあります。

つけ加えると、一般的には「Google Fonts」や「TypeSquare」などのようなウェブフォント提供サービスを利用するのが主流です。自前でウェブフォントをつくってサーバーに置く、というのは「自分の手ですべてコントロールしたい」ひと向けです。

1. 「rounded-mgenplus-1c-regular.ttf」と「rounded-mgenplus-1c-bold.ttf」を、「ttfautohint」で処理し、ヒンティングを除去したフォントファイルをつくる。（コマンドラインオプション：「--dehint --no-info」）
2. そのファイルを「FontForge」で開いて、「'maxp'テーブルを編集」、「ゾーン」の値を1にしてから、「フォントを出力」。
3. 「サブセットフォントメーカー」で、上の手順でつくったフォントファイルをもとに、収録文字を絞ったフォントファイルを複数つくる。
4. それらのファイルを「WOFFコンバータ」でWOFF2形式に変換する。

サブセット化とWOFF2コンバート

さて、日本語向けフォントは、特に漢字が大量に収録されていて、英文向けのフォントなどとくらべてファイルサイズが格段に大きくなっています。ふだん使わない漢字を省けばファイルサイズが減らせます。ウェブフォントとして利用する場合は、なるべく通信データ量を抑える為に、収録文字を絞ってサイズを減らすことが必須といっても過言ではありません。それがブラウザでの素早いページ表示にもつながります。

そこで、さしあたり必要になる文字だけを選び出したフォントファイルをつくることになります。たとえば、ふだんの作文で第3・第4水準漢字なんて使いませんから、それらを除外するだけで、もともとのファイルよりサイズがだいぶ減らせます。

特定の文字だけ抜き出したフォントファイルをつくるには、「サブセットフォントメーカー」というソフトが便利です。

当サイトでは、どのページでも使う「メイン」のフォントファイルと、せいぜい数ページでしか出番がないだろうと見込める文字を小分けにした「サブ」のフォントファイル群とを、標準ウェイト、太字ウェイトのそれぞれで用意して使っていました。標準ウェイトの「メイン」に含まれている文字は3339字（2023年9月末時点）で、ファイルサイズは約580キロバイトでした。

2024年8月には、「メイン」に含まれている文字を2855字にまで減らしました。標準ウェイトのファイルサイズは500キロバイトくらいに減っています。太字と合わせると依然1000キロバイトを超えるのですけれど、管理の煩雑さを避けるなら、このあたりがぎりぎりの最適化かなという感じがします。標準・太字をそれぞれ用意している点がボトルネックといえます。

いまも「メイン」と「サブ」の数ファイルに分けていますけれど、下記の「長い話」のようにこまかいことを考えていると何日も浪費してしまうので、サイト内の全ページで使っている文字を洗い出してひとまとめにするようにしました。常用漢字については、まだサイトで使っていなくてもほとんど入れました。すでに前からウェブフォントに含めていたのに現時点で出番のない漢字群は、ユニコード順に200文字ずつ切り分けて数個の別ファイルにしました。

ギリシャ文字、キリル文字、半角カナほか一部の記号は、引き続き別ファイルのほうに振り分けています。それらの文字が出ないページの文章は、現状ほとんどメインのフォントファイルのみで表示できると思います（絵文字は対象外）。

PCで使うフォントファイル（TTF形式やOTF形式）は、ブラウザで表示するぶんには要らない情報もたくさん含んでいるので、ウェブサイトでの表示用途に特化した「WOFF」というフォーマットに変換することで、ファイルサイズを削減できます。さらにデータ圧縮効率を高めた「WOFF2」がいまは主流です。これらの形式に変換してから、サーバーに置いています。古い「WOFF」形式のほうは、もう用意しなくてもいいとは思うのですけれど、手間がたいして変わらないし、サーバーの残り容量に困っているわけでもないので、2024年のうちは現状維持です。2025年以降は「WOFF」をなくすかもしれません。

「サブセットフォントメーカー」の姉妹品「WOFFコンバータ」で、両形式に変換できます。入力ファイルを指定し、「WOFF2を作成する」にチェックを入れて「変換開始」するだけです。

これらのフリーソフトの入手先を以下に載せます。どちらもおなじサイトで配布されています。

• サブセットフォントメーカー
• WOFFコンバータ

2024年8月のフォントファイル更新の際、WOFF2に変換できる高性能なウェブアプリはないかなと物色してみましたけれど、CJK言語圏をあまり考慮していなさそうな設計だったりするし、ウェブアプリのサイトがなくなったとき困るから、結局上記のソフトを引き続き使っています。

それで、あとはフォントファイルを、CSSの「@font-face」を使った書きかたで指定すれば、ウェブフォントでの文書表示ができるようになります。複数のサブセットを使う場合、どの文字でどのフォントファイルを使うかをユニコード符号で指定することになります。これがまためんどくさいので、文字一覧からCSSを生成できるかんたんなスクリプトを用意して、手間を減らしています。

こういうふうに当サイト用のウェブフォントを用意していましたけれど、気になることがあったので、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」の出番。これはフォントをつくったりいじったりできるソフトです。コリモフォントをつくったときにもちょっと触ったことがありました。

• FontForge Open Source Font Editor（英語）

ヒンティング除去後のフォント（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割ぐらいファイルサイズが増えてしまって都合が悪い、というのもあります。

フォントの表示には、ややこしい問題が多いんだなとつくづく思い知らされました。

（2024年8月9日追記：）「フォントの横画が抜けて見える」状態で、設定をいじらず新しいPCに「Pale Moon」をまるごとコピーしたところ、新しいPCでは問題なく表示されました。OS側の環境も要因なのでしょうか。なんだかよくわからなくなり、くわしく再検証することはあきらめました。申し訳ないところですけれど、この項の記述は公開すべきほどのものでもなかったのかもしれず、あまり真に受けないようお願いします。

よつばグリフ

こういったウェブフォント周りのてこ入れをしたついでに、自作のフォントもつくってしまいました。といっても「✤」（U+2724）と「❖」（U+2756）の2文字だけです。「よつばグリフ」と名づけています。

リストのマーカー（箇条書きの頭につける点）は、もともと、菱形の「◆」を使うスタイル指定をしていました（入れ子のリストは小さな白丸、小さな黒丸になります）。ダークモード対応と同時期に、よつばっぽい「❖」に変えました。これは本当は、よつばではなくてダイアモンドの記号ですけれど。ところが「Rounded Mgen+」での「❖」の字形がいまひとつだったので、差し替えることにしました。せっかくだから自力でデザインしてしまおうということで、「FontForge」でTrueTypeフォントをつくりました。

2文字つくっただけなので手順の詳細は省きますけれど、字形を画像で描いて「FontForge」に取り込んで、「自動トレース」でアウトラインを生成して、……というやりかたです。フォントファイルを書き出してからウェブフォントにするまでの手順は、ほぼ先述のとおりです。

いまのところ、菱形っぽい「❖」ではなく、アスタリスク文字の一種に割り当てた「✤」のほうをリストのマーカーに使っています。この「✤」は、ファビコンのよつばを模した、ちょっと斜めに傾げた形です。

昨今は絵文字も普通に使われるようになっていて、よつばの絵文字「🍀」もモダンブラウザ任せでカラフルに表示できるはずですけれど、まだちょっと、ユニコードの符号位置が5桁の新しめの文字をサイトの文書で使うのは怖いなという気分です。閲覧環境による差も大きいですし。（友人とチャットアプリでやりとりするときは平気で絵文字を使いまくっていますけれどね。）