Microsoft Print to PDFで出力したファイルからテキストをコピペしたら文字化けしてた…→実はPDFの仕様に潜む本質的な欠陥が原因なのでは？

やまねこ楢ノ木技研 @felis_silv

お判りいただけるだろうか。これが Microsoft Print to PDF による文字化けである。。。 なお、これMicrosoftだけじゃなくてほとんどあらゆるメーカーがやらかしてる。日本人なら気づくけど他の国の人に判りづらい問題。。。 pic.x.com/4Icgimi2I7

社畜 @leemanoid

ExcelからPDFに出力するときも「印刷→Microsoft Print to PDF」ではなく「エクスポート→PDFの作成」にしないと、ぱっと見は同じでも色々と変な出力結果になると聞いたことがある x.com/felis_silv/sta…

Searcholic_jp @Searcholic_JP

@felis_silv 実質同じ文字がいくつかにばらけて登録されてたりするからなｗ　でWindows側でこのユニコード１つ１つに描画するフォントが設定されていて、中国語しか使わない長だと中国語フォントで描画されてしまうという。。。知らなきゃ踏むよねｗ

やまねこ楢ノ木技研 @felis_silv

@Searcholic_JP 実質同じ、ってわけじゃないんですｗ 同じに見える別の文字がunicodeに三つくらいあって、PDF化するアプリがなぜか間違ってマッピングしてるという。。。 「⻑」（CJK部首補助） 「⾧」（康煕部首） 「長」（漢字）

Searcholic_jp @Searcholic_JP

@felis_silv ええ。えっと文字の原義として意味が同じということを言いたかったです。（どれもlongの意味を表す文字。もちろん長い歴史の中で意味が変わっている文字もあるでしょう） で長の場合は部首の区別のためのUnicodeが与えられていたんですね。で非漢字圏の方には部首の文字と通常の文字は分けるというのも難しい概念ですよね。

やまねこ楢ノ木技研 @felis_silv

@Searcholic_JP そもそも部首単体を扱うことなんて絶対にないと思うのに、なんでunicodeに組み込んでしまったのか、それがすべての問題の根源。。。ｗ

Searcholic_jp @Searcholic_JP

@felis_silv どう考えてもコードポイント足りないから、組み合わせて文字にするとか考えてたんですかね？なんかそういうことをするためのUnicodeがあった気がするので。 この辺かな？ 漢字記述言語 weblio.jp/content/%E6%BC…

やまねこ楢ノ木技研 @felis_silv

@Searcholic_JP あー、そういや、⿳とか⿱とか、プレイスホルダー文字ありますねｗ そういうところで使うやつだったのかｗ

Searcholic_jp @Searcholic_JP

@felis_silv 他、検索とかでしょうねｗ　辞書の部首索引の逆的な使い方？ jstage.jst.go.jp/article/konpyu…

やまねこ楢ノ木技研 @felis_silv

@Searcholic_JP たしかにｗ でもそれなら一般的な文字のほうに統一して、該当する文字がない部首だけ部首専用に作成すればよかったのにｗ

いわかた @yottaburger

@felis_silv あっCJK部首補助だか康煕部首だかに化けるやつだ！ 昔パターンマッチでもとに戻す力技メソッド作ったことあります笑

kusanoさん@がんばらない @kusano_k

康煕部首だ。中国語フォントが使われるとかいう話ではなく、PDFは実はテキストデータを陽には持っていないという話があるらしい。 PDFのコピペが文字化けするのはなぜか？～CID/GIDと原ノ味フォント～ | PDF slideshare.net/slideshow/pdfc… pic.x.com/hXmVyN3sDX x.com/felis_silv/sta…

画力・博士号・油田 @bd_gfngfn

（引用失礼します）この現象，説明すると長くなるけれども実はほとんどの場合はPDFを書き出すソフトウェアの不備ではなくPDFの仕様に潜む本質的な缺陥が原因なんですよね x.com/felis_silv/sta…

画力・博士号・油田 @bd_gfngfn

- 各フォントはそのフォント内でのみ通用するGID（glyph ID）と呼ばれる番号でグリフ（図形文字）を管理しており，UnicodeコードポイントからGIDへマップする cmap と呼ばれるテーブルを持っている - PDFは（方式によるがほとんどの場合は）GIDの列をテキスト情報として保持しており，（続く）

画力・博士号・油田 @bd_gfngfn

（承前）例えばPDFヴューワがPDFを表示するときはそれらのGIDで埋め込まれたフォントを表引きすることによってグリフの曲線のデータを得ている - PDFヴューワ上でテキストを選択しコピーして得られる文字列は，GID列からUnicodeコードポイント列へと逆変換して得られている．この時に（続く）

画力・博士号・油田 @bd_gfngfn

（承前）使われるのがPDF中に埋め込まれている /ToUnicodeCMap という機構で，大雑把に言えば cmap の逆写像にあたるものをPDF出力プログラムが書き込む箇所 - しかし，元々フォントファイルにあった cmap は必ずしも単射とは限らず，相異なるUnicodeコードポイントに同一のグリフが（続く）

画力・博士号・油田 @bd_gfngfn

（承前）割り当てられて同一のGIDが紐づいていることがあり，一般にはGIDから元のコードポイントが正確には復元できない - 一部フォントは例えば U+9577〈長〉と U+2FA7〈⾧〉（康煕部首）に同一のGIDを割り当てており，そうしたフォントを使うとコードポイントが一意に復元できない （続く）

画力・博士号・油田 @bd_gfngfn

（承前） - 一応PDFの仕様として /ActualText というUnicodeコードポイント列を陽に書いておくことができる仕組みがあり，これにより問題が回避できるが，わざわざこれを出力してくれるプログラムはおそらく多くない

やまねこ楢ノ木技研 @felis_silv

@bd_gfngfn 確かに、同じGIDが割り当てられてる複数の文字がドキュメント中にある場合、一意の逆変換は不可能だけど、U+2FA7〈⾧〉なんて本文中で一度も使われてない場合、〈⾧〉のGIDからCMapの逆変換テーブルで一意にunicodeに変換できるはず、ですよね。。