アカウント名:
パスワード:
再現する方法が見つかったという話が年末に出てます
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を平気で混ぜるようなヤカラもいるからなぁ。
それでも、ここまでは設計者か作業者がヘボいという話で済むけど、そのまま出版しちゃあダメだよねぇ。校正フローどうなってんの?ってなっちゃう。
「校正」としているプロセスの後でこれが発生したらツラいのでは。実物見られないけどルビ部分で時々発生してるやつなんだよね?
# 相好はそうこうだと思ってましたすいません
それはその通りで、@peprintenpa氏曰く、「一部のフォントの組み合わせによっては、ファイルを開いただけで文字化けが発生するパターンもありうる」ということもあり(極めて稀に稀を重ねた条件ではあるものの)、そうなると危険度は爆発的に上がりますね。
具体的には:A. 作業者の念校まで一貫した環境からinddファイルを受け渡し、突然別の環境から入稿用PDFを作るB. 製版者がinddファイルを直接入稿用として要求し、そのinddファイルから製版するのどちらかで、かつお互いの環境が問題を発生させる条件を満たす場合です。ただし、AもBも正しい工程ではないです。この場合それぞれ、Aは作業側の責任、Bは製版側の責任でしょう。(でも、いまだにPDF入稿じゃないとこあるんだよな……)
理想的なフローでは、念校用PDF=入稿用PDFで、それがそのまま製版されるわけですから、こういった問題が作業のタイミングで発生していたとしても、出版までには至らないでしょう。
まぁ現実的には、無茶な日程やおかしなタイミングで修正やフォントの変更が発生し、校正の工程がヌケたかずさんであったというのが一番ありえそうです。その場合バグ自体は珍しいものの、よくある話です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
再現方法と原因 (スコア: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: (スコア:0)
「校正」としているプロセスの後でこれが発生したらツラいのでは。実物見られないけどルビ部分で時々発生してるやつなんだよね?
# 相好はそうこうだと思ってましたすいません
Re:再現方法と原因 (スコア:2)
それはその通りで、@peprintenpa氏曰く、「一部のフォントの組み合わせによっては、ファイルを開いただけで文字化けが発生するパターンもありうる」ということもあり(極めて稀に稀を重ねた条件ではあるものの)、そうなると危険度は爆発的に上がりますね。
具体的には:
A. 作業者の念校まで一貫した環境からinddファイルを受け渡し、突然別の環境から入稿用PDFを作る
B. 製版者がinddファイルを直接入稿用として要求し、そのinddファイルから製版する
のどちらかで、かつお互いの環境が問題を発生させる条件を満たす場合です。
ただし、AもBも正しい工程ではないです。この場合それぞれ、Aは作業側の責任、Bは製版側の責任でしょう。(でも、いまだにPDF入稿じゃないとこあるんだよな……)
理想的なフローでは、念校用PDF=入稿用PDFで、それがそのまま製版されるわけですから、こういった問題が作業のタイミングで発生していたとしても、出版までには至らないでしょう。
まぁ現実的には、無茶な日程やおかしなタイミングで修正やフォントの変更が発生し、校正の工程がヌケたかずさんであったというのが一番ありえそうです。その場合バグ自体は珍しいものの、よくある話です。