符号位置とグリフの分離
同じUnicodeの符号位置でも、表示される字形はフォントが持つグリフ次第で変わるという性質。
異体字セレクタ(IVS)
漢字の直後にU+E0100以降の不可視の符号位置を置いて、字形の変種をデータとして指定する仕組み。
JIS2004の例示字形変更
JIS X 0213:2004で168字の漢字の例示字形が印刷標準字体に改められた変更。符号位置は変わらず字形だけが変わる。
OpenType jp90フィーチャ
OpenType Layoutのフィーチャタグのひとつで、JIS X 0208:1990ベースの字形(JIS90字形)への切り替えを提供する。
IVD(Ideographic Variation Database)
どの基底文字+セレクタの並びがどの字形を指すかを定めるUnicodeコンソーシアムの登録簿。Adobe-Japan1・Hanyo-Denshi・Moji_Johoなどのコレクションが登録されている。
OpenTypeのcmap format 14
フォントがUnicode Variation Sequenceと字形の対応を実装するためのcmapサブテーブル。
書記素単位での文字数計算
利用者が1文字と認識する並びを、UTF-16のコード単位ではなく書記素として数え、切り出すこと。
外字(EUDC)と私用領域(PUA)
Unicodeの私用領域のコードポイントに利用者や団体が独自の字形を割り当てる仕組み。同じコードでもPCごと・組織ごとに別の字になり得る。
外字
文字情報基盤(MJ)と戸籍統一文字
行政事務で用いる約六万字の漢字を対象とする文字情報基盤と、戸籍で用いられる文字を検索できる戸籍統一文字情報。
PDF/A(ISO 19005)
文書の表示に必要な要素をファイル内に含めることを求める長期保存用のPDF規格。フォントの埋め込みが必須になる。
フォントのfsType(埋め込みライセンス)
OpenTypeフォントが埋め込み権限(Installable / Restricted License / Preview & Print / Editable、サブセット禁止など)を宣言するOS/2テーブルのフィールド。
フォントリンクとフォールバック
指定したフォントにグリフがない文字を別のフォントで代替描画する仕組み。GDIではFontLink\SystemLink、DirectWriteやWPF・ブラウザーではフォントフォールバックが担う。
互換分解のUnicode正規化(NFKC/NFKD)
互換等価まで統合するUnicode正規化。全角半角や組文字などの表記上の区別を潰すため、区別の保持が要件のデータには適さない。
BIZ UDゴシック
Windows 10 バージョン1809以降に日本語補助フォントとして含まれる、モリサワ製のユニバーサルデザイン書体。
画面と帳票のフォント統一
画面表示と印刷・帳票出力で同じ書体を明示指定し、見た目や改行位置を一致させること。
表外漢字字体表を受けてJIS X 0213:2004で168字の漢字の例示字形が印刷標準字体に改められた。符号位置は変わらないため、同じデータでも環境によって字形が違って見える。
MSゴシックファミリーの既定字形はJIS2004ベースで、OpenTypeの'jp90'フィーチャを適用するとJIS90のレガシー字形を選べる。IVSの字形指定を担うcmap format 14とは別の仕組み。
基底文字の直後にU+E0100〜U+E01EF(VS17〜VS256)のセレクタを置くことで、字形の変種をデータとして指定できる。同じ「葛」でもどちらの字形かを区別できるようになる。
どの基底文字+セレクタの並びがどの字形を指すかは、UTS #37にもとづくIVDという登録簿で決まる。Adobe-Japan1(2007年)・Hanyo-Denshi(2010年)・Moji_Joho(2014年)などのコレクションが登録されている。
フォント側はcmapサブテーブルformat 14でUnicode Variation Sequenceを実装する。対応フォントと対応アプリが揃わなければ、セレクタは無視され基底文字の既定字形で表示される。
セレクタは追加面の符号位置なのでUTF-16では常にサロゲートペアになり、基底文字も追加面なら1文字が最大4コード単位になる。文字数の検証・切り出しはコード単位ではなく書記素単位で行い、DBのカラム長も見かけの文字数の2〜4倍を見込む。
私用領域のコードポイントには全世界共通の意味がなく、同じコードでもPCごと・組織ごとに別の字が割り当てられ得る。外字エディタで作った字形はeudc.tteに保存され、レジストリで各フォントに関連付けられる。
行政側は戸籍統一文字や、行政事務で用いる約六万字を対象とする文字情報基盤を土台に、標準準拠システムで使う文字集合を定める方向へ動いている。氏名を扱うシステムは受け入れる文字集合を決めて明示するのが要点になる。
文字情報基盤に対応するMoji_JohoコレクションはIVDに登録されており、IPAmj明朝で利用される。
PDF/Aは表示に必要な要素をファイル内に含めることを求めるためフォント埋め込みが必須だが、埋め込みの可否はフォントのfsTypeが宣言する埋め込み権限で決まる。許諾されていないフォントを埋め込んではいけない。
埋め込まなければ閲覧側は手元のフォントで代替描画し、字形どころかレイアウトも変わり得る。埋め込みは「10年後に開いたら字形が変わっていた」を防ぐ最も確実な方法になる。
指定したフォントにグリフがない文字は何も表示されないのではなく、別のフォントで代替描画される。豆腐(□)は指定フォントにもフォールバック先にもグリフがないという失敗の跡であり、データは生きていることが多い。
NFKC/NFKDは全角半角などの互換文字も統合するため、氏名データに安易にかけると保持すべき区別が失われる。
BIZ UDゴシックはWindows 10 バージョン1809以降に日本語補助フォントとして含まれるユニバーサルデザイン書体で、画面と帳票で同じ書体を明示指定して見た目を揃える際の選択肢になる。