[2]
フォント機能
hngl
は、
Hangul
です。
>>1
[18] ここでいう非推奨がどういう意味なのかは特に定められていません。 一般語として推奨されないということと理解するしかありません。
[19] 漢字とハングルの変換は、専用の辞書などによって行われるのが現在では一般的であり、 フォントに含まれる情報に依存するべきではないと考えられます。
[3]
フォント機能
hngl
は、
漢字 (hanja (Chinese-style) Korean characters) を対応するハングル
(hangul (syllabic) characters) に置換します。
>>1
[5]
多くの置換は1対1であり GSUB
の lookupType
1
が推奨されています。 >>1
[6]
しばしば複数のハングルの候補から利用者が選択する必要があり、
GSUB
の lookupType
3
が推奨されています。 >>1
[8] 複数の選択肢を提示する場合には、 フォントの族の中で代替候補の順序を一貫したものとするべきであり、 さすれば族内でフォントを切り替えたときにも正しく動作します。 >>1
[10] しかし OpenType としてはどのような置換や候補が提示されるべきかを一切規定していないのであり、 無関係のフォント同士で同じ様に動作する保証は一切ありません。
[16] フォント開発者は、 >>15 を前提に適切に順序を決めるべきです。 >>1
[20]
Adobe
は、
Adobe-Korea1
における
hngl
の実装例を提供していました。
その後身に当たる
Adobe-KR
には
hngl
は含まれていません。
[9]
hngl
は既定の状態で無効とするべきです。
hngl
は文書のマーク付け、利用者の制御、その他応用依存の方法によって適用できます。
>>1
[11] フォントが代替候補を提供している場合には、 応用はそのうち適切な1つを利用者が選択する手段を提供するべきです。 >>1
[14] 応用は、複数のハングルからの利用者の選択を覚えておき、 次に同じ漢字が出現したときの既定値として使うことができます。 >>1
[15] 応用は、 >>14 のような事前情報がないときは、 候補一覧の最初のハングルを好ましい形と仮定して構いません。 >>1
[12]
hngl
は実効的には文字コードの変更と等価でありますから、
応用は新しいグリフの文字コードを蓄積するべきです。
>>1
cmap
によって文字コードからグリフへと変換する情報が提供されていますが、 逆変換の情報は入っていません。文字コードからグリフへと1対1対応が保証されるならcmap
を逆変換すればグリフから文字コードに戻せるのですが、 一般にはそれが保証されないので、 複数の文字コードの候補が出現することになりますが、 これをどう解決するべきかは不明です。