雑なメモ。
tl;dr
- OTF は TTF を発展させたフォントである。
- フォントをリポジトリで管理したくない場合は、GitHub から download して使う。Google Fonts は GitHub 3 で公開されている。
Context
業務アプリで PDF を出力するにあたり、TTF 2 が必要になった。
CSS へのフォントの埋め込みや S3 からの配信などと構成を考慮した結果、Docker の build 時に download してそのまま使うことになった。
ただし、リポジトリに TTF を置くのはサイズが大きくなるため、避けたい。それを許容すると割れ窓的に他も大きなファイルを置くことになりそうだったため、Docker の起動時に download することにした。
# Get fonts for PDF generation
RUN curl -o /usr/local/share/fonts/NotoSansJP-Regular.otf -LO https://raw.githubusercontent.com/notofonts/noto-cjk/main/Sans/SubsetOTF/JP/NotoSansJP-Regular.otf && \
curl -o /usr/local/share/fonts/NotoSansJP-Bold.otf -LO https://raw.githubusercontent.com/notofonts/noto-cjk/main/Sans/SubsetOTF/JP/NotoSansJP-Bold.otf
Google Fonts は GitHub 3 で公開されており、そこから TTF を curl で取得することにした。
PDF 生成アプリ側は絶対パスで参照するようにした。React-pdf 4 でのフォントの読み込み。
{
src: path.resolve('/usr/local/share/fonts/NotoSansJP-Regular.otf'),
},
{
src: path.resolve('/usr/local/share/fonts/NotoSansJP-Bold.otf'),
fontWeight: 'bold',
},
今回フロントエンドは CloudFront と Lambda で構成される予定であり、Fonts をデプロイに含めるのが妥当という結論に達した。
フォント ファイルをサブセット化するという手もあるが、PDF を使用する部分の特性を考慮し、性能よりも信頼性を優先することにした。
Quick Note
現職になり、半年が経過した。
これまでに取り組んできたのは以下の通り。
- ADR の導入
- Architecture の検討
- 開発言語の選定
- CI/CD の構築
- CDK での IaC 化
- テスト自動化の実装
- 脆弱性診断の自動化
- 負荷試験の自動化と準備
- APM の導入
- 部門戦略の素案作成
生成 AI の登場により、何が必要なくなったかと言われれば、ググる回数が若干減ったくらい。
枯れた技術に取り組んでいれば、生成 AI で事足りるだろうが、それは「改善」を否定するに近く、昨日よりも良くなりたいという人間の性には逆らえない。
ということで、今も昔も変わらないエンジニア生活が続いている。自分でハマって、自分で解決して、自分の機嫌を取る。