フォントについての知見のはきだめと、GoogleフォントがPDF作成に使えない問題のメモ
Kyohei Fukuda次世代のフォント技術バリアブルフォントの世界: https://ics.media/entry/201008/
この問題を解決するため、今度はMicrosoftとAdobeが手を組んでOpenTypeフォントを開発します。TrueTypeをベースにPostScriptフォント形式をサポートしたもので、拡張子が複数パターン存在します。PostScript形式のものは.otf形式、TrueType形式のものは主に.ttfとなります。少しややこしいですが、.ttf形式のOpenTypeフォントは「TrueType形式のOpenTypeフォント」と呼んだりします。この違いは、TrueTypeフォントとPostScriptフォントのアウトラインの計算方法の違いに由来しています。
Kyohei Fukudaそもそもなぜフォントについて調べる必要があるのかというと
下記の問題に悩まされている。
Googleフォントから落としたフォントでPDF作成したらフォントがちゃんとレンダリングできない。
おそらく大元の原因はこれらのissueから問題を把握することができる？
とにかくNoto系のフォントで問題が発生している
説明がややこしいがpdfmeはpdf-libを使ってpdf作成処理を行なっているが、pdf-lib内で使われているフォント関連の処理が上記のライブラリをフォークして作っていたりするのでそれが問題なのかも。
もしかするとライブラリをアップデートしたりすれば治る可能性は0ではないが、現状は回避方法があり
というNoto(源ノ角)をttfに変換した下記のフォントファイルを使えばちゃんとフォントがレンダリングされる
醤ノ角ゴシック / 醤ノ明朝
Kyohei Fukudaフォントファイルについて知識があった方がデバッグやパターンが分析しやすそうなので調べているという所存。
とりあえずGoogle fontでもちゃんとPDFでフォントが表示されるようにしたい
Kyohei Fukuda- TrueType な 源ノ角ゴシック / 源ノ明朝 を作った話．
- Notoでは動かないが醤ノ角ゴシックではなぜ動くのか、醤ノ角ゴシックを作った時に公開されたメモ
- https://3846masa.hatenablog.jp/entry/2017/10/25/183205
- 源ノ角ゴシックや源ノ明朝の改変フォントを製作する際に得たノウハウ
- Fontforge で行う場合の問題点とTTX を使って問題点を改善する方法が書かれている
- https://okoneya.jp/font/knowhow.html
- TTXを使用してTrueTypeフォントのcmapテーブルを修正
- TTXを使ってcmapテーブルを置き換えたTrueTypeフォントを生成するところまで解説している
- https://itouhiro.hatenablog.com/entry/20141004/font
- エンジニア向けフォントの中身の見方
Kyohei Fukudaあまり確信がないのだがうまく行った上記で説明した のIssueでうまく表示されなかったフォントをレンダリングできるようになった。
どのようにやったか
試したフォントは https://fonts.google.com/specimen/Zen+Kurenaido?subset=japanese¬o.script=Jpan
- https://glyphsapp.com/ をダウンロードしてうまく表示できないフォントファイルを読み込む
- export でttfとしてエクスポートする(うまくいかない場合はこちらのトラブルシューティングを試す)
- 生成したフォントならうまくレンダリングできる
Kyohei Fukudaなにが起こっているのか確信はないのだが、https://3846masa.hatenablog.jp/entry/2017/10/25/183205 にあるように OpenType がうまく使えないソフトウェアがあったりする
その中に devongovett/pdfkit があり、それは自分が依存しているソフトである。
↓
おそらく OpenType フォント特性 がうまく読み取れないのではないかと思う
↓
そのため TypeTrue フォントに変換する必要があるのでやったら動いた
フォント作成ソフトはいろいろあるんだが、なんとなく良さそうなGlyphsを使って変換した
日本語フォントの場合はデータが巨大すぎるので カーニングペアが多すぎるか、大きなカーニンググループと多くのグループ例外と例外グループカーニングペアを持つカーニングをしている などが原因なのではないかという仮説
Kyohei Fukudaちょっと曖昧すぎるが、一旦問題が少しわかったので一旦クローズする
Kyohei FukudaNotoSansJP-Regular.otfとNotoSerifJP-Regular.otfをGoogle fontからダウンロードして Glyphs 3でttf変換しようとした。
- NotoSerifJP-Regularはエクスポート時のオプションでエラーになったがすんなりと変換できた。
- NotoSansJP-Regularはエクスポート時にエラーはでないがアルファベットの文字幅が広がる問題にあたった
- FontForgeで生成した日本語TrueTypeフォント文字幅広すぎ対策 を見てttxでxAvgCharWidthをチェックしたがおかしい部分はなかった
-
日本語フォントの場合はデータが巨大すぎるので カーニングペアが多すぎるか、大きなカーニンググループと多くのグループ例外と例外グループカーニングペアを持つカーニングをしている などが原因なのではないかという仮説があったが エラーメッセージなどは特にないのだが、トラブルシューティングを実施してみた。font features の markを無効化した。 - するとアルファベットの文字幅が広がる問題は解決された
Kyohei Fukuda
について追記。
ダウンロードするとZenKurenaido-Regular.ttf とそもそもttfとして返却されるが、これはttfだけどうまくレンダリングできない。ただ拡張の問題というよりもフォント作成ソフト上でなにかおかしくなっているケースもあるということ。
自分はGlyphs3を使ってttf->ttf変換をエラーを解消しながらしている。
厄介なのが実際にpdfを作成するまでフォントがレンダリングできているかわからないところ。