正規化・互換漢字・IVS

@works014さんの「異体字/IVSなどなど」 http://togetter.com/li/145839 の続き。先に「IVSと正規化について」 http://togetter.com/li/88888 を読んでおくといいかも。
インターネット Unicode IVS 正規化 互換漢字
4878view 2コメント
20
Koji Ishii @kojiishi
OS、アプリ、IMEにきれいに入ればユーザーに対して透明にできると思うんですが、今のIVSだとこれらの層との協調が悪くて、それを解決しないと難しいな、と @0guma 私の周囲3m内外でも、その技術を誰も使いこなせないだろうな、と思える辺り、如何ともし難い @ogwata
tomo.(むにゃむにゃ) @MnjaMnia
(既存の IVD よりも荒い)字体/抽象グリフレベルの IVD(ないしは、そういう風な運用)は現実問題として必要だと思うんだけども(だから、私も細々と試行錯誤してる訳だけども)、現実問題としてなかなか難しそうなのも事実なんだよなぁ。
Kiyonori Nagasaki @knagasaki
おお! RT @MnjaMnia: 理想的なグリフオントロジーをすぐに作るのは無理だとして、まず、いろんな包摂規準を機械可読に記述・操作できるような多粒度漢字構造情報の整備かなと思ってるんだけど、これもなかなか大変。
@キャンディーズはランちゃん @moji_memo
IPAmj明朝のU+59FF U+E0103が、ややこしいことになっているようだ。
@キャンディーズはランちゃん @moji_memo
U+59FF U+E0103(姿)、U+6B21 E0103(次)、U+8AEE U+E0103(諮)、U+8CC7 U+E0103(資)。Adobe-Japan1と汎用電子でIVSを統合あるいは正規化しようとすると、このあたりは問題になるな。
@キャンディーズはランちゃん @moji_memo
IPAmj明朝の(U+6FA0 E0101と)U+6FA0 E0102はバグ?
田原恭二 @taharakyoji
外字・異体字PJ、JAGATさんのこの表現「しかし、これらは各々の目的に応じて文字集合を整備することを目指しており、共通して利用するための基盤を整備することを目的にはしていなかった。つまり、これまで外字を総合的に管理しようとする試みは、ほとんどおこなわれてはいない」がいちばんOK
@キャンディーズはランちゃん @moji_memo
IPAmj明朝の(U+9C76 U+E0101と)U+9C76 U+E0102はバグだろうな。
@キャンディーズはランちゃん @moji_memo
IPAmj明朝検証版のバグと思われる字形について、ブログにメモしておきました。 http://bit.ly/mMiWuf
Koji Ishii @kojiishi
フォントと結びつきすぎてるとこ。文字コードでなくグリフID的なものなら、文字列APIでは扱えない @ogwata なるほど。現在のIVSのどの辺りが「透明でない」と感じますか? RT @kojiishi: OS、アプリ、IMEにきれいに入ればユーザーに対して透明に… @0guma
小形克宏 @ogwata
確かにフォントに依存する限りプレーンテキストになり得ない。なるほど。RT @kojiishi: フォントと結びつきすぎてるとこ。文字コードでなくグリフID的なものなら、文字列APIでは扱えない @ogwata IVSのどの辺りが透明でない? RT @kojiishi @0guma
小形克宏 @ogwata
@kojiishi DTP等、用途を限定すればフォントに依存しても全然構わないのだけど、問題はIVSがくっついたままネットに流れたりすることが十分に考えられることですね…。
Koji Ishii @kojiishi
規格制定者の「前提」は往々にして破られる。なのでIVSをもう少し中間的なものに変えて将来困らないようにしよう、と @ogwata DTP等、用途を限定すればフォントに依存しても全然構わないのだけど、問題はIVSがくっついたままネットに流れたりすることが十分に考えられることですね…
Koji Ishii @kojiishi
そうなのかな。それって共通理解? 字形には依存するけど、Unicodeである以上、グリフIDじゃなくて文字コードだと思うんですが @ogwata ただ逆に言えば、フォントに依存するのはIVSの基本ですから、それはもうどうしようもない問題ですよね。IVS以外の選択肢を求めざるを得な
小形克宏 @ogwata
@kojiishi それは正論。ぼくも賛成です。しかし問題は、グリフを情報交換する技術が「今」求められていること。背景には改定常用漢字表の追加字の扱い、それから電子書籍への要求。規格から考え直すタイミングではないところが難点。
Y.Mihashi | 三橋洋一 @ymihashi
@ogwata @kojiishi 「フォントに依存する」というのが、フォントによって特定の文字があったりなかったりする、という意味なら、現在流通しているUnicodeベースのフォントはすでにそうですよね。そういう意味ではないのでしょうか。
小形克宏 @ogwata
規格的にはそうだと思います。しかし実際のユーザーへの浸透は、フォントを意識させる形ですすむのでは? RT @kojiishi: そうなのかな。それって共通理解? 字形には依存するけど、Unicodeである以上、グリフIDじゃなくて文字コードだと思うんですが @ogwata
Y.Mihashi | 三橋洋一 @ymihashi
@ogwata @kojiishi たとえばメイリオとヒラギノとでは、Unicodeベースですでにそれぞれのフォントが持っている文字は異なります。
小形克宏 @ogwata
@kojiishi つまり「●●というフォント、アプリを使えば、ほら、グリフが交換できますよ」というような。
Koji Ishii @kojiishi
「グリフの交換」には賛成ですが「グリフIDの交換」には賛成できない。運用の問題なので対応可能ですよ @ogwata それは正論。ぼくも賛成です。しかし問題は、グリフを情報交換する技術が「今」求められていること。背景には改定常用漢字表の追加字の扱い、それから電子書籍への要求。規格か
小形克宏 @ogwata
@ymihashi その違いはOSのフォールバック機構で吸収していると思います。じゃあIVSはどうするの、というのが難問。
小形克宏 @ogwata
@kojiishi ?? UTS#37の考え方は、特定のグリフをidentifyするものではないのではないでしょうか?
tomo.(むにゃむにゃ) @MnjaMnia
それは本当? RT @ogwata: ただ逆に言えば、フォントに依存するのはIVSの基本ですから、それはもうどうしようもない問題ですよね。IVS以外の選択肢を求めざるを得ないでしょう。
tomo.(むにゃむにゃ) @MnjaMnia
まあ、でも、何でそうなっちゃうかというと、思うに、今世の中で一番普及してる文字データベース(オントロジー)交換フォーマットがフォントだから、なのかも知れない(フォントを使ってる人は本当にフォントを使ってるのだろうか?)
残りを読む(464)

コメント

狩野宏樹 @KAN0U 2011年6月21日
追加と、無関係な記事の削除。
ログインして広告を非表示にする
ログインして広告を非表示にする