Kintone Sans 備忘録

• 和文→サブセット（pyftsubset）

  • そもそもNotoに幅0のグリフが2つある。ミス？
  • 欧文のグリフが増えているため、文字を減らす必要があった、丸つきの漢字などを減らしている

• 欧文→カスタム

  • 字形カスタム
    • 良かれと思って2000upmにした結果、マージの際の変換で色々形が崩れてしまって結果手で治すことになった。一部字形だけ少数を許容する貂明朝的な設計もありかもしれなかったがやりすぎな気もする。縁は難しい
    • 色々なカット、角丸の半径などを試した。太さが足りなく見えるところもあったため細くなり方をease的にすることで太さを担保した
  • ベトナム語
    • 思ったよりは大変じゃなかった。チュートリアルや先人の資料が充実している。ただ、文字の高さは後々影響してくる。
  • 拡大縮小・字形
    • サイドベアリング、カーニング値など拡大縮小されるものを都度確認する必要があった。
    • アラインメントゾーンはベースラインがズレるため、追加のベースラインを追加する実装にした。
    • sTypoやhheaはmekkablueスクリプトの方が安全そうだったのでそちらを使用することに。

• マージ

  • pyftmerge, OFL Font Bakerなどの前例があったのは助かる。
  • どの数値を、どちらから引き継ぐかというのが主な課題。もちろん、モノによっては新たに算出する必要がある
  • OTMasterで色々いじっていた。便利だけどinputとoutputではないところが注意は必要。モノによってはPythonも使っている。
  • nameテーブル
    • OFL同士の合成なのでその辺りのマージ。OFLを事前に勉強していたのが良かった
    • いつもはcheck-universalを通していたがcheck-googlefontsも試した結果、nameID 1, 3, 16, 17の関係を再確認できて良かった（というか直感的ではないと感じる）
    • この辺りをいじるためにPythonも使えたのが良かった。
  • 和文判定
    • 最初のマージを読み込んだ時和文フォントだと判定されなかった。
    • 何が原因かわからず、この解明に数時間かかった。nameテーブルのlanguageIDの日本語、ulUnicode Rangeなどかと思ったが違った。結果としてはcmapサブテーブルのMachintosh; Japaneseだった
  • スタイルリンキング
    • いつもはGlyphsがいい感じにやってくれてるが、今回は自分でやる必要があった
    • nameテーブルのnameID 1, 2以外にも、OS/2テーブルのfsSelection、headテーブルのmacStyleの変更が必要だった。
  • chwsの追加　一応やっておいた。
  • バーティカルメトリクス
    • 最初は和文の慣例に従った880, -120で設定していた。
    • しかし、ベトナム語を追加したことで大幅に背が高いグリフが出てしまった。MacのIllustrator, Figma, ブラウザ、WindowsのWord, ブラウザは検証の結果ちゃんと表示されたが、MacのWordのみクリッピングが発生してしまった。行間を広げれば表示されるものの通常ではクリッピングされてしまう。
    • Windows側は全てをカバーしているusWinAscent/Descentのおかげで表示されるが、おそらくMacではhheaを参照するためカットされてしまうっぽい。
    • そもそもNotoはsTypoとhheaが違う設定で、参考にして良いかわからなかった。
    • TypoLineGapは意味がなかった。sTypo/hheaを追加するしかなかった
    • 色々エンジニアの方に相談させていただきつつ、2025年にはGF GuideのCJK Vertical Metricsが更新されているのもあってそちらの実装にした。BASEテーブルやvheaテーブルはNotoのものを使用した。結果、無事表示できるように

(Masaki Ando)