文字コード総合スレ part15 (462ﾚｽ)
上下前次1-新
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
379(1): 08/01(金)23:52 ID:S37h8L9Z(4/4) AAS
>>378
俺は実際にPDFの検索組んだことあるんだが、お前のその妄想はどっから来たのか知りたい
380: 08/02(土)07:47 ID:xIFE1Go+(1/4) AAS
>>379
文盲か？最初の行にわざわざモロクソ書いただろ
> 検索文字列がフォント名とグリフIDのセットで降ってくるとでも思ってるのか？ (>>377)
ここからだよ
普通はたった2行のレスをわざわざ引用するのは冗長すぎるので文句言われるが、
それでもお前にはどちらの行か分かるようにしたほうが良さそうなので敢えて引用した
5chのコミュ障共はこの辺の配慮なんて汲めないから、
省10
381: 08/02(土)07:48 ID:xIFE1Go+(2/4) AAS
結局の所、>>317はよく書けていて、その通りだが、別の言い方をすると、
PDFの仕様は各文字が別々の字形(＝複数の文字コードが同じグリフを使うことがない)
の時に機能するように出来ていた
SJIS時代はだいたいこれが成立してたので、目立った問題はなかった
unicodeだとまるで動かなくなったので、新仕様を整備したが、対応してないPDFアプリは誤動作しまくり
で、これが上位の状況説明で、下位の詳細理由説明が317になってる
上位の説明はお前のような文系馬鹿でも分かるはずだが、下位の説明では、
省12
382(1): 08/02(土)08:50 ID:jagzAmj3(1/4) AAS
糞長文書いてる暇があったらプログラム書けよ
そうすればすぐに unicode 関係ない
絶対に失敗しない検索も作れないってわかるぞ
そもそも暗号化されてもいないのに一切検索できないPDFをはくツールすらあるぞ
383: 08/02(土)09:03 ID:tv/q+z7t(1) AAS
>>382
それも初心者あるあるだな
賢いお前にはこれで十分通じるはず(ｷﾘｯ
384(1): 08/02(土)10:53 ID:jagzAmj3(2/4) AAS
日本語フォントとかだとグリフID の順がSJISやUnicodeと全く一致してないということを知らずに吹いてるんだろうな（SJIS時代は並び順が一致してたとでも妄想してるのかな？
検索文字列がSJISとかUnicodeで与えられた時にそれをどうやってグリフIDとマッチングされるか具体的な方法も知らないんだろうな
グリフIDと文字コードの対応がPDFに内蔵されてない場合に検索どうするか検討もつかないんだろうな
中には文字をグリフIDですらなくてアウトラインの図形データとして格納してるPDFだってあるということも知らないんだろうな
385(1): 08/02(土)11:23 ID:xIFE1Go+(3/4) AAS
>>384
> 順が
なるほどやはりお前は分かってない
> 検索文字列がSJISとかUnicodeで与えられた時
実はこれには問題がある。だから注つけるかとも考えたが、
> 画面なぞって (>>361)
と既に言及してるし、どのみちunicodeだと手打ちでは無理で、画面なぞるしかない(後述)ので、まあいいかで省略した
省9
386(1): 08/02(土)11:47 ID:jagzAmj3(3/4) AAS
>>385
結局何も分かってなかったのね？
既存のPDFビュワーの画面をなぞるのはコピペの機能だぞ
一旦グリフIDから文字コードに変換される、そして検索窓等に文字コードとして入力される、コピペが化けるのと同じ問題が起きる
それともお前がSJIS時代にグリフIDのままで検索できるビュワー書いたのか？ 本当に過去に存在してたのなら見せてくれ、ごめんなさいして今から書いても良いぞ
作るのなら
フォントごとにグリフIDが異なるんだが、まずは複数のフォントが使われてる時にあるフォントの「あ」の文字を選択したときに、別のフォントの「あ」の文字のグリフIDにどうやったら変換できるか考えてみろ
省3
387(1): 08/02(土)12:26 ID:xIFE1Go+(4/4) AAS
>>386
相変わらず分かってねえな
> コピペが化けるのと同じ問題が起きる
だからいいんだぞ
両方ともPDF内から生成された物だからこそ、確実に一致する
> PDFについて無知過ぎ
PDF博士なお前はマウントポイントなこの点にこだわるようだが、
省10
388: 08/02(土)15:48 ID:MvhBDlJ2(1) AAS
馬鹿はコード書けって言われると発狂するから分かりやすいね
389: 08/02(土)18:36 ID:jagzAmj3(4/4) AAS
きっとここがプログラム技術板だってことにすら気付いていないんだろうな
プログラム書けば良いのに
390: 08/02(土)19:21 ID:dbEqXJf9(1) AAS
ID:xIFE1Go+がニワカ知識だったでOK？
391: 08/04(月)06:18 ID:QkMIbgCE(1/2) AAS
さてと
PDFの中を覗いてみたけど、/ActualTextという要素がある（場合がある）のね
Acrobatなどは検索やコピペのときにこれを参照するのかな?
392(2): 08/04(月)06:44 ID:wGHus/El(1) AAS
画像に/actualtextや/altが付いているのでたしかめて見ては？
{}内のテキストが入っている
Actual Text
{T}
his is an example of actual text.
Alt Text
{Je t'aime (French for "I love you")}
省2
393(2): 08/04(月)07:42 ID:B+SwrOCa(1/5) AAS
Actual Text や Alt Text もそうなんだけど最近の PDF には大きな枠組みで「タグ付き PDF」という機能があって文章の構造化ができる
要はHTMLの段落タグや見出しタグと同じやつで読む順番やその文章内での意味付けや読み方や代替の指定が可能、補足を入れる Expansion Text みたいなのも
これによって改行を超えた検索とかリフローっぽいこととか、画像化された文字のテキスト化の指定とかとか色々HTMLっぽく使える
（文字コードとは独立した問題）
394(1): 08/04(月)10:06 ID:QkMIbgCE(2/2) AAS
>>392
なるほどー。ただこれはどちらかというと /Span の使い方のデモ（濫用）って感じも
しかしこれでAcrobatのことが少しわかった感も、どうもです
>>393
> ... 文章の構造化ができる
>（文字コードとは独立した問題）
異なるコードポイントの文字を構造化することもできますね
395(2): 08/04(月)12:31 ID:Dprx6XuC(1/4) AAS
一部訂正
× コピペに関しては、文字コードを保存してないのが問題で、(>>387)
○ unicodeのコピペに関しては、糞フォントと文字コードを保存してない組み合わせの時の問題で、
PDFの昔の仕様でも、文字コード->グリフが1:1の場合にはコピペ/検索共に全く問題なく機能する
316で「なんか低い…」になるのは、それらの文字コードには別のグリフが与えられているからであり、
PDF閲覧者の環境でその文書のPDFを作成した場合、(3つとも別のグリフなら)全く問題ないPDFが作成される
だから発生条件として、
省11
396(1): 08/04(月)12:54 ID:B+SwrOCa(2/5) AAS
>>395
お前、まだあきらめて無かったのか
昔から1対1なんてことはないよ
グリフIDはフォントごとに異なる、1つのPDFで複数のフォントを使ったら異なるグリフIDになる、逆に同じグリフIDでも異なる文字を表現している
何度も言われただろ、理解できない部分を読み飛ばしてるのか？
397(1): 08/04(月)13:40 ID:Dprx6XuC(2/4) AAS
>>396
いや、やはりお前は理解出来てない
もういいけど
(お前が理解出来ない事は理解しているし、お前の頭の悪さについては諦めている)
> グリフIDはフォントごとに異なる、1つのPDFで複数のフォントを使ったら異なるグリフIDになる
ここまでは全く問題ないが、
> 逆に同じグリフIDでも異なる文字を表現している
省9
398(1): 08/04(月)14:31 ID:B+SwrOCa(3/5) AAS
>>397
明朝体の「あ」のグリフIDが 325 でゴシック体の「ほ」のグリフIDが同じ 325 ということだってあり得るんだよ
明朝体の「あ」とゴシック体の「あ」は検索したいけど、ゴシック体の「ほ」は検索にひっかかると困る。常識だろ
399(1): 08/04(月)14:37 ID:D3iy7z0J(1) AAS
>>395
>・糞フォントで、違う文字コードで同じグリフを使いまくり
自分の妄想をベースにAdobeに因縁を付けるのか
最近こういう人が増えている感じで怖い
>以前の文字コード：このコードはこう表示される程度の知識で全く問題ない
ある
前提の認識が間違っているのでそれをベースにした話も間違い
省1
400(1): 08/04(月)15:13 ID:Dprx6XuC(3/4) AAS
>>398
それは初(ry
あとちなみに、「1:1」の表現は317から使われてるだろ
お前以外の誰も「1:1」表現を気にしてないのは、お前だけが特殊(＝非プログラマ)だから
まあ方言っちゃ方言だが、この場合の意味は可逆/非可逆であって、写像形式自体を示しているわけではない
>>399
> 自分の妄想をベースにAdobeに因縁を付けるのか
省2
401(1): 08/04(月)15:21 ID:SX/R7tYr(1) AAS
>>392-394
Adobe Acrobatで検索もコピペも出来ない/ActualTextの例
402(1): 08/04(月)17:34 ID:B+SwrOCa(4/5) AAS
>>400
だから 317が1対1じゃないって言ってるだろ
フォントと文字コードが1対1じゃないのは Unicode どころかPDFよりもっと前の PostScript のフォントで使われ始めた技術
それが現在までそのまま引き継がれてる
Unicode で始まった話ではない
403(1): 08/04(月)21:50 ID:Dprx6XuC(4/4) AAS
>>402
そういう話じゃねえ
てかお前も本気で文盲だな
317: 1:1でなら動くシステムに多:1をブッ込んでるから動かない
やぞ
ただここまで言っても通じないのだから、本件に対し、お前の知能/知識がまるで足りてないんだよ
普通レベルのプログラマなら317で、ああ、そういう事か、で終わるし
省5
404: 08/04(月)22:38 ID:B+SwrOCa(5/5) AAS
>>403
文盲って言われても 317 は俺が言ってる通りの意味で、お前の解釈が間違ってるんだが？
405: 08/04(月)23:12 ID:n6MSUZI0(1) AAS
で、いつ検索プログラム書いてくれるの？
406(1): 08/05(火)17:39 ID:vuU/s1Wj(1/3) AAS
>>401
え? 例えば箇条書きの部分 (Tom Dick Harry）の先頭は
● (<-文字化けするかな? U+25CF）で検索もコピペもできますが?
PDFの中を見てみました?
407(1): 08/05(火)17:45 ID:ucdc3IWT(1) AAS
>>406
全部でいくつあるか数えたか?
その他の/ActualText箇所が対応してない
408(1): 08/05(火)18:40 ID:vuU/s1Wj(2/3) AAS
>>407
"T"の所? アクセシビリティをオンにしたらそこを"T"と読むので
これで機能している
多分/Spanとの組み合わせにする必要があるんじゃ?
409: 08/05(火)18:52 ID:vuU/s1Wj(3/3) AAS
ところで、この手のPDFって/Encodingが/Identity-Hじゃないですか
もしかして/UniJIS-UTF16-Hとかなら元のコードが反映されるんじゃね? と思って
試してみたが... 駄目ですなーなるほどー
中間コンパイル的な感じでグリフの世界に行っちゃってる感じ?
410: 08/05(火)19:10 ID:tWkqXVBi(1) AAS
>>408
Thisで検索もコピペも機能してない
411: 08/07(木)22:53 ID:lZ/0qeLw(1/3) AAS
というわけで、今のところActualTextが唯一の方法なのかな
本来は構造化とかタグ付け目的なのかもしれんけど、それでグリフとコードポイントの
対応もローカルにカスタマイズできるというか
412: 08/07(木)23:01 ID:lZ/0qeLw(2/3) AAS
現状、それを生成できるPDFライブラリとそれを検索できるPDFビューアが限られるけど
ま、コピペするならPDFで出力する前の元の文書からどうぞ、って感じかね
そもそも元の文書の持つ論理構造はPDFにした時点で文書のレンダリング表現（って
言うのかな）に変換されるわけで、何かしら情報が変化しても不思議ではない、
というのが個人的感想ですが
もちろんこうしてアドビさんは頑張っている一方、それを理解していない人々も多々...
413: 08/07(木)23:05 ID:lZ/0qeLw(3/3) AAS
そういえば、ネット上で色んなPDFが検索できるけど、中にはActualTextを使わずに
複数コードポイントが混在できているのもあった
それはフォントを切り替えることでグリフが重複していないのだった
PDFの生成主がそれを意図的にやったのかは不明だが
414: 08/17(日)14:45 ID:2MRCWKC9(1) AAS
康煕部首の「長」と普通の「長」がコピペで混在できる（こともある）PDFを
作ってみましたが、いかがでしょう
外部ﾘﾝｸ:drive.google.com
とりあえずGoogle Driveが立ち上げるPDFビューアではうまくいかない模様w
415: 08/18(月)08:42 ID:uGdRPz4N(1/2) AAS
ActualTextだとPDF内で該当文字が出てくるたび必要なので煩雑ではあるね
416: 08/18(月)09:08 ID:uGdRPz4N(2/2) AAS
この手のPDFでは、フォントは部分埋め込みなのでCMapも対応する部分だけで
よく、すると一般的な文書の文字範囲では1対1対応にできる（場合が多い）のに
MSの場合はそれでもバグっている、わけね
埋め込みフォントを作る時点ではもうグリフしか見てないということか
417: 08/19(火)15:11 ID:u9mpg9OM(1) AAS
Windowsのフォントをちょっと調べてみたら、MS明朝とか、「長」のグリフが重複していない
それでPDFを生成してみると... やはりコピペで文字化けしない
と言うわけでWindowsユーザーの皆さん、これからはMSのフォントだけを使う、
と言うのはどうだろうか。游明朝とかのことは忘れて
WindowsのPDF生成ドライバーもそれを望んでいるのかもしれない
418(3): 08/19(火)16:58 ID:fPjlHGI2(1) AAS
別にMSじゃなくても伝統的な日本語（JIS系や adobe-japan系）の文字しか入ってないフォントで重複してることなんてめったにないよ
複数の国の文字（中国漢字など）や異なる用途の文字（部首素片など）を同じフォントに収録してる場合にグリフ重複させる場合が多い
最近 google の Noto フォントみたいな多言語対応フォントを使い始めるやつが増えて問題を「再発見」してるだけ
そのせいで unicode のせいだとか言い出すアホが湧いてたわけだが（当然だがフォントには unicode に関係なく任意の文字とマップが登録できる）
419: 08/19(火)23:57 ID:RalGdNCX(1) AAS
もちろんその通り
unicodeのせいだと主張してる人は根本的にわかっていない
420(1): 08/20(水)00:55 ID:hGmntMeI(1) AAS
>>418みたいのって、どこかに書いてあるのでしょうか
それとも純粋に個人的な発想でしょうか
421(1): 08/20(水)01:07 ID:gymbsza2(1/2) AAS
>>420
opentype とか truetype とかもっと古い type1 とかフォントの規格と歴史を勉強しろ
422: 08/20(水)13:03 ID:NLPMnvCO(1) AAS
>>421
なるほど、そういったものを経て>>418のような知識につながったと。興味深いです
423(1): 08/20(水)14:23 ID:bjR6GZEK(1/2) AAS
>>418
お前が相変わらずアホなだけ
実際、SJIS時代に多言語対応フォントなんて誰も使ってなかったろ
お前は仕様的に出来る/出来ない事と、実際にみんながどう運用してるかの区別が付いてない
仕様が完全でなくても、通常の運用では十分カバー出来てた事を、
無駄に意識高いお前のような馬鹿が「仕様ガー悪いノデー僕は悪くアリマセンー」なノリで不用意に
そこらの意識低いド平民にも問題を強制的に「再発見」させたのはunicodeだろ
省12
424: 08/20(水)15:48 ID:EXUVzrtL(1) AAS
絶対負けを認めないマン
425: 08/20(水)16:40 ID:bjR6GZEK(2/2) AAS
勝った負けたではなく、俺の認識はこう、ということ
お前がそう思わないのはお前の自由
(というか、何でも勝った負けたになるのは議論出来ない馬鹿の特徴
そもそも「議論」に勝った負けたはない
勝った負けたがあるのは「討論」＝決を採る段階で、5chで(というよりネットで)決採る意味はないから、
そもそもネットでのほぼ全部の議論に勝った負けたはない
その辺ひろゆきも大幅に勘違いしてるし、信奉者も同程度
省10
426: 08/20(水)16:44 ID:rn5+zHEj(1) AAS
さんざんマウント取る言い方してきて、勝った負けたの勝負じゃないだとw
クソダサ
427(1): 08/20(水)17:25 ID:6T31eh60(1/2) AAS
>>423
SJISなんてものを褒め称えるとはマイクロソフト信者かね
昔からメールなどネット上ではいわゆるJISコード(ISO-2022-JP)が使われてきてこちらが国際的にも通用する主流でUNIXなどではEUC-JPが標準
もちろん今では国際的にUNICODEで統一され符号化はネット上もファイル保存もUTF8だがマイクロソフトさんは
428: 08/20(水)18:20 ID:gymbsza2(2/2) AAS
unicode 出る前からフォントは複数の文字コード対応マップで多言語化されれたことを知らないんだろうな
429: 08/20(水)19:22 ID:6T31eh60(2/2) AAS
SJISが世界の全てだった人なんだろうね
430: 08/20(水)21:05 ID:Qtedysji(1/2) AAS
>>427
JISがメールで使われてたのは7bit透過だからだぞ
SJIS信者だと思うのは自由だが、PDFのコピペに関しては、今風に言うと現場猫だよ
PDF仕様猫：グリフが重複して使われるフォントなんて普通ないからヨシッ
PDF出力アプリ猫：同上、ヨシッ
google猫：PDF出力アプリが対応してればグリフが重複してもヨシッ
unicode猫：同じ字(でもないが)に複数の文字コードを割り当てても、アプリかフォントが対応してればヨシッ
省10
431: 08/20(水)21:08 ID:Qtedysji(2/2) AAS
ん？2行連続空行は削除されるようになったのか？
まあちと読みにくくなってるが、よろしく
432: 08/21(木)02:20 ID:X0ZtFPzr(1) AAS
一つ一つの技術を正しく理解していないから、文字通り「個人の感想ですよね」という
まあ5ちゃんだし、酒飲み話みたいのもアリだとは思うけど
正しい知識が元になっていればそれは役に立つ話にもなる
一方読む方は間違いを間違いと見抜く力が.... って決してひろゆき信者ではないw
433(1): 08/21(木)02:56 ID:D3EzSAOJ(1) AAS
私も世界にSJISさえアレば良かった人間です(過去形)。欲しい文字は外字にドット打ってました。
ROMに第2水準程度しか乗っていない8ビットや16ビット世代のマシンでUTF8を構築するのって、現実的に可能なのかしら。
興味本位の疑問だけど。
434: 08/21(木)04:47 ID:HC849JP7(1) AAS
交換用符号としての扱いは楽だけど
ROMのコードがJISだから変換マップをオンメモリにするのは厳しそう
索引付きでないと性能でないと思うから
これもROMで持てるならあり
もちろん幅や方向、合字なんかは扱えない
435: 08/21(木)05:18 ID:mNeC3fTJ(1) AAS
>>433
そこはSJISとUTF8といった符号化方式の比較でなくてJIS漢字コードとユニコードの比較で十分
漢字ROMのデータ収録順序はJIS漢字コードの機械的変換できる範囲内だろうから
ユニコードからJIS漢字コードへのマッピング
436(2): 08/21(木)05:33 ID:lFCpHxq7(1) AAS
いわゆる半角カタカナ等(JIS X 0201)と全角漢字等(JIS X 0208)のほとんどは規則的変換できるようにユニコード内に収容されている
例外は一部の記号や文字のみ
したがって漢字ROM読み出しもほとんどは規則的変換できて例外のみ対応で実用的かな
437: 08/21(木)06:14 ID:BA9KDvPD(1) AAS
漢字は厳しいだろ
偶然だが半角の途中まではEF BDを前置するとUTF8
A1 ｡ EF BD A1
AF ｯ EF BD AF
B0 ｰ EF BD B0
B1 ｱ EF BD B1
B2 ｲ EF BD B2
省4
438(1): 08/21(木)08:42 ID:YIWSP+jR(1/2) AAS
>>436
JIS/SJIS/EUC: 外部ﾘﾝｸ[htm]:manuals.ricoh.com
unicode: 外部ﾘﾝｸ[html]:www.asahi-net.or.jp
さすがゆとりZ、無敵すぎ
439: 08/21(木)09:07 ID:4FAr+8B9(1) AAS
>>436
昔のAIにSJISをunicodeに変換するコード書かせたら何故かテーブルもってなくて機械的にシフトと論理演算で変換できますってコード出されたって話を思い出した
お前、そのAIだったりしないか？
440(1): 08/21(木)16:15 ID:jm5fSTrV(1) AAS
>>438
>JIS/SJIS/EUC: 外部ﾘﾝｸ[htm]:manuals.ricoh.com
区点コードで文字入力とはシブい。しかし字形が2004じゃないのは果たして
マニュアルだけの話でプリントで使うフォントとかは別なのかな。にしても
441: 08/21(木)21:08 ID:YIWSP+jR(2/2) AAS
>>440
何が言いたいのか分からんが、こちらの意図を明確にしておくと、
ただ単に「JIS 漢字表」でググって並び順が見やすいのを選んだだけ
コードなら以下が見やすいかと
外部ﾘﾝｸ[html]:www.infonet.co.jp
JIS等は漢字もあいうえお順(ricohのサイトはまんまアイウエオで見やすい)
てかunicodeって何順？
442: 08/22(金)21:59 ID:SVHvHw/K(1) AAS
外部ﾘﾝｸ[html]:www.asahi-net.or.jp
＞UnicodeのCJK統合漢字は、概ね部首順(部首内は画数順)に並んでいます
443(1): 08/23(土)02:24 ID:/wnxORck(1/4) AAS
しかしこれらの部首って、例のUnicodeの漢字部首のコードポイントに頼らなくても
出せるのね。元々各国の文字コードに部首のコードがあってそれがUnicodeに
引き継がれているようで
JISでも第二水準にちょいちょい部首が入っている。冫（にすい）とか
だがしかし「さんずい」や「しんにょう」などは第二水準にはない
これって何故でしたっけ。まさか さんずい＝水に「包摂」とか? ???
444(2): 08/23(土)06:47 ID:0WleoknD(1/5) AAS
>>443
氵も 辶 もJISにあるだろ (JIIS補助漢字または第4水準だが、包摂ではない)
もちろん Unicode も部首素片以外に漢字側にも登録がある
冫だけ第2水準なのは教科書とかで使用例があったから（うろ覚え）
445(2): 08/23(土)07:30 ID:0WleoknD(2/5) AAS
大元の理由が知りたいというい意味ならこの辺は漢字の歴史に由来していて
「冫」は甲骨の時代から独立した漢字で「氷」は字源的には「冫+水」の「冰」の略字
「氵」は「水」が部首になった時の省略形で昔の漢字では2つは全く同じ字形
unicode でも「冫」は漢字としてのみ登録されていて、部首素片(CJK Radical)には無かったはず
446(1): 08/23(土)08:40 ID:baE/iOEd(1) AAS
>>444
「第二水準内で」（第四水準がなかった時代に）という意味です
第四がある現在では包摂の適用が変わりましたので
>>445
JISの中の人がどう考えていたのか気になりました
「冫」は康熙部首の方にありますね(U+2F0E）
どうやら康熙部首がメインでCJK部首が補助のようですが、件の「長」は何故か両方に
省2
447(1): 08/23(土)08:52 ID:wdSAuDDp(1) AAS
>>444
「第二水準内で」（第四水準がなかった時代に）という意味です
第三以降では包摂の適用が変わったので、同列には語れません
>>445
JISの中の人がどう考えていたのか気になりました
「冫」は康熙部首の方にありますね(U+2F0E）
どうやら康熙部首がメインでCJK部首にはそのバリエーションが
省3
448: 08/23(土)08:56 ID:yzoynflT(1) AAS
失礼、投稿が失敗したと思いダブリました（&少し書き直した）
449(1): 08/23(土)09:10 ID:0dLwdQt1(1) AAS
>>446
> CJK部首の「長」は縦の棒が上から下まで繋がっている（画数が-1）とかいう話
ならばgoogle猫が手抜きで糞フォントを作ったのがPDFコピペ文字化けの元凶だな
日本人の美的感覚では、(この辺は習字を見れば分かりやすい)
「長」の縦棒は、上よりも下のほうが少し左側(下のほうが広く見える)が美しいとされるので、
真面目にフォントを作れば同じグリフになることはない
450(1): 08/23(土)12:38 ID:0WleoknD(3/5) AAS
>>447
そういう意味なら「康熙部首」はもともと部品じゃなくて普通に使われる漢字なのでJIS的には漢字として登録されるのは問題ない
（康煕部首を漢字以外に登録しているunicode が変というかローマ数字の ⅰ がアルファベットの i と別にあるみたいな変さ)
「氵」とかは伝統的な漢字じゃないので（辞典類の索引くらいしか）単独の用例が存在していなかったのが理由じゃないかな
国語の教科書とかでも康煕準拠で「冫の部」とういう表記は使われるけど「氵の部」という部首は存在してなくて「水の部」と書かれてる
第3、第4水準の包摂基準は原則として第1、第2の基準を援用してるので第2水準で包摂されていたら第4水準に追加できないので、逆説的に第4水準に追加されたことは包摂されていなかった解釈になる（補助漢字はかなりあやしい
451: 08/23(土)12:45 ID:0WleoknD(4/5) AAS
>>449
文字をどのようにデザインするかはフォントごとの勝手、文字コードでは規定していない
いやならそのフォントを使わなければ良い
ゴシック体で画数と意識してられるかアホらしい
452(1): 08/23(土)14:58 ID:/wnxORck(2/4) AAS
あ、すみません
> CJK部首の「長」は縦の棒が上から下まで繋がっている（画数が-1）とかいう話
ちょっとこの部分はガセかもしないので皆さん一旦忘れてもらえますか?
「長」が康熙部首とCJK部首（補助）に登場するのは事実ですが
453(1): 08/23(土)15:25 ID:0WleoknD(5/5) AAS
>>452
unicode には4つの「長」の部首素片が登録されてるメインに1つ、補助に3つ
多分メインのやつが字形を無視した意味上の部首素片で、補助のやつが unicode の包摂基準に従って分離された字形
454: 08/23(土)15:38 ID:/wnxORck(3/4) AAS
>>450
> 「氵」とかは伝統的な漢字じゃないので（辞典類の索引くらいしか）単独の用例が存在していなかったのが理由じゃないかな
なるほど、そんな感じですかね
455: 08/23(土)15:54 ID:/wnxORck(4/4) AAS
>>453
基底クラスに派生クラスが3つ、みたいな感じですかね
部首周りは思ったより複雑ですなw
456(1): 08/25(月)08:21 ID:y+b0tsbW(1/2) AAS
今回の話はほぼ部首由来だけど、そうでないのも少しありそう
U+6AF8（櫸）は「ケヤキ」らしいがこれ以外にU+237F1（𣟱）という字もあり、
この両者に同じグリフを使う場合がある
ちなみに例の坂道グループのはU+6B05（欅）、つくりの下側が「手」
ここらへんの文字がちゃんと扱えるのかのテストでもある
457: 08/25(月)08:51 ID:y+b0tsbW(2/2) AAS
ちなみに台湾の日本アイドルファン系のサイトには、U+6AF8を使っている
サイトが散見される.。まあ無理もないことではある
しかしそれだと日本の情報を十分に集められなかったのではなかろうか
まさかそれを嫌って櫻坂に改名したとしたら、なかなかの文字コード通か?
しかし今度は中国本土の人がU+6A31（樱）を使ってしまう可能性もある
458: 08/25(月)08:56 ID:4e0IOAiN(1/2) AAS
そもそも unicode の統合基準がグダグダなので unicode では同じ字形の文字が複数あるのが当然になってる（IVS/IVDも入れると同じ字形の漢字が3つも4つもあったり
あと1つのフォントには最大で65536グリフしか登録できないので多くの文字を登録したい場合やフォントサイズを圧縮したい場合は同じ字形は一つのグリフで表すというのも普通のテクニックになってる
459(1): 08/25(月)15:28 ID:WuqY0NEW(1) AAS
>>456
Unicodeは各国にある規格を取り込む、というのはまあまあやっていて
U+6AF8は台湾で使われる字、U+237F1は日本などで用例のある字、
で本来グリフにも差があるらしい
460(1): 08/25(月)18:00 ID:4e0IOAiN(2/2) AAS
>>459
U+6B05 は旁の下部が手なのでおいておいて
もともとU+6AF8 は横棒二本と横棒三本が統合(unify)されてる（日本語フォントだと三本、中国語フォントだと二本で表示されるのが一般的、
二本と三本を指定したい時は IVS をつけるのがルール、具体的には U+E0100 をつければ日本で一般的な adobe-japan の横棒三本の字体を明示的に示せる
IVS なんか知るか独立のコードポイントよこせという大陸様のゴリ押しで、横棒三本が別に U+237F1 に登録された
このせいで日本語フォントで表示すると両方が横棒三本の同じ字形という状態になってる（中国語フォントなら二本と三本で別の字形になる
461(1): 08/26(火)15:23 ID:yhOjjAzx(1) AAS
>>460
例えば
>IVS なんか知るか
U+237F1が入ったのはIVSより前じゃね?
462: 08/26(火)17:54 ID:Bsu3S+Ad(1) AAS
>>461
ちょうど同じ時期に並行して議論されてたんだよ
正式な規格書にコード位置が載ったのは Ext-B の方が少しだけ早かったかも
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s