エンジニア座談会Vol.05 JamstackとWebフォントの機能

はじめに

　本記事はフロントエンドに関わる人々のためのメディア「CodeGrid」（https://www.codegrid.net/）より厳選した記事をお送りします。

　前回はWebフォントがどれくらい普及されているかということや、仕組みなど基本的な知識や仕組みが話題に上がりました。日本語のフォント化は欧米のそれに比べて容量が多くなることや、その適用の高速化を図るため、さまざまな仕組みが策定されていることが話されました。 今回はJamstackとWebフォントの話題を中心にお届けします。OpenType機能などこれからのWebフォントに期待される機能の話も登場します。 引き続き、ゲストの鈴木さんとのWebフォント談義をお楽しみください。

（※本記事は、2022年1月下旬に収録した座談会をもとにしたものです。記事中で話されている情報は、座談会当時の内容になります。また、記事へのリンク先が有料記事の場合もありますので、あらかじめご了承ください）

ゲスト

ビルド時にフォントを埋め込む問題点

中村：Jamstackの場合のフォントの埋め込みはどうでしょう。 Jamstackでは、事前にビルドプロセスでコンテンツを埋め込んだ状態のHTMLを作ってしまって、ユーザーのアクセスに対しては速いサイトを作るという手法です。 そうなってくると最終成果物は静的サイトなので、動的サブセッティングするというのはムダだなと思っていて。そういうのをビルド時に事前に埋め込んだりしたいなと思っているんです。こんなイメージですね。

Webフォントを埋め込んだ静的なHTMLを生成するイメージ

ただ、鈴木さんからもお話あったように（編集部注：前回のお話で出てきました）、ライセンスの問題があるのかなと思うのですが。

鈴木：仕組みとしては、おっしゃるようなことはできることはできるんですよ。僕が関わっているFONTPLUSの場合でもAPIがあるので、文字列を投げるとサブセット化されたものをzipで返すというようなことはできる。まあ、あんまり洗練されてはいないですけど、仕組みとしては不可能ではない。

でも、やっぱり、問題になるのはライセンスですよね。Webフォントのサービスって、どこもいろんなフォントメーカーからフォントを預かって、それを配信しているという立場なので、ちゃんとプロテクトをかけないといけない。

ビルド時に埋め込むとかそういう使い方もフォントメーカーと契約できればできると思いますけど、現状だとできていないし、もしできたとしても高くなりそうなところはありますよね。

中村：そうですよね、Jamstackのように事前に作って埋め込むのって大規模なサイト向けなので、どうしても高くなってしまうかなと。僕が個人サイトで「このおしゃれなフォントをちょっと使いたくて、お金多少かかってもいいんだけど」みたいなのだと、ちょっと難しいのかなと思います。

鈴木：そうですね。ちょっと見合わないんじゃないかなと。

僕もフォント業界に入ってみて思ったんですけど、活字の歴史に比べるとWebフォントはまだ新しい技術なので、Webでどういうニーズがあるのかというところまで、なかなか思い至ることができていないという印象があります。

なので、そういう（Webサイトで埋め込んで使いたい）話が来たときに、見積もりが難しかったり、価格感が合わなかったりしがちなんじゃないかと。もうちょっと時間が経って、Webフォントの仕様と実装が洗練されてくれば、フォントメーカーのライセンシングの考え方が変化する可能性はあるんじゃないかなと思います。

動的にサブセット化をする時間コストをどう考える？

矢倉：ビルド時に必要なもので静的サブセットのフォントがライセンス的に可能としても、僕が気になっているのが、ビルド時間はどれくらいかかるのかというところですね。

Jamstackだと、基本的に静的にビルドしてそれを配置するというのをコアな思想として持っているんですけど、ページコンテンツが増えればページを作るビルド時間も増えていくわけです。それにさらにフォントを作成する時間があってとなると、コストが全然見合わないんじゃないかなと思うんですよね。

フォントのサブセットって、それなりに短い時間で作成できるものなんでしょうか？

鈴木：そうですね、速いといっていいかわからないですけど、シンプルなサイトだったら、気にならない程度だと思います。

ただ、今FONTPLUSは動的サブセットで返しているのがWOFFなんですね、いい加減WOFF2を出しましょうよ、ということで試しているのですが、WOFFに比べて生成にかなり時間かかってしまうんです。現状、IEを考えないのであれば、WOFF2でいきたいところだと思うので、そう考えると大きいサイトだとネックになる可能性はあるかなと思っていて。

矢倉：Googleが静的サブセッティングを採用しているのも、そこが理由の一つかもしれないですね。その話を聞くと。

中村：僕も動的サブセッティングは結構速いなという印象があるので、ビルドのタイミングで作ってくださいみたいなことがAPI的にできれば、Jamstackという用途でも使いやすいのかなと思っていたんですけどね。ライセンスの問題があるにしても。

鈴木：あとは、動的にサブセット化するときに、どこまで含めるか。グリフのデータだけじゃなくてOpenType機能をどこまで含めるかも多少関係してくるのかなと思っています。

現状のWebフォントサービスって、ファイルサイズとかサブセット化にかかる時間とか考えて、使わなそうなOpenType機能を落としちゃっていることがよくあるんですよ。そのあたりの、OpenTypeの機能をどこまで使うのかは関係してくると思いますね。

矢倉：なるほど。

日本語フォントでOpenType機能をどう活かせるのか

矢倉：OpenType機能は違う字形をフォントに含めることが多いので、機能を入れれば入れるほどフォントのファイルサイズが大きくなる。だから、鈴木さんがおっしゃったように、何を使うのか、どこまで含めるのかっていうのが課題になっているんだと思います。

たとえば、Noto Sans CJKも、インストール可能なもとのフォントファイルに比べて、Webフォントでは使えるOpenType機能が削られていますね。そうしてファイルの容量を少しでも減らしているんだと思います。

鈴木：そうですね。

矢倉：それで、そのOpenType機能をCSSから制御できる、font-feature-settingsというプロパティがあります。

• font-feature-settings – CSS: カスケーディングスタイルシート | MDN

小原：font-feature-settingsって、なにか一つを指し示しているんじゃなくて機能全体を指していて、その中の機能で何を使うかを指定してください、っていうことなんですよね？

矢倉：そうです。OpenType機能はいっぱい数があるんですが、font-feature-settingsはその機能ごとにオンオフできるんです。たとえば、Noto Sans CJKにはプロポーショナルメトリクスの機能paltに対応しているんですが、それをオンにしたかったら、font-feature-settings: "palt" onと書くとオンにできます。

中村：OpenType機能は、現場でCSS書くときに使います？

國仲：指定があれば書きますけど、なければ特に書かないですね。個人的なサイトでは場所によっては使います。ただ、font-feature-settingsってプロパティが使いにくいんですよね。

鈴木：そう、使いづらい。

國仲：一個変えたら、全部上書きされて死ぬという。font-variantプロパティが、それをいい感じにしてくれる。Open Type機能を個別に指定するプロパティがあるんですよ。

CJKとかは厳しいですよね。

矢倉：ですよね。ちょっと使いにくいプロパティを使わざるを得ない状況になっていますね。

OpenType機能はpaltだけじゃない

鈴木：現実的にはpaltがとにかく流行りすぎちゃった、という気がしています。font-feature-settingsには、文字幅を変えるにしても、約物*だけ変えるとか、前後関係に応じて変えるとかいろいろあるんですけど、とにかく「font-feature-settingsといえばpalt」みたいな定着の仕方をしている気がしていて。

そのあたりの機能が「もうちょっと、いろいろあるんだよ」というのがわかってもらえるといいなと思うんですけど。でもそのためにはフォントにそのOpenType機能を搭載してもらわなきゃいけないというのもあるし。

まあ、フォントにそもそも機能入っていないとか、そもそもいろいろな機能が知られていないとかが、課題かなという気がしますね。

國仲：FONTPLUSのフォントでOpenType機能はなにが使えるかなと思ってみていたんですけど、chws（Contextual Half-width Spacing）が使えるのはちょっとびっくりしました。

鈴木：chwsは、横書きのテキストで全角の約物が特定の組み合わせで連続した場合の空きを調整するというものですね。これはいいんですよ、すごく。

デフォルトの状態（上）と、chwsを適用した状態（下）

矢倉：これ、いつ対応したんでしたっけ？

鈴木：対応したのは2021年です。結構早かったですよ。ちょっと自慢です（笑）。

國仲：これはわりと、すごいなと思っていますね。text-spacing: trim-adjacent的なものが、これ使えばできる。

鈴木：そうなんですよね。paltにしてもchwsにしても、こういうのが以前だとJavaScriptで無理やりやったりとか、正規表現で走査して<span>で囲ってスタイル当てたりしてがんばってやっていたのが、最近は標準技術としてどんどんできるようにやれるようになったので楽しいですよね。

OpenType機能って、今もいろいろな機能が「こうしたいよね」と言って積極的に提案されているかんじがあって。まだまだ機能を拡張できる余地があるので、楽しみなところですね。

國仲：本文にpaltを使っているのを見ると、ＭＳ Ｐゴシックを思い出すんですよね。なんでもかんでもガチガチに詰めていくみたいな。好みの問題もありますけど。

鈴木：うんうん。あれ、辛いと思うんだけどね。

中村：僕もそう思いますね。おばらさんはデザインするときに、そのあたりってどこまでやっています？

小原：本文は文字詰めはやりたいとは思わないですね。とはいえ、いわゆる箱組*がWeb上でできるかというと、現状仕様上ではすんなりはできない、ブラウザの実装ではできないはずなので。そうなると、paltするしないにかかわらず、きれいに四角くはなりづらいので悩ましいところです。

和欧文の混植に力を発揮する仕様

小原：Web上のコンテンツって、和欧文の混植がとてもされやすいですよね。たとえばCodeGridなら、コードもあるし、仕様とかのアルファベットと日本語が混じりやすいっていうのがある。そのあたりって、箱組というか、仮想ボディの四角いリズムというのが本当に本文に対して完全に適用されるのかというと、いまいち僕はそこまで踏み込んで考えるところには至っていないので、していない。

まあ、見出しは、文字が大きくなるとやっぱり字間がパラパラしちゃうというのはあるので、そこはシュッとまとまっていてほしいので指定するんですけど。

ただ、指定したいという思いがあっても、それを上手に実装の方に伝えるのが難しくて、そのへんは悩ましいところですね。一律、全部かけてくださいというのは簡単だけど、あのときはこうでこのときはこう、という場合分けをするのは難しい。

鈴木：和欧混植の話で言うと、CSSの@font-faceのディスクリプターが結構実装されてきていて、おもしろいですね。たとえば、ascent-overrideとdescent-overrideでアセンダとディセンダのバランスを変えられたり、size-adjustで数値上のフォントサイズはそのままで見た目上のサイズを変えられたりします。

そうすると、それを使うと和欧混植のサイズ調整、たとば欧文だけ5%大きくするみたいなことができるようになるんですよね。ブラウザの実装状況を見ても、あとはSafariがくれば、みたいなかんじになってきています。

@font-faceは最近いろいろ増えて、これも楽しいなという気がしていますね。

小原：もともとあのあたりって、グラフィックツール周りの混植設定の流れからきているんですかね？

鈴木：いや、これはパフォーマンス関連からみたいですね。欧文って字幅がまちまちだから、フォールバックフォントからWebフォントに切り替わったときに、行数が変わっちゃってレイアウトシフトが起こってやだよね、みたいな。それで、フォールバックフォントとWebフォントで同じ見た目、同じ字幅になるように、ということで取り上げられていることが多いみたいです。

小原：そうですよね、「I」と「W」じゃ、だいぶ字幅が違いますからね。

鈴木：ただ、実装している人たちはそういうモチベーションでやっているのかもしれないんですけど、CJKを使う僕たちの立場からすると、それってやっぱり和欧混植で力を発揮するなあと思っていて。そういう観点からの話ってあんまり見たことはないんですけど。

逆に日本語だと基本全角だから、フォールバックからWebフォントに切り替わっても実は欧文に比べるとレイアウトシフトが起こりづらいんですよね。そのあたりが、扱う文字の違いによる、アングルの違いですよね。

中村：なるほど。日本語を扱うという観点からOpeyTypeフォントや@font-faceを見ていくとおもしろいですね。

同じ観点で、バリアブルフォントはどうでしょうか？ 次はこの話題を話してみたいと思います。

（後編へ続く）