アカウント名:
パスワード:
再現する方法が見つかったという話が年末に出てます
https://twitter.com/peprintenpa/status/1607951187269287937 [twitter.com] > お、再現できた> https://pbs.twimg.com/media/FlCW8d9agAEjVz9?format=png [twimg.com]
https://twitter.com/peprintenpa/status/1607952594194006018 [twitter.com] > Win10の「游ゴシック」とAdobe Fontsの「游ゴシック体 Pr6N」で合成フォントファミリーを作るとこうなる> （理屈はこれhttp://sysys.blog.shinobi.jp/Entry/98/）理屈はこれ http://sysys.blog.shinobi.jp/Entry/98/ [shinobi.jp] ）
詳しくは上の http://sys [shinobi.jp]
うわー。これはかなり特殊な条件だなぁ。
1. 合成フォントを使っている2. 合成フォントを使ったテキストにルビを振っていて、ルビのフォントを自動指定している3. 合成フォントの名付けルールで、ウェイトの表現に-Wnを使っている4. 3で出来たフォントファミリーの中に、異なるcmapのフォントが含まれる
このうち、1.～3.まではほぼ全くおかしくない作業だけど、4.はかなりおかしいね。まぁStdとStdNを平気で混ぜるようなヤカラもいるからなぁ。
それでも、ここまでは設計者か作業者がヘボいという話で済むけど、そのまま出版しちゃあダメだよねぇ。校正フローどうなってんの？ってなっちゃう。
「DF平成明朝体W9」などで、単体のフォント再現してますし、合成フォントは再現しやすいだけで原因ではないでしょう。
・「同じフォントのウェイト違いでcmapが異なる」ようなフォントで、ノーマル以外のウェイトを使って・InDesignでルビを振り、ルビのウェイト設定が自動(無指定)だと、・ルビ部分は、ノーマルウェトのcmapで取得したグリフIDで、指定ウェイトのフォントの描画を行うので、文字が化ける。と。cmapが異なるフォントでもルビのウェイトを明示的に指定してれば化けない。
上記のフォントは縦書きの場合のみ発生していますが、これは縦と横で別のグリフを使っていて、横書き用グリフはずれてないけど、後ろの方の縦書き用グリフはずれてるっぽい、と。
で、その推測を元に再現実験したのが合成フォントの例。
あーそっか。そうなると怖いけど、同じ条件を満たすフォントってまぁないですよね（あったら怖いな）。うろ覚えだけど、かなり昔（os9とかのころ）のDF平成明朝体ってW9だけなんか扱いが違った記憶がある（ファミリーから外れてるとかそんな印象）けど、あれ関係あるのかな。今販売してるのは流石に大丈夫なのかな？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
再現方法と原因 (スコア:3, 参考になる)
再現する方法が見つかったという話が年末に出てます
https://twitter.com/peprintenpa/status/1607951187269287937 [twitter.com]
> お、再現できた
> https://pbs.twimg.com/media/FlCW8d9agAEjVz9?format=png [twimg.com]
https://twitter.com/peprintenpa/status/1607952594194006018 [twitter.com]
> Win10の「游ゴシック」とAdobe Fontsの「游ゴシック体 Pr6N」で合成フォントファミリーを作るとこうなる
> （理屈はこれhttp://sysys.blog.shinobi.jp/Entry/98/）理屈はこれ http://sysys.blog.shinobi.jp/Entry/98/ [shinobi.jp] ）
詳しくは上の
http://sys [shinobi.jp]
Re: (スコア:5, 興味深い)
うわー。これはかなり特殊な条件だなぁ。
1. 合成フォントを使っている
2. 合成フォントを使ったテキストにルビを振っていて、ルビのフォントを自動指定している
3. 合成フォントの名付けルールで、ウェイトの表現に-Wnを使っている
4. 3で出来たフォントファミリーの中に、異なるcmapのフォントが含まれる
このうち、1.～3.まではほぼ全くおかしくない作業だけど、4.はかなりおかしいね。まぁStdとStdNを平気で混ぜるようなヤカラもいるからなぁ。
それでも、ここまでは設計者か作業者がヘボいという話で済むけど、そのまま出版しちゃあダメだよねぇ。校正フローどうなってんの？ってなっちゃう。
Re:再現方法と原因 (スコア:5, 参考になる)
「DF平成明朝体W9」などで、単体のフォント再現してますし、
合成フォントは再現しやすいだけで原因ではないでしょう。
・「同じフォントのウェイト違いでcmapが異なる」ようなフォントで、ノーマル以外のウェイトを使って
・InDesignでルビを振り、ルビのウェイト設定が自動(無指定)だと、
・ルビ部分は、ノーマルウェトのcmapで取得したグリフIDで、指定ウェイトのフォントの描画を行う
ので、文字が化ける。と。
cmapが異なるフォントでもルビのウェイトを明示的に指定してれば化けない。
上記のフォントは縦書きの場合のみ発生していますが、これは縦と横で別のグリフを使っていて、
横書き用グリフはずれてないけど、後ろの方の縦書き用グリフはずれてるっぽい、と。
で、その推測を元に再現実験したのが合成フォントの例。
Re:再現方法と原因 (スコア:2)
あーそっか。そうなると怖いけど、同じ条件を満たすフォントってまぁないですよね（あったら怖いな）。
うろ覚えだけど、かなり昔（os9とかのころ）のDF平成明朝体ってW9だけなんか扱いが違った記憶がある（ファミリーから外れてるとかそんな印象）けど、あれ関係あるのかな。今販売してるのは流石に大丈夫なのかな？