bewise.jp

2024年4月18日木曜日

少し前にAIに奪われる雇用の割合は日本がアジア圏で一番といった調査機関の報告がニュースに出ていました。

事務的な仕事が多いためだそうです。

また、他の調査では労働人口の半分近くがAIで代替されるといったものもありました。

そういうわけでAIと仕事について少し考えてみました。

これまでAmeba Owndを無料プランで使用していたのですが、仕様変更となって独自ドメインを使用できなくなりました。

このため、bloggerに引っ越すことにしました。

Ameba Owndのコンテンツは逐次こちらに移動していくつもりですが、当面は以下のURLを使用してください。

bewise.jpをbloggerに移行できないか、検討を始めました。

引き続いて調べたいことはいくつかあるのですが、なかなか進まないので少しだけ寄り道です。

デジタル庁はNoto Sans JPフォントを推奨フォントとしているので、デジタル庁の文書の中ではどう扱っているかを調べてみました。

前々回、前回と調べてきたNoto Sans JPフォントを埋め込むと正常なPDFが生成されない件について、少し進展がありましたので調べた内容を書いていきたいと思います。

簡単にまとめてしまうとNoto Sans JPフォントが (仕様として正しいかどうかまでは確認できませんでしたが) 多少気持ち悪い作りになっていたため、PDF生成ソフトウエアがうまく処理できなかったことが原因だろうという結論となりました。

Noto Sans JPフォントはOTFフォント (CFF形式) で作られていて、OTFフォントはざっくり言うとTrueTypeフォントの字形データの代わりにCFF形式のCIDフォントデータを使用したものになります。

前回調べたNoto Sans JPの文字化けに関して、cmapを確認してみました。

このフォントには以下の5種類のcmapテーブルが実装されていました。

簡単にまとめると16ビットのUnicodeからCIDを引くcmapと32ビットのUnicodeからCIDを引くcmap、そして異体字セレクタ (別字形を選択するためのコード) を含むUnicodeからCIDを引くcmapの3種類が登録されています。

これらのcmapの内容を確認したところ、すべて前回調べたToUnicode cmapに登録されているCID値が設定されており、Microsoft Print to PDFの出力が (文字化けするけど) 正しい値を指定していることがわかりました。

cmapには問題がなさそうなので、次はCFFテーブル (フォントデータ本体) を調べてみようと考えています。

最近、PDFへのフォント埋め込みで気になることがあったので、フォントについて少し調べてみました。