STANDARDIZED VARIANTSに「黒四角囲みA」が含まれない理由


  • STANDARDIZED VARIANTSが拾っているのは、基本的に「ケータイ絵文字がUnicodeに収録された時点で既存の符号位置に統合されたもの」なので、Unicode 6.0で入った「A」はケータイ絵文字（単独）ソースと見なされ対象外。しかしAdobe-Japan1フォントには、以前から黒四角囲みのアルファベットはすべて入っている。したがって、Unicode 6.0をサポートした（黒四角囲みのアルファベットのマッピングが追加された）Adobe-Japan1フォントを用いる環境では、「A」にも衝突が発生する。STANDARDIZED VARIANTSは、このようなケースに対応していない。
  • というわけで、黒四角囲みのアルファベットのなかで「絵文字じゃない文字」と「絵文字」が衝突する「A」「B」「O」「P」のうち、（ARIB外字をソースとして）Unicode 5.2に入っていた「P」はSTANDARDIZED VARIANTSに含まれるが、Unicode 6.0で追加された「A」「B」「O」は含まれない、というわかりにくいことになっている（下図）。


  • で、「A」「B」「O」にはバリエーション・シーケンスが使えなくて困るよねと書こうと思っていたのだけれど、実はMountain Lionで試してみたら、「A」「B」「O」などにも「絵文字スタイル」を指示するU+FE0F（VS-16）が効いてしまうことを発見*1。この実装は、規格上はちょっとアレな気もするが、まあ、そのほうが便利かな。

*1:Mountain LionでU+FE0F（VS-16）がStandardizedVariants.txtに登録済みのシーケンス以外でも効いてしまう例には、本文で触れた<1F170, FE0F>、<1F171, FE0F>、<1F17E, FE0F>以外に、<00A9, FE0F>、<00AE, FE0F>、<2122, FE0F>がある。また、「keycap symbol #」のEmoji Style用のシーケンスは<0023, FE0F, 20E3>だが、Mountain Lionでは<0023, 20E3, FE0F>でも同じ結果になる。[0-9]のkeycap symbolも同様。