異体字/IVSなどなど

tomo.（むにゃむにゃ） @MnjaMnia

100万字を識別したり管理するのは現状では無理なんです。なので、Unicode は Unicode に逆らった仕組みを入れたというかw RT @shinji_kono: そこまで頑張って、それなりに頑張ってるUnicodeに逆らって得られるものが何かって言う疑問はあるな～…

tomo.（むにゃむにゃ） @MnjaMnia

でもって、（オントロジーのない状態で）オントロジーなしでも動くように頑張ろうとすると多分バグると思う。

tomo.（むにゃむにゃ） @MnjaMnia

字形の詳細をフォント制作者に任すと、多分、字形の詳細を指定したい！って人が出てくると思うw RT @KAN0U: …「旧字体のテキストには必ずE01E2をつける」というようにSelectorが統一されていると楽だし、字形の詳細をフォント制作者に任せられる。仕組みを変えずIVS割…

UTF-8はBOMなしでって言ったよね？ @moji_memo

@KAN0U なるほど。Private Use IVSみたいな枠組みなら、ちょっと現実的（？）かもしれませんね。

tomo.（むにゃむにゃ） @MnjaMnia

考えてみれば、これは、ある意味、スクリプト指示子ですよね。 RT @KAN0U: 漢字1文字ごとに後置するのは現状のままです。ただ「旧字体のテキストには必ずE01E2をつける」というようにSelectorが統一されていると楽だし、字形の詳細をフォント制作者に任せられる。仕組みを…

小熊善之 @0guma

@KAN0U @moji_memo 「旧字体とはなにか」「当用漢字表に書かれたどの文字が旧字体か」「新字体の別字との字体衝突の解決はどうする」などの議論が巻き起こる悪寒。

tomo.（むにゃむにゃ） @MnjaMnia

あ、そうか。このやり方は『IVS 全体としての包摂規準』を決めても両立するのか（というか、それが暗黙の前提?）RT @KAN0U: 例えばE01E0は「改定常用+人名+印標+exptモード」、E01E1は「旧字体（所謂康煕）モード」、E01E2は「もう少し古臭い康煕字典モード」…

tomo.（むにゃむにゃ） @MnjaMnia

TL を眺めてると、なんとなく、「少年は荒野をめざす」を思い出す（狩野さん＋小林くん w）。

小熊善之 @0guma

@moji_memo 一応マジレスしとくと、うちのボスは包摂については文字感データベースを別途構築して、文字コードの外でやれという提案をしていたと思う。国や時代ごとの包摂の違いをDBで吸収しよう、と。

Koji Ishii @kojiishi

OS、アプリ、IMEにきれいに入ればユーザーに対して透明にできると思うんですが、今のIVSだとこれらの層との協調が悪くて、それを解決しないと難しいな、と @0guma 私の周囲3m内外でも、その技術を誰も使いこなせないだろうな、と思える辺り、如何ともし難い @ogwata

狩野宏樹 @KAN0U

私の提案は、細かくなる一方の既存IVDの包摂規準より粒度の粗い包摂規準を導入しようというものですから、本体の包摂規準とは別のものとして同時運用できます。 RT @MnjaMnia: このやり方は『IVS 全体としての包摂規準』を決めても両立するのか（というか、それが暗黙の前提?）

狩野宏樹 @KAN0U

自分で細かくやりたい場合には若い番号のIVSを直接指定して詳細字形指定を行えるはずです（各フォントがエイリアスの元になったIVDをフル実装していることを前提）。 RT @MnjaMnia: 字形の詳細をフォント制作者に任すと、多分、字形の詳細を指定したい！って人が出てくると思うw

tomo.（むにゃむにゃ） @MnjaMnia

（既存の IVD よりも荒い）字体／抽象グリフレベルの IVD（ないしは、そういう風な運用）は現実問題として必要だと思うんだけども（だから、私も細々と試行錯誤してる訳だけども）、現実問題としてなかなか難しそうなのも事実なんだよなぁ。

小形克宏 @ogwata

なるほど。現在のIVSのどの辺りが「透明でない」と感じますか？ RT @kojiishi: OS、アプリ、IMEにきれいに入ればユーザーに対して透明にできると思うんですが、今のIVSだとこれらの層との協調が悪くて、それを解決しないと難しいな、と @0guma @ogwata

Koji Ishii @kojiishi

フォントと結びつきすぎてるとこ。文字コードでなくグリフID的なものなら、文字列APIでは扱えない @ogwata なるほど。現在のIVSのどの辺りが「透明でない」と感じますか？ RT @kojiishi: OS、アプリ、IMEにきれいに入ればユーザーに対して透明に… @0guma

小形克宏 @ogwata

確かにフォントに依存する限りプレーンテキストになり得ない。なるほど。RT @kojiishi: フォントと結びつきすぎてるとこ。文字コードでなくグリフID的なものなら、文字列APIでは扱えない @ogwata IVSのどの辺りが透明でない？ RT @kojiishi @0guma

小形克宏 @ogwata

@kojiishi ただ逆に言えば、フォントに依存するのはIVSの基本ですから、それはもうどうしようもない問題ですよね。IVS以外の選択肢を求めざるを得ないでしょう。

小形克宏 @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 つまり「●●というフォント、アプリを使えば、ほら、グリフが交換できますよ」というような。