PostScript、Acrobat DistillerでPDF変換するとテキスト情報が文字化けする。

フォントに起因する部分だとこれですかね。

PS経由でフォントを埋め込む場合PostScript系はCharset内に文字コードが保持されるんですけど、Trutype系にはありません。そのため、文字コードはカスタムエンコーディングの状態で拾われる為に文字化けします。
Illustrator等のアプリケーションからPDF構造を書き出すとフォント定義にUnicodeとカスタムエンコーディングを紐づけるテーブルが付加されるため正しいテキストが抜き出せます。

という事でTrutypeの件に関しては仕様ではないかと思います。

IceFloeのさんの発言と一部被ってしまうのですが、PostScript生成段階でテキストエンコーディングが影響する場合はありますし、それはアプリケーションのほうに依存する場合があります。

また、どこでフォントを埋め込んでいるのか、は結構影響するところだったりします。

（アプリケーション段階なのか、Distillerでエンベッドするのかは結構影響したりします）

また、フォントがTrueTypeだから、というわけでもなかったりはしますので、OpenTypeでも見た目と裏で持つテキスト情報が不一致になることはありえます。

どのようなアプリケーションで作成・PS出力してるかはあるのですが、結局はその組み合わせを除外したり、出来るだけイレギュラーな方法にならないように、PDFを作ることになってきます。

ただしそれでも使っている文字群等によっては完全な検索・テキスト抽出用には向かない、くらいで考えないといけないところです。

『見た目の文字の形通りの文字で検索できないPDF』
『見た目の文字の形通りの文字でコピーできないPDF』
ですね

『使われているフォント』『作ったアプリケーション』『その時の設定』に依存するので
元になっているPSファイル見てみないと確実な事は言えないですが
原因は
CIDやGID等フォントについて基本知識のある方のようなので
こちらを読んだらわかるとお思います
https://blog.antenna.co.jp/PDFTool/archives/2006/05/tounicode_cmap.html

作り方（psを作成するアプリケーション）を変える事で回避出来る事が多いですよ♪

OS情報がないですが
ヒラギノ言っているのでmacOSですよね（Windows版もあるけれども）
macOS標準で搭載されているTTC形式のヒラギノフォントには
フォントファミリー名を正しくOSが認識できないバグ？
（たぶんAppleとScreenの仕様に対しての見解の相違なんだけど）
が
ありますので

macOS12以降で不具合が出ている場合、利用を避けた方が
検討する項目が減ります
参考まで

--余談
Uske_Sさん＞PDF上で正しく表示されているのであれば、PDFの役目はそこで終わりで、
そうなんですよね
PDFって『見た目通りの文字とデザインで印刷』するのを目的で誕生しているから
後から色々つけた機能で混乱している感もありますよね…苦笑

詳しいところはわかりかねますが、示していただいたスレッドでも上がっているように、PDFの再変換に関する仕様として、下記ヘルプページがあります。

https://helpx.adobe.com/jp/acrobat/kb/cq10240010.html

ですので、バグではないだろうと考えられます。

どのフォントだと起きる・起きないではなく、そもそもそのような利用を想定していないので、それを明確にはできないでしょう。

個人的な意見ですが、PDF上で正しく表示されているのであれば、PDFの役目はそこで終わりで、そこにあるテキストをコピーしたいが正しくコピーできないという話は、文字化けでもなんでもなく、そういう仕様かと思います。

どうしてもその作業に必要性があってやられているのでしょうが、PDF本来の性質・役割から逸脱したやり方かなと思いますので、画像にしてOCR認識する、対話型AIプラットフォームに投げて文字起こししてもらう、といった、PDFだのコピペだのにこだわらないところで解決する選択肢も検討していただいたほうがいいかもしれません。