文字コード総合スレ part15 (410ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
395(2): デフォルトの名無しさん [sage] 2025/08/04(月) 12:31:11.59 ID:Dprx6XuC(1/4) AAS
一部訂正
× コピペに関しては、文字コードを保存してないのが問題で、(>>387387(1): デフォルトの名無しさん [sage] 2025/08/02(土) 12:26:25.37 ID:xIFE1Go+(4/4) AAS
>>386
相変わらず分かってねえな
> コピペが化けるのと同じ問題が起きる
だからいいんだぞ
両方ともPDF内から生成された物だからこそ、確実に一致する
> PDFについて無知過ぎ
PDF博士なお前はマウントポイントなこの点にこだわるようだが、
既に言った通り、本質的にはPDFではなくunicodeの問題だ
実際、unicodeなhtmlでも「見た目同じだけど検索に引っかからない」ケースが普通にあるだろ
コピペに関しては、文字コードを保存してないのが問題で、既に仕様は追加済み、さっさと対応しろだが、
検索に関しては、元々unicodeは検索がまともに出来ない仕様で、それがPDFにも輸出されただけ
例えば、316で3つの「長」が同じグリフIDに紐づけされるのは、
当然その文書のそのフォントでは3つの「長」が同じグリフを使うからであり、見た目が同じだから
同じ文書をhtmlで表示させたら、当然画面上の見た目は同じ「長」になるが、
文字コードが3つのどれかは見た目では分からない
だから「手打ちで」「長」と打ち込んでも、当たらない時がある
これ、PDF全く関係ないだろ
)
○ unicodeのコピペに関しては、糞フォントと文字コードを保存してない組み合わせの時の問題で、
PDFの昔の仕様でも、文字コード->グリフが1:1の場合にはコピペ/検索共に全く問題なく機能する
316で「なんか低い…」になるのは、それらの文字コードには別のグリフが与えられているからであり、
PDF閲覧者の環境でその文書のPDFを作成した場合、(3つとも別のグリフなら)全く問題ないPDFが作成される
だから発生条件として、
・糞フォントで、違う文字コードで同じグリフを使いまくり
が必要であり、これを誘発しているのはunicodeの仕様
だからPDFがボロいと言うより、
unicodeが本質的にボロくて、以前の1:1な世界と親和性が皆無な事が問題なのだと思うよ
(なお316の件は、コードに戻す際、その文書で一度も使ってもない「長」に決め打ちで変換されていると思われ、
PDF出力アプリがポンコツなのもほぼ間違いない
376の通り、「その文書で最初にそのグリフを使った文字コード」を格納する実装なら、
単国籍な文書《≒大半のケース》で顕在化するのは防げる)
結論としては、やっぱunicode糞じゃね？と思うが
以前の文字コード：このコードはこう表示される程度の知識で全く問題ない
unicode：正しい作法(正規化等)を知らないと色々誤動作する
396(1): デフォルトの名無しさん [sage] 2025/08/04(月) 12:54:11.55 ID:B+SwrOCa(2/5) AAS
>>395
お前、まだあきらめて無かったのか
昔から1対1なんてことはないよ
グリフIDはフォントごとに異なる、1つのPDFで複数のフォントを使ったら異なるグリフIDになる、逆に同じグリフIDでも異なる文字を表現している
何度も言われただろ、理解できない部分を読み飛ばしてるのか？
399(1): デフォルトの名無しさん [sage] 2025/08/04(月) 14:37:31.31 ID:D3iy7z0J(1) AAS
>>395
>・糞フォントで、違う文字コードで同じグリフを使いまくり
自分の妄想をベースにAdobeに因縁を付けるのか
最近こういう人が増えている感じで怖い
>以前の文字コード：このコードはこう表示される程度の知識で全く問題ない
ある
前提の認識が間違っているのでそれをベースにした話も間違い
ただの間違いの積み重ね
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.034s