縦書きに対応

[Qrac]

使用するグリフが異なるので、同じファイルにしてしまうとファイルの容量が倍増してしまう。
別ファイルに分けるのが望ましいか。
そもそも縦書きで詰めるシーンはあるだろうか。

[Qrac]

ニーズが少ないと思われるので次期バージョン、または別のライブラリにすることで検討。

[Qrac]

#59 でマージした場合、横書きだけ半角になってしまうため縦書きへの対応が必要だと思われる。

[Qrac]

そこまでのモチベーションと時間はなかったので今回も見送る。

[Qrac]

Glyphsで縦のカーニングを編集する場合は下部の縦リストアイコンを押して切り替える必要がある。

一括編集する場合は左下の数値の間にある記号を押して左右と上下の余白を切り替える...はずなのだが入力が反映されない。一覧での一括編集が効かないので一つ一つグリフを開いて編集する必要があり面倒（Glyphs v3.1.2）。

[Qrac]

容量比較

• 横書きのみ（Noto Sans CJK JP）：2,612 バイト（ディスク上の4 KB）
• 横書きのみ（Noto Sans JP）：2,508 バイト（ディスク上の4 KB）
• 横書き＋縦書き（Noto Sans JP）：3,592 バイト（ディスク上の4 KB）

[Qrac]

ダウンロード速度計測

低速3G	高速3G

• 横書きのみ（yoko-only.woff2）：低速3G→2.13秒, 高速3G→611ミリ秒
• 横書き＋縦書き（yoko-tate.woff2）：低速3G→2.19秒, 高速3G→627ミリ秒

40%近く容量が増えてるが読み込み速度の影響は2%程度。

[Qrac]

縦フォントの導入方法

• 別フォントとして配信する
• オリジナルにマージして配信する

結論としては「オリジナルにマージして配信する」で良いかと考える。

まず、CSSの進化でYakuHanJPのWebでの重要度が下がっている #58 ので容量の増加に対して深刻に悩む必要がない。また、ダウンロード速度自体も容量増加に対して軽微であること。フォントを横向きと縦向きで分割すると命名規則などを含め開発・利用共に面倒であること。マージフォントの作成 #59 に伴い縦フォントへの対応を避けて通れないことなどから、縦用のグリフをオリジナルにマージしたいと考える。

[Qrac]

Playgroundで試したところ、どうやら縦書きモードの時に括弧を詰める font-feature-settings が効かない様子。これを実装すれば、縦書きを用いるWebサイトにとっては未だ有用なのかもしれない。

[Qrac]

縦書きに対応する場合、横書きのグリフを縦書きのグリフに置き換えるにはフォントのフューチャー機能を使う。

Noto Sans JP → Yaku Han JPのようにグリフを減らした場合にフューチャーはエラーを起こすので、全削除して自動生成を行う。

Noto Sans JP, Noto Serif JP

基本的には vert の欄に同名のグリフの末尾に .vert が付与されたものを適応してくれるが、2文字だけ横と縦でグリフ名が異なるものがあり、それだけ抜け落ちてしまう。

自動生成のチェックを外し、以下の2行を加える。

sub angleLeft by anglebracketleft.vert;
sub angleRight by anglebracketright.vert;

これで抜け落ちた 〈〉 を縦のグリフにマッピングできる。

M PLUS Rounded 1c

M PLUS Rounded 1cの 〈〉 は横型も縦型も anglebracketleft anglebracketright なので自動生成のみで完結できる。

[Qrac]

完了。