リンクをクリップボードにコピー
コピー完了
2025年4月のアップデートで、Windows10および11にNoto Sans JPのフォントが導入されました。
Windows 10/11のパッチをあてたら、Webページのフォントが変わった? 戻し方はこれ - やじうまの杜 - 窓の杜
Windows 11環境で、Noto Sans JPを使ったWord・Excel・PowerPoint等の文書を「Adobe PDF」で書き出すと不具合があります。(おそらくWindows 10環境でも同様)
普通に書き出すと次のようなエラーが発生します。
%%[ ProductName: Distiller ]%%
%%[ Error: undefinedresource; OffendingCommand: composefont; ErrorInfo: CharOffsets TTA882DAD6tH
%%[ Flushing: rest of job (to end-of-file) will be ignored ]%%
%%[ Warning: PostScript error. No PDF file produced. ] %%
「システムフォントのみを使用し、ドキュメントフォントは使用しない」のチェックをオフにすると、PDFを書き出すことはできます。
しかし書き出されたPDFを見ると、太字(Bold)の指定が無視される箇所があります。
手元で検証したところ、文字サイズ36pt以下だとBold指定が無視されています(37pt以上だとBoldが残っています)
PDF書き出しのプリンタドライバを「Microsoft Print to
PDF」にした場合には、このようなエラーは起きていません。
このことから、「Adobe PDF」がNoto Sans JP(バリアブルフォント?)を扱う際に不具合が起きているように見えます。
セキュリティやテキスト情報の保持の観点から、PDF書き出しに「Adobe PDF」を使えるのが理想です。
対処方法やフィードバック方法などあるでしょうか。
まず、「システムのフォントのみを使用し~」のほうは、Acrobat(とDistiller)側で決めている節があるので、そこはチェックを外すしかないとは思います。
次に、Boldなどが適用されない件ですが、確かにそうなりましたし、40ptの文字についてはBold有無を問わずに文字どころか図形扱いになりました(高品質印刷のjoboptionsを使って処理しました)。
あと個人的な認識ではあるのですが、バリアブルフォントに対応しない(要は機能を生かしきれない)ソフトについては、実際には正常動作しないことがあると思っています。
それもあり、非バリアブル版があれば、そちらを使うのが無難だとは思います。
(ただ今回の場合は、OSに入れられたので、どう共存させるんだ……ってことにはなるのですけど。結局使わないのが無難かもしれない、とも)
試しに同じデータを、CubePDF(内部ではGhostscriptを利用)でPDF生成したところ、Adobe PDFとほぼ同様の挙動になりましたので、AcrobatやAdobe PDFに限らず発生することになります。
(どちらも共通するのはPostScrip
...リンクをクリップボードにコピー
コピー完了
まず、「システムのフォントのみを使用し~」のほうは、Acrobat(とDistiller)側で決めている節があるので、そこはチェックを外すしかないとは思います。
次に、Boldなどが適用されない件ですが、確かにそうなりましたし、40ptの文字についてはBold有無を問わずに文字どころか図形扱いになりました(高品質印刷のjoboptionsを使って処理しました)。
あと個人的な認識ではあるのですが、バリアブルフォントに対応しない(要は機能を生かしきれない)ソフトについては、実際には正常動作しないことがあると思っています。
それもあり、非バリアブル版があれば、そちらを使うのが無難だとは思います。
(ただ今回の場合は、OSに入れられたので、どう共存させるんだ……ってことにはなるのですけど。結局使わないのが無難かもしれない、とも)
試しに同じデータを、CubePDF(内部ではGhostscriptを利用)でPDF生成したところ、Adobe PDFとほぼ同様の挙動になりましたので、AcrobatやAdobe PDFに限らず発生することになります。
(どちらも共通するのはPostScript経由ということです。Microsoft Print to PDFはPSを介さずにPDF作成してますし、OpenTypeフォントは全部画像化するので、別の意味で使いづらいはずです)
リンクをクリップボードにコピー
コピー完了
検証と追加の情報ありがとうございました。
PostScript経由のPDF作成の部分で発生する様子ということが分かって、把握できてひとまずよかったです。
印刷ないしデータ作成にあたっては、それぞれ使い分けるように〈運用〉で気をつけるようにいたします。自分としては幸いそれで済みそうなので…。
DTP・印刷周辺となると、回避が難しいというか思わぬところで発生しそうで少々心配が残りますね。
リンクをクリップボードにコピー
コピー完了
数日前に簡易的ですが比較をしてみました。
ファミリーが異なる、Variations PostScript Prefixの記載がないなどがわかりましたので、互換としてこの辺りが影響してそうな感じです。
リンクをクリップボードにコピー
コピー完了
2年ほど前になりますがFacebookのAffinityのユーザーグループで「Google版の Noto Sans JPはPDFの埋め込みに失敗する」という話題がありました。(このユーザーグループは非公開ですので、参加者以外は閲覧できません)
Noto FontはGoogleとAdobeが共同で開発したものですが、いくつかのバリエーションがあります。開発当初にGoogleから提供されていたものは「Noto Sans/Serif CJK JP」というフォントで、これはもうGoogleからは提供されておらず、代わりに「Noto Sans/Serif JP」(以前の名称は「Noto Sans/Serif Japanese」)が提供されています。「Noto Sans/Serif CJK JP」はGitHubからダウンロードすることができます。
https://github.com/notofonts/noto-cjk
Adobeでは「源ノ明朝/源ノ角ゴシック(Source Hans Serif/Sans) 」という名称で同じフォントが提供されました。
Noto Sans/Serif CJK JP = Source Hans Serif/Sans-Pans-CJK Japanese
Noto Sans/Serif JP = Source Hans Serif/San Japanese
になります。
当時の回避方法は「Noto Sans/Serif JP」を使用せず、「Noto Sans/Serif CJK JP」「源ノ明朝/源ノ角ゴシック(Source Hans Serif/Sans)」を使用する、というものでした。そちらの方は問題なくPDFに埋め込めます。
その後、ある方がGoogleフォントのサポートとやりとりをして、Noto Sans JPがアップデートされて、この問題は解決しました。
----------------------------------
このときのフォントは今回Windowsに搭載されたもの(VF)とは異なりますので、そのこととまるっきり同じとは思いませんが、非常に酷似しており、フォント側に何らかの問題があるという想定はしておくべきだと思います。
したがって、当面の回避方法はWindowsに搭載されたNotoフォントを使わないことです。上記のように代わりのフォントがあります。ただし、2年前の話ですので、その後のフォントのバージョンにより変化があるかもしれません。ここは要検証です。
フィードバックについては、提供元のMicrosoftに送るのが筋だと思います。MicrosoftとGoogleのどちらが
検証・修正するのかというところはありますが、そこまでは知りません。フォント名称から見てAdobeは関与していないのではないかと思いますが、Adobeでも「Source Hans Sans JP - Japanese Subset Variable」などの派生フォントを提供しているので、可能性がないとは言い切れません。
私の知っていることは以上です。直接の解決にはならないかもしれませんが、参考にしてください。
リンクをクリップボードにコピー
コピー完了
情報ありがとうございました。似た事象が以前から確認されているとのことですね。
海外(欧文)でも似たようなトピックが上がっていたので、Google Fonts提供のVariable Fontに問題があるのかもしれないですね。
個人のレベルですが、フィードバックをMicrosoftに送ってみようと思います。
より詳しい方々の多数の声が集まって、早めに修正があたることをお祈りしつつ👏