[380] 基底文字に異体選択子を組合せた異体列は、 基底文字が表す字形を限定したものです。
[381] IVS は漢字を対象としたもの、 EVS は絵文字を対象としたもの、 SVS はその他のものです。
[31] Unicode文字は、 いろいろなグリフによって表現され得ます。 ときにテキスト処理において文字を表現するのに使うグリフの集合を制限したり、 変更したりする必要が生じることがあります。 >>30
[32] 通常それはリッチテキスト文書でフォントやスタイルを選ぶことで示します。 しかし特殊な状況 (※ >>382) では、 そうした通常の見た目の範囲との違いを、 平文で書式付きテキストを交換するのが不可能か不便であるとしても、 同じ文書に並べて表現する必要があったりもします。 >>30
[34] そこで異体選択子は特定の文字の表現に使うグリフの集合に対して制限を指定する仕組みを提供するのであります。 >>30
[35] 加えて、 異体選択子は、 CJK漢字やモンゴル文字におけるような、 本質的に同じ意味を持ちながら実質的に違ったグリフの範囲を持った、 異体を指定する仕組みを提供するのであります。 >>30
[36] つまるところ、 異体選択子は、 Unicode が過剰に統合して 1つの文字として扱っているものを、 より細かく区別して扱うための救済措置的に使えるものとなっています。
[382] なお Unicode のいう「特殊な状況」とは、 Unicode の世界観で「特殊」とされるものです。 それは世界各地の一般の人々の文字生活上「特殊」とは限りません。
[37]
Unicode文字が必ずしも一般に認識される
「文字」
と一致しない
[472] たまに文字コードや漢字をちょっと齧ったくらいの知識の人が、 「新しい符号位置を追加しないで異体字セレクタで異体字を表現するべきだ」 と主張することがあります。 しかしほとんどの場合この主張は誤りで、その人が思っている「異体字」 は Unicode の異体字セレクタが表現可能な「異体字」ではありません。 意図的ではないにせよ 「今の Unicode を破壊して自分の思う新しいアーキテクチャーを採用するべきだ」 という主張になってしまっています。
なお>>90も参照。
[125] ある文字のグリフ的部分集合とは、 その文字の表示に適切なグリフ群の部分集合です。 >>19 符号点が文字を表すように、 異体列はグリフ的部分集合を表すものです。 このグリフ的部分集合という語はなぜか The Unicode Standard ではなく UTS #37 で定義され IVS の説明にしか使われていませんが、 その定義された意味は他の異体列にもそのまま通用するはずです。
[204] 「グリフ」 (単数) ではなく「グリフ群」の集合と説明されていますが、 蒙古文字のように文脈でグリフが変化する場合はもちろん、 漢字のような文脈変化がない場合でも、 特定フォントの特定グリフだけを指すような限定的な指定ではなく、 もう少し広い範囲の「同じようなグリフ」を指しています。 ただしその「同じような」の具体的範囲は定められていません。
[205] 異体列のグリフ的部分集合だけでなく、 文字のグリフ群についても具体的範囲を Unicode は定めていません。 むしろ逆に異体列が定義されて代表グリフが提示されることで、 Unicode文字の代表グリフ以外にもこんな字形までその Unicode文字の範囲に含まれていたのかと知ることができます。
[137] ある文字に関する各異体列のグリフ的部分集合は、 互いに素とは限りません。 このことは IVS について明記されています >>19 が、 他の異体列についても同様です。 IVS でもそれ以外でも、 代表グリフが同じように見えるものすら散見されます。
[87] 異体列は、 元の Unicode文字の意味的範囲に含まれる字形のうちの一部分を表す、 という立て付けで規定されています。 元の Unicode文字と同じ意味の別の文字を指すものではありません。 従って元の Unicode文字の範囲に含まれないと思われるような、 著しく異なるものが異体列で表されることはありません。 この設計ゆえに、異体選択子に未対応だとしても、 基底文字だけを見て処理できるということになっています。
[88] そのため、 異体の区別のためには、 元のUnicode文字と異体列との区別では意味がなく、 異体列と異体列との区別にしなければいけません。
[89] 「令」 c について 「明朝体の令」と「楷書体の令」が異体選択子 v1, v2 で区別されるとするとき、 c と <c, v1> や c と <c, v2> の区別では意味がなく、 <c, v1> と <c, v2> で区別しなければなりません。
[90] かつては、異体字のために膨大な符号空間を占用されるのはけしからんから枝番形式にしろ、 という主張をする人達もいたようです。 Unicode の異体選択子は、 微小な違いを枝番形式で「節約」することにはなりますが、 微小でない違いは別の Unicode文字を追加しないといけないのですから、 「節約」にはなりません。
[91] 異体字を枝番方式で表せば、枝番部分を無視すれば簡単に曖昧検索できて便利だ、 といわれていました。異体選択子にもそれは当てはまりますが、 既に異なるUnicode文字として区別されている (または今後追加される)、 違いの大きな異体字の同一視もしないといけないので、 検索処理の効率化にはあまり貢献しません。
[390] 異体列として登録されたグリフ的部分集合と同じものを含む別のUnicode文字が後から追加されるというおかしなこともたまに起こっています。
[391]
例えば
2022-09-13
版の IVD
>>377
は
Unicode 15
によって新しく追加された CJK統合漢字
U+31350
用の IVS
<U+31350
, U+E0100
>
を追加しました。
[392]
これは
Adobe-Japan1
の
CID+19130
を表すものでしたが、
CID+19130
には以前から
<U+793A
, U+E0100
>
が登録されていました。
[393]
<U+31350
, U+E0100
>
と
<U+793A
, U+E0100
>
は同じもの
(Duplicate Sequence)
として
IVD_Stats.txt
に示されています。
[92] Unicode文字 ⊃ 異体列という構造は Unicode のアーキテクチャ的にはそれでいいのでしょうが、 実際の運用を思うと厄介なことも少なくありません。
例えばある文字 c の符号点がほとんどの場合その一般的な字形 v1 で表示されていて、 たまに使われる異体 v2 と区別したいとき、 確実に区別するなら <c, v1>, <c, v2> と書き分けなければなりません。
ですが、現実的にほとんどの場合 c が <c, v1> の意味で使われているのです。普通の人が普通の入力方法で作った文書には c と書かれているのに、それが通用しなくなるのは困りものです。
[39]
異体列は、
1つの基底文字または
spacing mark (General_Category=Mc
)
に、
1つの異体選択子文字を続けたものです。
これを基底文字または spacing mark
の異体といいます。
>>30
[107]
異体選択子は、適用対象の直後に置きます。 >>105
結合文字や
ZWJ
や
ZWNJ
を間に挟むことはできません。
[110]
自由異体選択子の古い実装は、
ZWJ
を併用する時、
基底文字、 ZWJ
, 自由異体選択子の順としていました。
古い The Unicode Standard でないドキュメントがこの順としていたためだといいます。
>>105
[47] 異体列には、 SVS, IVS, EVS の3種類があります。 >>30
[196] 適用対象となる文字が、 異体列の1文字目となります。 1文字目は基底文字か、 spacing mark です。
[51] 異体列の最初の文字が、 nonspacing combining mark や正準分解可能文字になることは、ありません。 これは、 正規化文における異体列の解釈の問題を防ぐための制限です。 >>30
[203] IVS には更に互換分解可能文字でないこととの制約が付きます (>>50)。
[197] 異体選択子は必ず適用対象の直後に来るとされています。 そのため基底文字に結合文字が続く列に異体選択子を適用することはできず、 合成済文字に異体選択子を適用することもできません。
[198] 例えば「ざ」の異体を区別したくても、「ざ」 + 異体選択子とすることはできません。 「ざ」は「さ」 + 結合文字の濁点と正準等価なので、 「さ」 + 異体選択子 + 結合文字の濁点、 と表現することになります。
U+180B
MONGOLIAN FREE VARIATION SELECTOR ONE
(FVS1
),
U+180C
MONGOLIAN FREE VARIATION SELECTOR TWO
(FVS2
),
U+180D
MONGOLIAN FREE VARIATION SELECTOR THREE
(FVS3
),
U+180F
MONGOLIAN FREE VARIATION SELECTOR FOUR
(FVS4
)FVS4
は Unicode 14.0 で追加U+FE00
VS1
- U+FE0F
U+E0100
- U+E01EF
VS256
[101] 兼用でもいいはずなのに、なぜか VS の種類ごとに使い分けられています。 既に種類ごとに違う方法で実装されてしまっていて、 今更兼用にもできないみたいです >>363。
[102] Unicode 4.0 追加分は第14面にあって、 UTF-8 でも UTF-16 でも4バイトで表されます (それ以外の文字は、 UTF-8 で3バイト、 UTF-16 で2バイトです)。 Unicode 4.0 時点では BMP に押し込められるだけの空き領域があったはずですが... SIP の漢字の IVS だと UTF-8 でも UTF-16 でも1つ8バイトにもなってしまいます。
[138] 違う基底文字に対して同じ異体選択子が適用可能だからといって、 それによって表される異体の関係性が同じとは限りません。 このことは IVS については明記されています >>19 が、他の異体列でも同様です。
[210]
例えばある文字に対して U+E0100
が2点しんにょうを表していても、
他の文字に対して1点しんにょうを表しているかもしれませんし、
さらに他の文字に対しては異体列が定義されていないかもしれません。
[139] IVS に使える異体選択子は 240 個あります。 Unicode Consortium は、 240 以上の IVS の登録が必要となった時、 新しい異体選択子を追加する >>19 とされています。
[194] それがどの程度現実性があるのか不明ですが、 実装は既存の異体選択子だけと決め打ちにせず、 将来の追加も想定しておく必要があるでしょう。
[48]
標準化済異体列
(SVS)
は、
UCD
の
StandardizedVariants.txt
>>17
で定義されます。
>>30
[24]
StandardizedVariants.txt
にはコメントとして
SVS
をいくつかの種類に分けています >>17。
それによると:
... があります。 (今後他の種類が増えることもあるでしょう。)
[80]
Manichaean
と
Mongolian
は、
適用される
shaping environment
が、
isolate
,
initial
,
medial
,
final
のうち1つ以上のみに限定されるとあります。 >>17
[81]
このうち
Mongolian
だけは、
専用の自由異体選択子文字を使います。
[67] 蒙古文字の異体は、 SVS に分類されていますが、 特別な扱いを受けています。 蒙古文字用には特別な異体選択子が3つ用意されています (>>8) >>105。 この異体選択子は蒙古文字だけに使われています。 蒙古文字には他の異体選択子は使われていません。 (この原則が将来にわたって維持されるのかは不明。)
[106] この蒙古文字の自由異体選択子は、 機械的に決定できないグリフ形が必要な時 (例えば外来語を書く時) に使います。 >>105
[109] 利用者は、 レンダリングシステムが自動的に正しいグリフを選択できないときのみ、 自由異体選択子を使うべきです。 >>105
[200]
ちなみに
Unicode
には数学用と称して太字、
フォント違いなどラテン文字のバリエーションが大量に、
ASCII文字とは別に用意されています。
それらはなぜか異体列ではなく独立した文字となっています。
[56] 各CJK互換漢字用に1つずつ、計1002個の SVS が定義されています。 >>30
[57] これは CJK互換漢字の正規化の問題の対策として定義されました。 CJK互換漢字を相当するCJK統合漢字と区別したい時がありますが、 CJK互換漢字はCJK統合漢字に正準等価な写像を持つ故、 正規化によってその区別が失われてしまいます。 そこでかわりに SVS を使えるのです。 >>30
[58] CJK互換漢字用 SVS は、 CJK互換漢字の符号点と一対一対応するものです。 IVD に登録された実装依存グリフに対応付けられた IVS とは違います。 >>30
[202] SVS と IVS は独立した判断で別の基準で追加されたため、 同じ字形のように見える漢字が SVS と IVS とで2種類以上 (+ 元々の CJK互換漢字でもう1種類) 存在する事例が多々あります。 混乱させたくてわざとやっているのではないかと思いたくなるほどの重複符号化祭です。
[59] CJK互換漢字用の SVS は、 CJK互換漢字に異体選択子を付けたものではなく、 相当するCJK統合漢字に異体選択子を付けたものとなります。 CJK互換漢字は正準写像を持つので、 異体列に使えないのです。
[60] CJK互換漢字の正準写像はCJK統合漢字単体であって、 CJK互換漢字用 SVS ではありません。 SVS に正準写像が変更されればさほど問題は生じなかったのですが、 正規化の仕様変更は認められていないのです。
それゆえ、 正規化をおそれて CJK互換漢字を避けるなら、 CJK統合漢字 + 異体選択子を使うことになりますが、 それが正しく表示されるのは適切なフォントを持っている環境のみ、 正しく処理されるのは対応した環境だけです。
CJK互換漢字をそのまま使っていれば、 正規化以外はまったく支障がなかったのが、 SVS に置き換えるとまったく使い物にならなくなってしまいますw (フォントの問題は過渡期の今だけだと思いたいですが...)
[61] それどころか同じ表現が CJK互換漢字と SVS の2通りになって、しかも両者は正規化で同一視される対象ではありませんから、 検索などで新規に個別対応が必要となってしまいます。 むしろ面倒事は増えています。
[62]
正規化は破壊的操作なので、オリジナルデータや重要なデータには使うべきではありません。
[428] Wayback Machine, https://web.archive.org/web/20110709094418/http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg30/IRGN1468IVS_Recommendation.pdf
[358] IRG N1676 (IRG 34) - 10211-irgn1676-adj1-ivs-upd.pdf, , https://unicode.org/L2/L2010/10211-irgn1676-adj1-ivs-upd.pdf#page=13
[359] >>358 この時点の構想では当時登録済みの Adobe-Japan1
IVS
と重複するものは共用しようとしていたようです。
[82]
次の2件は、
Unicode 3.2
で定義されたものの、
誤りとわかり
SVS
から削除された、
と
StandardizedVariants.txt
にコメントがあります。
>>17
#2278 FE00; with vertical stroke; # NEITHER LESS-THAN NOR GREATER-THAN
#2279 FE00; with vertical stroke; # NEITHER GREATER-THAN NOR LESS-THAN
[354] この削除された列が今後どういう扱いになるのか (再割り当てされるのか) よくわかりません。
[49]
絵文字異体列
(EVS)
は、
UTS #51
emoji-variation-sequences.txt
で定義されます
>>30。
[66]
古い
Unicodeの版では
EVS
は
SVS
に含まれていました。
当時
StandardizedVariants.txt
に記述されていた
EVS
は、現在の版では削除されているようです。
[44]
数字,
U+0023
(#
),
U+002A
(*
)
を基底文字とする絵文字異体列は、
それに対する結合文字
U+20E3
COMBINING ENCLOSING KEYCAP
の色、サイズ、位置決定に影響することが想定されています。
>>30
[11] Emoji Variation Sequences () http://www.unicode.org/emoji/charts/emoji-variants.html
[351] , https://standards.iso.org/iso-iec/10646/ed-6/en/emoji-variation-sequences.txt
[50]
表意文字的異体列
(IVS)
は、
2つの符号化文字の列であって、
1つ目が
Ideographic
であって正準的分解可能でも互換的分解可能でもないもの、
2つ目が異体選択子文字
[ U+E0100
, U+E01EF
]
であるものです。
>>19
[127] IVS には、異体選択子の通常の規則が適用されます。 IVS は、 関連付けられたグリフ的部分集合にレンダリングを制限したいときのみ、 使うべきです。 >>19
[123] IVS は、 UTS #37 の定める Ideographic Variation Database (IVD) >>21 に登録されています。 IVD に登録された IVS を登録済IVS といい、 それ以外の IVS を未登録済IVS といいます。 >>30
[208] SVS や EVS が Unicode Consortium の直轄で規定されるのに対し、 IVS は外部で定義されたものを Unicode Consortium に登録するという形をとっています。
[119] UTS #37 によると、 漢字その他の表意文字にあっては、 利用者の需要すべてを満足する異体列の単一の集成を構築することが不可能である、 すなわち研究者、政府、出版社の要件が異なりすぎて単一の集成に収容することが困難であるゆえに、 複数の独立した集成をもって各要件を満たせるようにしたものであります。 >>19
[120] IVD は、異体列を使ったテキストの情報交換を信頼できるものとするべく、 異体列に単一の定義を存在せしめるものであります。 IVD の目的は、 IVS を固有のグリフ的部分集合に関連付けることです。 IVS がテキストに現れたなら、 IVD をチェックすればその意図する所を特定できます。 ゆえに登録済IVS は、テキスト交換に使うのに適したものです。 >>19
[126] 未登録済IVSは、テキスト交換で使うべきではありません。 >>19
[145] IVD は、 Unicode Consortium の Webサイトで公表されています >>21。
[147] UCD とは別のデータベースになっていて、 The Unicode Standard とは同期せずに、 必要があるときに更新されているようです。 過去に公開された版はそのままで、 新しい版を公開されていく形になっています。 各版で完結しているので、 歴史的経緯を気にしないのであれば常に最新版だけを見ていれば済みます。
[236] IVD の版は日付で命名されています。 >>21
[239] 一度出版された版は変更されないこととされています。 >>21 しかし実際のものを見るとなぜか日付よりずっと新しいタイムスタンプのものが紛れ込んでいます。
2007-12-14
https://www.unicode.org/ivd/data/2007-12-14/Adobe-Japan1
が追加されました。2010-11-14
https://www.unicode.org/ivd/data/2010-11-14/Hanyo-Denshi
が追加されました。2012-03-02
https://www.unicode.org/ivd/data/2012-03-02/Adobe-Japan1
に追加がありました。Hanyo-Denshi
に追加がありました。2014-05-16
https://www.unicode.org/ivd/data/2014-05-16/Moji_Joho
が追加されました。Moji_Joho
の追加によるものとみられます。 PDF
ファイル内に書かれた日付はいずれも 「May 16, 2014」。Hanyo-Denshi
と
Moji_Joho
の IVS の共有の情報が追加されました。2016-08-15
https://www.unicode.org/ivd/data/2016-08-15/MSARG
が追加されました。2017-12-12
https://www.unicode.org/ivd/data/2017-12-12/Adobe-Japan1
に追加されました。Moji_Joho
に追加されました。KRName
が追加されました。IVD_Stats.txt
に重複情報が6件追加。2020-11-06
https://www.unicode.org/ivd/data/2020-11-06/MSARG
に追加されました。IVD_Stats.txt
だけ付。
変更されたものかどうかは
Internet Archive からは不明。2022-09-13
Adobe-Japan1
に1つ追加されました。IVD_Stats.txt
に重複情報が1件追加。[149]
IVD のファイル
IVD_Collections.txt
,
IVD_Sequences.txt
は、
IVC
と
IVS
の情報を含んだテキストファイルです。
その構造は UTS #37 で説明されています >>19 が、
UCD 同様の ;
区切りの行指向データファイルです。
[150]
IVD_Collections.txt
には、
Ideographic Variation Collection
の情報が記述されています。
IVC を表す識別子、
IVC 内の識別子の正規表現、
IVC の説明の Webサイトの URL が書かれています。
>>19
[152]
IVD_Sequences.txt
には、
IVS
の情報が記述されています。
IVS の各文字の符号点、
IVC を表す識別子、
IVC 内の識別子の組が並べられています。
>>19
[231] 他に代表グリフの一覧表の PDF ファイルがあります。 古い版では IVC 横断の一覧表だったようですが、 新しい版では IVC ごとの一覧表になっているようです (ファイルサイズが大きすぎるからでしょうか)。 改版のたびに変更のない IVC の PDF まで改訂されているようです (少なくても日付が書き換わっています)。 (意図しない代表グリフ変更が生じていないか、不安になりますね。)
[140] IVD では、 IVS (とそれに関連付けられたグリフ的部分集合) は、 集成 (Ideographic Variation Sequence Collection, Ideographic Variation Collection, IVC) のエントリーという形にグループ化されます。 >>19
[212] IVC は0個以上の IVS と付加情報という形を採ります。 IVD は IVC の和集合という形になります。 IVS は複数の IVC に属することがあります。
[211] IVC は特定の利用者コミュニティーの要件を満たすグリフ的部分集合を集めたものとなることが期待されます。 しかし IVC の登録は、 特定目的への適当性を暗示するものではありません。 IVS の有用性や IVC 全体としての有用性は、 その用途に依存します。 登録者は IVC の意図を説明するべきで、 利用者は IVC が自身の目的に有用かどうか評価するべきです。 >>19
[233] IVC は固定の集合ではありません。後から IVS を追加していくことができます。 IVC に既に含んでいる IVS の変更や削除の手続きはなく、認められていないものと思われます。
[143] 実装は、 登録済IVS を任意の組み合わせで自由に対応でき、 複数の IVC であろうとも IVC の部分集合であろうとも構いません。 >>19 つまり IVC は一応意味のある単位として想定されてはいるものの、 実装に対する要件を課すものとはなっていません。
[141] 同じグリフ的部分集合の IVS がいくつもあると実装コストが嵩み、 当該 IVC が実装される可能性は下がります。 そこで同じグリフ的部分集合の IVS を減らすため、 既存の IVC の IVS と似たものを共有することが強く推奨されます (が必須ではありません)。 IVS の共有は、 関係する IVC の登録者間相互の合意があれば実施できます。 登録官は、 IVS の共有の可能性を登録者に警告しなければなりません。 >>19
[142] なお CJK互換漢字 の SVS (>>56) は IVC ではありません。
[213] IVC は、 識別子 (集成識別子) を持ちます。 特に言及はありませんが、 今の所他の IVC と重複しないものが割り当てられているようです。
[214] IVC 中の IVS は、 識別子 (列識別子) を持ちます。 列識別子は IVC 内で固有の識別子です。 同じ IVS が別の IVC で共有される場合、 IVC ごとに違う識別子になることがあります。
[153]
集成識別子と列識別子は、
ASCII英字から始まり、
ASCII英数字、
_
,
-
,
+
のいずれかが続くような文字列です。
>>19
[154]
このうち -
, +
は既存の登録との後方互換性のために認められるものです。
_
に置き換えるか、または除去することで、
固有の識別子を生成できるとされます。
>>19
ということは今後は追加されない想定なのでしょうか。
(既存の IVC への追加の IVS に使われることはあるかもしれません。)
[151] IVC ごとに列識別子の正規表現が定められます。 当該 IVC のすべての IVS の列識別子は、 この正規表現に一致しなければなりません。 これは Perl 5.8 正規表現です。 IVC 登録者が定めるもので、必要となれば拡張のために変更できます。 >>19
[226] 一旦 IVD に登録された IVC の集成識別子や IVS の列識別子を変更する手続きは用意されていません。 変更は認められないものと思われますが、明記はされていません。
[345] 日本関係が3件、 大韓民国関係が1件、 中華人民共和国澳門特別行政区関係が1件、 Adobe 関係が2件 (重複あり) です。
[395] 未登録のまま長年放置されているものがいくつか見つかっています。 再開の見込みがあるのかどうかも不明。
[401] BabelStone フォントは IVD 登録済みの IVS とそうでない IVS を実装しています。 未登録のものは将来登録するつもりであるものの、 変更の可能性もあると説明されています。 >>400 ウェブページ上の日付から2年既に経過していますが、今のところ登録はされていません。 すぐに登録しようというスケジュール感ではなさそうです。 未登録 IVS がどの程度利用されているのかは不明です。
[402]
Nôm Na Tống フォントは IVD にない IVS
を多数実装しています。
旧版は IVD の IVS を避けていましたが、現行版は IVD の IVS
と非互換に衝突しています。
[429]
常用標準漢喃表と漢喃復活委員会フォントは IVD にない IVS
を多数実装しています。
IVD の IVS と非互換に衝突しています。
Nôm Na Tống
の
IVS とも違っています。
[419]
注音IVS字型規格 (Bopomofo IVS Font Specification)
は
U+E01E0
からの VS
を中文漢字音の区別に使っています。
>>420
[421]
PanCJKV IVD Collection
は U+E01E5
から U+E01EF
を使っています。
注音IVS字型規格とぎりぎり衝突を回避できているのか、いないのか?
[399] Unicode非互換割当も参照。
[422] 中華民国でも IVS 利用を検討しているらしいですが、具体的な話にはなっていない模様です。
[458] >>422 少しずつ進んではいるようです >>457。でも先は長そうな雰囲気。
[426] BabelStone Khitan Small Linear は契丹小字 + VS を使っています。 >>425
[14] Wayback Machine, https://web.archive.org/web/20150104014658/http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg36/IRGN1757_ProposedIVDRegistration.pdf
(UTCソース)
[449] ChiuKongGothic/Other/IVD_Ext.csv at main · ChiuMing-Neko/ChiuKongGothic · GitHub, https://github.com/ChiuMing-Neko/ChiuKongGothic/blob/main/Other/IVD_Ext.csv
[450] >>449 U+E01EA
, U+E01EB
に独自に割り当てています。
[451]
IPA明朝は U+E0100
を (IVD に存在しない IVS も含めて)
多くの符号位置で機械的に定義しているようです。
[452]
平成時代中期以後の日本市場の多くの汎用フォントは JIS X 0213:2004 対応と称して、
JIS X 0213:2000 から JIS X 0213:2004 への改正で字形が変更された面区点位置の一部に相当する
(それぞれの jp90
字形と jp04
字形の一方または両方の)
AJ1 IVS を実装しています。
[172] IVD の登録機関は、 Unicode Consortium です。 >>19
[173] 登録機関は、 登録要求を処理する登録官 (IVD Registrar) を任命します。 >>19 その資格や任期、待遇、人数などは UTS #37 には記載されていません。 Unicode Consortium の裁量で決められているようです。
[174] 登録機関自身が登録者となる IVC であっても特殊な地位は持ちません。 登録機関が提出した IVC も他の提出案と同じ登録手続きを経ます。 >>19
[163] 登録機関は、 IVC や IVS の登録に於いて、 返金不能な手数料を課すことができます。 >>19
[165] 登録機関が提出したまたはスポンサーとなった IVC については、手数料は免除されます。 >>19
[164] 登録官は、 登録の出願が不完全なとき、 登録者にこれを通知し、 訂正出願を1回無償で受理します。 それ以後の訂正出願は有償となります。 >>19
[219] 具体的な価格は UTS #37 には書かれていません。
[220] ISO/IEC 10646 の制定作業に関与する national body は登録料が免除されているらしいです。 (SC2 に対し免除を表明する Unicode Consortium の書簡 >>356。)
Moji_Joho
の登録時には、
文字情報基盤整備事業
(独立行政法人の IPA が受託した日本政府の事業)
が登録料支払いを迂回するため
JSC2
(SC2 に日本の代表として参加している情報処理学会の下部組織)
の協力を仰いだらしいです。[222] 登録料を徴収している理由は不明ですが、 Unicode 関係者や各国政府関係を除いた一般の団体や民間人が安易に登録して IVS が氾濫するのを防ぐ狙いがあるのでしょうか。
[207] IVS は、 UTS #37 の登録手続きにより、 IVD に登録されます >>30。 登録者は、 登録機関に登録要求を提出します >>19。 登録手続きは登録者と登録官によって進行されます。
[175] 登録手続きは、 IVC の登録と IVS の登録の2つがあります。 まず IVC を登録し、 次にその IVC に個々の IVS (に関連付けるグリフ的部分集合) を登録していきます >>19。 ただし IVC と IVS の登録手続きは並行して開始できる >>19 とされていますから、 初期登録は同時に行われているようです。
[224] IVC と IVS の登録手続きは、 次の手順を踏みます。
[166] 登録者は、 IVC の評価期間終了後の登録時に、 次の登録事項を提出します。 >>19
[179] 登録者は、 IVC の評価期間終了後の登録時に、 次の事項を署名付きで声明します。 >>19
[184] IVC の所有者は、 登録官への通知により、 代表者と Webサイトの URL をいつでも変更できます。 IVS の列識別子の正規表現を拡張できます。 >>19
[185] IVC の所有権は、 登録官への通知により、 移転できます。 >>19
[187] IVS の登録者は、 出願に当たり IVS の列識別子が IVC 中 (既に登録済みのものも含む。) の各基底文字に対して固有であることと、 IVC の列識別子の正規表現に一致すること、 を確かめる責任を持ちます。 この要件を満たさない出願は、拒絶されます。 >>19
[188] 理想的には、 IVS の登録者ははじめの出願の段階で、 提案する IVS の代表グリフを含めるべきです。 IVS の登録者は、 評価期間終了後の登録時に、 各 IVS に1つ以上の代表グリフを含めなければなりません。 >>19
[192] IVS の登録者は、 登録手続きとは別に、 既存の IVC の登録済の IVS に追加の代表グリフを提供できます。 >>19
[183] 登録官は、 IVC の出願を受理したら、 IVC に集成識別子を (できるだけ提案を尊重して) 割当します。 >>19
[193] 登録官は、 IVS の出願を受理したら、 IVS に異体選択子を割当します。 >>19
[230] 登録官は出願を受理したら IVD に追加するとされていますが、 具体的には関係するテキストファイルを編集して情報を追加し、 代表グリフ一覧の PDF を作成しているようです。
[337] これまで実施された評価は Unicode Consortium の Webサイトで公表されています。
[439] 20140808-12.pdf, https://warp.ndl.go.jp/info:ndljp/pid/10965918/mojikiban.ipa.go.jp/contents/2014/08/20140808-12.pdf#page=4
Moji_Joho コレクションの登録後に、公開レビュー期間を、2000 図形あた
り 30 日追加するとの方針が Unicode コンソーシアムから示された。その結 果残り約 48,000 のシーケンス登録には、2 年を超える公開レビューの期間が 必要となる可能性がある。
[423] IRG では他の漢字と統合可能なときに「ではそれは IVS で」 という処理になってるぽいですが、 それで新規追加が却下された結果 IVS が登録された事例はあまりなさそうに見えます。 符号位置の新規追加プロセスと IVS の新規登録プロセスがまったく繋がっていません。
[468] 唯一例外として、文字情報基盤事業ではUCSへの追加ができなかったものを後から IVSとして登録することで、ほぼ全MJ文字図形が何らかの形で Unicode 化されました。 Unicode とは別に文字図形の一覧を画定させた上での、 初めから符号位置追加と IVS 追加がセットで企画されていたプロジェクトだからこのフローが実現したのでしょう。
[469] それ以外は、 IRG に参加する各国代表機関にとっては 「CJK統合漢字に不足を追加する」ことが目的 (管掌業務) になっていて、 「既存の Unicode で表現できなものを表現できるようにする」 ことを目的としていないので、CJK統合漢字に新規追加できなくても既存の符号位置に統合可能なら目的を達成できたという判断なのでしょうかね。
[424] 符号位置の追加では NB 以外からの要望でも Unicode Consortium が出典U に取り込んで新規追加してくれますが、 IVC はそのような運用がありません。 そういうのがあれば、 NB がやる気がなくても誰かやる気がある人が必要なものをどんどん申請してくれそうなものですけどねえ。
[176] IVC の登録者は、 IVC の意図、 原則、 その他利用者に有用なデータを説明する Webページを作成します。 >>19
[186]
IVS
の登録者は、
IVC
を説明する
Webページ
(から指定されたWebページ)
に、
提案する IVS
を提示します。
IVD_Sequences.txt
形式のファイルとしますが、
IVS 符号点の欄には基底文字だけを示します。
>>19
[144] 登録手続きは登録者が Webサイトで説明を提供することを要求しています。 そして登録後も可能な限り公衆アクセスを提供し続けることが強く推奨されています。 しかしそれは保証されません。 利用者は、 説明への公衆アクセスの継続性が自身の目的に必要かどうか、 登録者がそれを提供できるかを、 注意深く評価するべきです。 >>19
[247] IVC の Webサイトの状況をまとめると次の通り。
Adobe-Japan1
2017-12-12
版で登録されている URL:Hanyo-Denshi
2020-11-06
版で登録されている URL:
The Hanyo-Denshi IVD Collection, , https://www.unicode.org/ivd/hanyo-denshi/Moji_Joho
2017-12-12
版で登録されている URL:
http://mojikiban.ipa.go.jp/mjc/https:
)moji.or.jp
2022-09-13
で登録されている URL:
https://moji.or.jp/mojikiban/MSARG
2020-11-06
版で登録されている URL:
https://www.safp.gov.mo/mscs/ivs/KRName
[333]
Hanyo-Denshi
は登録した汎用電子情報交換環境整備プログラムが終了して
Webサイトも消滅してしまったようです。
救済措置なのか
Unicode Consortium
の
Webサイトに紹介ページが作られました。
[406] どのような手続きでこの変更が行われたのかは謎です。
[334] これらの Webサイトの情報は、登録に必要な事項はいったん登録されてしまえば IVD から入手可能になるので、 実装には不要で無くなっても困らないことは事実です。
[335] 本来なら代表グリフ以外にも実装や利用に必要なはずの詳細な情報とか、 自由に利用できる参照フォントとかが提供されていてしかるべき感はありますが。 登録手続きで要求されて仕方なく作っただけにしか見えないサイトがいくつかあります。
[336] そういう情報が提供されないなら、開発過程の履歴を残すという歴史的意義しか残らないのですが、 (GitHub を使っているサイトはともかく) どこも登録手続き中の改訂でどんどん上書きして前の版を残していないようなので、 それすら満足がいくとはいえない状況です。
[415]
Moji_Joho
の文字情報基盤は日本政府傘下の IPA から民間団体に令和2年に移管されました。
2022-09-13
版で登録 URL が新しいものに変更されています。
[416] しかしなぜか変更履歴にはそのことが書かれていません。 また、新しい URL はただの文字情報基盤のトップページで、 元々の IVC 登録用の情報は見当たらなくなっています。 どのような手続きによって変更されたのかは謎です。
[407]
KRName
も令和5年4月に GitHub から Unicode に移転しました。
これは Adobe から Unicode Consortium への登録者の移管と同時に行われたものです。
[414]
KRName
は移転後 IVC が更新されておらず、現時点で最新の
2022-09-13
は当然古い URL のままです。しかし IVD ウェブサイトのリンク集
(KRName
移転とほぼ同時に新設) は新しい
URL に更新されています。
[418] これらもどのような手続きによるものか謎です。
[128]
異体選択子は default ignorable
なので、
IVS に関連付けられたグリフ的部分集合は、
基底文字を単体で使った時に適切なグリフ群の部分集合である、
言い換えると IVS のグリフ部分集合が基底文字に統合可能なものである必要があり、
登録者はそれを確かめることが期待されます。
Unified_Ideograph
の文字の場合については、
The Unicode Standard の漢字の章と
ISO/IEC 10646 附属書 S の漢字統合規則に照らし合わせることが、
その方法の1つです。
>>19
[131]
encoded variants の数を削減するための取り組みとして、
Unified_Ideograph
な文字に関する統合規則は、
IVD に適用される時、
次の2つの場合も含めるよう拡大されます。
>>19
[470] 実際の登録字形を見ると、本当にこの字形は基底文字と統合可能なのだろうか、 どの UCV によりそう判断できるのだろうか、と疑問を呈さずにはいられない異体列が数多あります。
[209] ある基底文字の異体列として登録された IVS の代表グリフが、 実は別の基底文字の代表グリフに一致する (かそちらの方がより近い) ことが後から判明する、という事例がままあるようです。
[350] 草書体フォントや篆書体フォントの字形を使った登録を試みたらどうなるのか、 おもしろそうだからどこかがやってみてくれないものかw
[476] >>475 統合分離に伴い従来IVSで使われていた字形と同形の新しい符号位置が追加される事例。 IVSと矛盾した追加であることを認識し、引き続きIVSを使うことが容認された上での分離。
[441] IVS についてのデータはいろいろなところにあります。
Adobe-Japan1
IVS の情報は
Adobe-Japan1 GitHub リポジトリーにあります。Hanyo-Denshi
IVS の情報は
漢字データベースプロジェクト
にいくらかあります。Moji_Joho
IVS の情報は文字情報基盤にあります。
関係するCJK互換漢字SVSの情報もあります。[63] ほとんどの SVS の代表グリフは、 符号表に示されています。 >>30
[69]
SVS
は、
符号表の文字一覧の元の文字の項に、
swung dash (~
)
で示されています。
>>68
[70] SVS は、 符号表の元の文字のブロックの後に代表グリフの一覧が付されています。 ただし CJK互換漢字用の SVS は、 CJK統合漢字でなく CJK互換漢字の側に示されています。 >>68
[71]
Unicode 8.0
の時代まで、
CJK互換漢字用を除く
SVS
(後の EVS を含みます。)
の字形は
UCD
の
StandardizedVariants.html
に収録されていました。
蒙古文字のものも含まれ、
語頭形など複数の字形例が示されたものもありました。
>>22
[72] Unicode 9.0 でこのファイルの内容は削除され >>23, >>18、 Unicode 10.0 でファイル自体も削除されました。
[64] EVS の代表グリフは、 絵文字表に示されています。 >>30
[65] IVS の代表グリフは、 IVD に示された登録中にあります。 >>30
[430] 異体列が表すグリフ部分集合を代表するのが代表グリフですが、 グリフ部分集合とは基底文字が表し得るグリフ全体の集合の部分集合です。 つまり代表グリフは基底文字をある意味代表する字形の1つともいえます。
[431] 基底文字の代表字形は、大部分のUnicode文字には1つ、 CJK統合漢字やCJK互換漢字には1つ以上が符号表で示されています。 それら代表字形が異体列の代表グリフに選ばれている (ような異体列が規定または登録されている) こともあれば、そうでないこともあります。
[434] なお、フォントにおいて異体列に割り当てられたグリフに対して、 基底文字のみの列に対して割り当てられたグリフのことを、 文字情報基盤ではデフォルトグリフと呼んでいます >>433。
[435] フォントのデフォルトグリフ = 既定グリフは、 同じフォントで異体列に割り当てられたいずれかのグリフと一致することもあれば、 どれとも一致しないこともあります。
[437]
OpenType の場合、
異体列のグリフがデフォルトグリフと一致するような異体列のことを
default UVS
(既定UVS)
といい、
そうでない異体列のことを
non-default UVS
(非既定UVS)
といいます。
両者には別のデータ構造が用意されています。
>>436
[41] 異体列において異体選択子は基底文字または spacing mark の見た目に影響します。 >>30
[42] この見た目の変化は、 後に続く文字、 とりわけ同じ基底文字または spacing mark に適用される結合文字にも視覚的な影響を与えることがあります。 >>30
[43] 基底文字の図形の変化に合わせて、 結合マークの図形や位置も変化するべきです。 基底文字の色の変化に合わせて、 結合マークの色も変化するべきです。 基底文字の advance width が変化すれば、 次の spacing文字の位置も変化します。 >>30
[384] 異体列に対応したフォントが存在しない時、 基底文字だけの場合と同じグリフを表示し、 異体選択子相当の表示はしない実装が普通です。
[385] この実装方法のメリットは、 受信者が対応した異体列かどうかを個別に送信者が判断せずとも、 そこそこの表示が得られる点です。
[386] この実装方法のデメリットは、 送信者の意図しない表示になっていても受信者が気づかない可能性が高いことです。
[46] 異体列は、 定義されたものを除き、 表示上の効果を持ちません。 異体選択子によって視覚的な見た目は変化しません。 >>30 適合する処理は、 未定義のものを SVS として解釈してはなりません >>105。
[108] SVS を構成しない自由異体選択子は無視されるべきです。 >>105
[52]
異体選択子は、
結合マークであり結合クラス ccc
= 0 で、
default ignorable
です。
従って異体列に対応していない場合には、
異体選択子は不可視で無視されるべきです。
>>30
異体選択子は視覚的な見た目を持ちません
>>105。
[53] 異体選択子が可視的な見た目を与えられるモードや環境があっても構いません。 例えば「隠れたものを表示する」モードで特別なグリフで表示しても構いませんし、 基底文字に下波線を引いて現在のフォントでは対応できないことを示したりできます。 >>30
[467] 利用者:emk - GlyphWiki, https://glyphwiki.org/wiki/User:emk#i2
Windows 7でIVSを認識させるには、以下の条件をすべて満たす必要があるようです。
cmap
[375]
OpenType フォントは cmap
の format
= 14
を使って異体列とグリフの対応関係を記述しています。
[367]
TTF / OTF の異体列用 cmap
format 14
に対応していないソフトウェアが意外とあります。
[368]
opentype.js
は API がなく存在自体が無視されます。
GSUB
[360] 文字の表示上の処理の多くは、 書記素クラスターを単位にします。 異体選択子は結合文字ですから、 異体列は書記素クラスター (の一部分) になります。 多くの処理では異体列はその基底文字単体と同じように振る舞います。
[361]
例えば縦書き字形に関する
Vertical_Orientation
は、
多くの場合に書記素クラスターの先頭文字の
Vertical_Orientation
となります。
つまり異体列が横書きと縦書きで字形回転するかどうかは、
異体選択子に関わらずに決まります。
[45] 異体選択子は、 文字符号化の一般の拡張機構を想定したものではありません。 基底文字や spacing mark と異体選択子の組み合わせは、 Unicode Consortium が定義するリストにあるものを除き、 表示上の効果を持ちません。 >>30 定義されていないものは、 将来の標準化のために予約されています >>105。
[54] 特定の異体列の標準化や対応は、 基底文字単独での表現に使うことが出来るグリフの集合を制限することにはなりません。 利用者がある文字とその特定の異体の視覚的な区別を必要としているなら、 その区別のためにはフォントを使わなければなりません。 >>30
[55] 異体列が存在するからといって、 異なる意味で同じまたは重なるグリフの範囲の新しい文字が将来符号化されることを否定するものではありません。 >>30
[206] 異体列は、 誤りとして廃止された事例が2件知られています (>>82)。 今後も廃止される可能性があるのかは不明です。
[136] 登録済 IVS を使ったテキストの安定性を保証するため、 IVS とグリフ的部分集合の関連付けは恒久的なものとされます。 IVS が他のグリフ的部分集合に再割当されることはありません。 >>19 恒久的ということは、変更も削除もされることはないと解釈できそうです。
[228] IVS には後から追加の代表グリフを追加することが認められています。 その条件は特に規定されていません。 ということはある時点の代表グリフ群から推測されるその異体列の解釈の幅と、 それより後の時点の代表グリフ群から推測されるその異体列の解釈の幅が変わっていることもあり得るわけです。 (削除が認められるとは書かれていないので、幅が狭まることはないとは思われます。)
[229] SVS、 EVS の代表グリフが変更されることもありそうですが不明です。 過去あったのかも不明です。 (符号点の代表グリフはたまに変更されています。)
<ivs>
(朝刊太郎)[25]
DTP
ソフトウェア
朝刊太郎・改(<ivs>
タグという機能で
IVS
を文字列表現しています。
[118] 「朝刊太郎・改(仮称)」タグの使い方, , https://www.chokantaro.com/tag/tag.html#Ivs
辻と<ivs>辻、祇園と<ivs>祇園 兵庫の芦屋市と広島の<ivs>芦田川
辻と<ivs=2>辻、祇園と<ivs=2>祇園 兵庫の芦屋市と広島の<ivs=2>芦田川
異体字の枝番号を省略すると「0」番と判断されます。(実際の枝番号定義から逆算しやすいよう番号はゼロから指定します)
[112] Unicode の異体列は標準化の対象とされ、 私用の仕組みは用意されていません。
[195] 私用文字に異体選択子を併用することも認められていません。
[113] それとは別に、 私用文字に独自に異体選択子的な機能を割り当てている応用もあります。
[114]
Apple
は
U+F870
「transcoding hint: variant tag 16」 -
U+F87F
「transcoding hint: variant tag 1」
を定義しています。
>>15
[116] Apple が Unicode 以前に使っていた各国用の文字コードにあって Unicode にない文字で、 他の Unicode文字の異体とみなされるもののために、 Unicode文字の後に置いて使われています。
[117] 例えば MacJapanese の縦書き字形に使われています。
[427]
Wenlin は PUA に独自の異体字選択子を規定して使っています。
[371] BabelStone は標準の IVS の続きの未割当の異体選択子を使っています。 >>357 独自分は追加提案する意思があると書いていますし、 変更の可能性もあるとは書かれています。 (怖くて実用できないですね...)
[474] Proposal to Encode a Set of 128 User-Defined Variation Selectors - 24148-n5266-uvs_proposal.pdf, , https://www.unicode.org/L2/L2024/24148-n5266-uvs_proposal.pdf
[347] 既存の Unicode文字の細かい差は表現できますが、 似た別字やまったくの新字は表現できません。
[348] Unicode Consortium が標準化または登録したものしか使えません。
[471] 異体選択子 (特に意味が未割当のもの) は、
不可視の文字として悪用されることがあります。
[29] 異体選択子とは別に、 本来算用数字を表す符号位置の表示形をアラビア文字の数字に切り替える、 numeric shape selector format characters があります。
[161] L2/08-109, https://www.unicode.org/L2/L2008/08109-ivd-update.html
[20] プレスリリース「ISO/IEC 10646の規定に基づく漢字字形データベースへの登録」 | IPSJ/ITSCJ (一般社団法人 情報処理学会 情報規格調査会 著, 版) https://www.itscj.ipsj.or.jp/oshirase/2014/06/pr_140610_sc2.html
[1] ホーム ( 版) http://ivstpc.jp/default.aspx
[6] >>1 404 Not Found () http://ivstpc.jp/ いつの間にか消滅
[2] 人名などの異体字もデータ交換可能に、MSなどが「IVS技術促進協議会」発足 -INTERNET Watch ( 版) http://internet.watch.impress.co.jp/docs/news/20101206_412176.html
[3] 『Unicode IVS Add-in for Microsoft Office』を提供 ( ( 版)) http://www.microsoft.com/japan/presspass/detail.aspx?newsid=4219
[459] Microsoft Word - wg2n4572_gvs-proposal_20140401a.doc - n4572.pdf, , https://www.unicode.org/wg2/docs/n4572.pdf
[460]
>>459 (4月1日)。〓
の字形を区別する Geta VS
(GVS) を提案していた。
[461] SVS として普通に有用そうだし実例が示されているように横書き字形と縦書き字形の区別は本来あるべきなのに、 なぜかスルーされてるのが謎。
[463] >>462 は (4月1日)。こちらは VS とは正反対で、 本来の CJK統合漢字なら統合対象にならない粒度まで統合する新しい概念の提案。 問題設定は真面目だし、実際解決の必要性がありそうな課題を選んでいるのに、 解決案は雑で、おそらく4月1日ならではの文書だと思われるが、 いまいちその点が伝わりにくいというか、どこにユーモアがあるのかよくわからないんだよな...
[464] というかもうはっきりいってしまうと、ギャグとして滑ってるんじゃないの、って。 (ギャグなんだとしたらね。たまたま4月1日の提案になっただけで大真面目だったら申し訳ない。 ← この突っ込んでいいのか悪いのかよくわからない感じが滑ってるんよ)
[465] これがギャグだろうとなんだろうと、ここで紹介された統合対象になってない文字が、 なぜ現在まで CJK統合漢字に新規追加されず、 VS も登録されないまま放置されてるのか、がやっぱり謎。
[466] どっちの4月1日も、解決するべき問題を示すだけ示して、非現実的な解法を提示するだけで放置して逃げてるのがダサいというか困ったところ。
[4] Issue 383580 - chromium - UVS (SV or IVS) is not supported even with a UVS-capable font - An open-source project to help move the web forward. - Google Project Hosting ( 版) https://code.google.com/p/chromium/issues/detail?id=383580
[5] 新異体字セレクター作成計画 ‐ 未来情報産業 ( (未来情報産業株式会社 著, 版)) http://www.mirai-ii.co.jp/data/ivs/
[9] 異体字セレクター ‐ 通信用語の基礎知識 () http://www.wdic.org/w/WDIC/%E7%95%B0%E4%BD%93%E5%AD%97%E3%82%BB%E3%83%AC%E3%82%AF%E3%82%BF%E3%83%BC
[10] 異体字について | 文字情報基盤整備事業 () http://mojikiban.ipa.go.jp/2527.html
[12] AbemaPrime【公式】さんのツイート: "【今夜 #アベプラ】①沖縄県東村高江で米軍大型ヘリが着陸し炎上②プレイバック総選挙!05年「郵政解散」を小泉元総理に罷免された島村元農水大臣に聞く︎③元郵便局員が語る郵政民営化の実情@8bit_HORIJUN @shigekixs▷https://t.co/NdXJ5e0onb https://t.co/F5S046u1CO" () https://twitter.com/Abema_Prime/status/918056947902922752
現在、文字コード技術部会では、このIVSを含む文字列のコレーションを可能にする技術的な方法について調査と検討を進めています。最終的には何らかの実現可能な方法を提案し、課題の解決につなげたいと考えています。
[235] 桐ヘルプ - IVS, 管理工学研究所, https://www.kthree.co.jp/kihelp/index.html?page=data/ivs&type=html
[346] プレスリリース:超漢字検索IVS強化版 | 超漢字検索ウェブサイト, パーソナルメディア株式会社, , http://www.chokanji.com/ckk/press_ckkivs.html
[352] , https://standards.iso.org/iso-iec/10646/ed-6/en/UCSVariants.txt
[353] , https://standards.iso.org/iso-iec/10646/ed-6/en/EmojiSrc.txt
[355] 異体字セレクタを含む漢字が縦書きのウェブページでうまく表示されないときの対策|Colorless Green Webs () https://we.fnshr.info/2016/02/14/variation-selector/
[364] 392588 - Proper font fallback for variant selectors, https://bugzilla.mozilla.org/show_bug.cgi?id=392588
[365] IPSJ-DC16102006.pdf, https://ipsj.ixsq.nii.ac.jp/ej/index.php?action=pages_view_main&active_action=repository_action_common_download&item_id=168214&item_no=1&attribute_id=1&file_no=1&page_id=13&block_id=8
[366] [css-text] [css-fonts] Variation selectors are underspecified · Issue #854 · w3c/csswg-drafts · GitHub, https://github.com/w3c/csswg-drafts/issues/854
[372] IVSとフォントの関係 - ちくちく日記, https://chiku-chiku-nikki.hatenablog.com/entry/20110930/1317339375
IVS技術促進協議会セミナー「UnicodeとIVSの基礎について」
使える文字が増えるということが、本当に便利なのかどうかをよく考えてほしい。 ある人のわがままで増えた文字が誤字であってもそれを削除する権限が行政にない。それがたまりたまってこれだけの数になって、全部そのまま符号化されている。
[373] 現に存在する文字を「わがまま」だという。こういう考え方の人がなぜか IVS を仕切っている。
[374] こういう言い方をするからには相応の根拠があるのだろうな? 「わかがま」の「誤字」が「これだけの数」あると断定するからには、 相当数の文字の来歴を調査していつどんな経緯で生まれたのか判明しているはず、 その調査報告はどこにあるの?
[397] Proposal to add standardized variation sequences for digits and various punctuation (L2/18-013) - 18013-svs-proposal.pdf, , https://www.unicode.org/L2/L2018/18013-svs-proposal.pdf
[448] L2/23-212 (Proposal to add standardized variation sequences for four quotation marks) - 23212r-quotes-svs-proposal.pdf, , https://www.unicode.org/L2/L2023/23212r-quotes-svs-proposal.pdf
[403] IVD Registrar—異体字王さんはTwitterを使っています: 「The IVD (Ideographic Variation Database) landing page now includes a new “Registered IVD collections” section that includes useful details about the registered IVD collections. https://t.co/CfXnj9qlcA」 / Twitter, , https://twitter.com/IVD_Registrar/status/1650308296124022786
[477] A Letter in Support of N5266 - 24199-support-n5266.pdf, , https://www.unicode.org/L2/L2024/24199-support-n5266.pdf
[478] Recommendations to UTC #180 on Script Proposals - 24166-script-wg-rept.pdf, , https://www.unicode.org/L2/L2024/24166-script-wg-rept.pdf#page=24