アカウント名:
パスワード:
今さらU+FA20を互換漢字から統合漢字に変更するのはstablility policy的に無茶な気がします。U+FA20と同じ字形を統合漢字として新たに追加提案するほうがまだ見込みがありそうです。Unicode 3.2以降に互換分解マッピングを訂正した前例もあるにはありますが、Unicode 6.1では訂正しないで互換漢字の追加で対処するみたいですし。> IVSの基底文字に互換漢字を許してしまう許されても分解マッピングが訂正されない限りU+FA20 U+E0100の正準分解はU+8612 U+E0100になってしまうので、ちっとも嬉しくないです。「互換漢字を基底文字にしても構わないが選択されうる字形は正準分解後のIVSと常に同じで、独立して登録することはできない」ならアリかも。U+8612 U+E0100とU+FA20 U+E0101とか書けるようになるので。
> 互換分解マッピング「互換漢字の分解マッピング」に訂正
ま、私も正直なところ
互換漢字を基底文字にしても構わないが選択されうる字形は正準分解後のIVSと常に同じで、独立して登録することはできない
あたりが落とし所かな、とは思うのですが。つまり、「U+FA20 U+E0101」は「U+8612 U+E0101」と同じだが、font fallback [srad.jp]に関してはそれぞれ「U+FA20」と「U+8612」に落ちる、というあたりが妥協点じゃないかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
N1698が提出された時点ならともかく (スコア:1)
今さらU+FA20を互換漢字から統合漢字に変更するのはstablility policy的に無茶な気がします。U+FA20と同じ字形を統合漢字として新たに追加提案するほうがまだ見込みがありそうです。Unicode 3.2以降に互換分解マッピングを訂正した前例もあるにはありますが、Unicode 6.1では訂正しないで互換漢字の追加で対処するみたいですし。
> IVSの基底文字に互換漢字を許してしまう
許されても分解マッピングが訂正されない限りU+FA20 U+E0100の正準分解はU+8612 U+E0100になってしまうので、ちっとも嬉しくないです。
「互換漢字を基底文字にしても構わないが選択されうる字形は正準分解後のIVSと常に同じで、独立して登録することはできない」ならアリかも。U+8612 U+E0100とU+FA20 U+E0101とか書けるようになるので。
Re: (スコア:1)
> 互換分解マッピング
「互換漢字の分解マッピング」に訂正
互換漢字のIVS (スコア:1)
ま、私も正直なところ
あたりが落とし所かな、とは思うのですが。つまり、「U+FA20 U+E0101」は「U+8612 U+E0101」と同じだが、font fallback [srad.jp]に関してはそれぞれ「U+FA20」と「U+8612」に落ちる、というあたりが妥協点じゃないかと。