hngl

hngl

[2] フォント機能 hngl は、 Hangul です。 >>1

代替

[17] hngl非推奨 (DEPRECATED) とされています。 >>1

[18] ここでいう非推奨がどういう意味なのかは特に定められていません。 一般語として推奨されないということと理解するしかありません。

[19] 漢字ハングルの変換は、専用の辞書などによって行われるのが現在では一般的であり、 フォントに含まれる情報に依存するべきではないと考えられます。

仕様書

意味

[3] フォント機能 hngl は、 漢字 (hanja (Chinese-style) Korean characters) を対応するハングル (hangul (syllabic) characters) に置換します。 >>1

[4] これは実効的には、ハングルを入力して漢字に置換する標準の入力方式を逆転させるものです。 >>1

[7] 例えば グリフから グリフに置換できます。 >>1

フォントの実装

[5] 多くの置換は1対1であり GSUBlookupType 1推奨 (recommended) されています。 >>1

[6] しばしば複数のハングルの候補から利用者が選択する必要があり、 GSUBlookupType 3推奨 (recommended) されています。 >>1

[8] 複数の選択肢を提示する場合には、 フォント (family) の中で代替候補の順序を一貫したものとするべきであり (should) 、 さすれば内でフォントを切り替えたときにも正しく動作します。 >>1

[10] しかし OpenType としてはどのような置換や候補が提示されるべきかを一切規定していないのであり、 無関係のフォント同士で同じ様に動作する保証は一切ありません。

[16] フォント開発者は、 >>15 を前提に適切に順序を決めるべきです (should) >>1

[20] Adobe は、 Adobe-Korea1 における hngl の実装例を提供していました。 その後身に当たる Adobe-KR には hngl は含まれていません。

表示の実装

[9] hngl は既定の状態で無効とするべきです (should) hngl文書マーク付け利用者の制御、その他応用依存の方法によって適用できます。 >>1

[11] フォントが代替候補を提供している場合には、 応用はそのうち適切な1つを利用者が選択する手段を提供するべきです (should) >>1

[14] 応用は、複数のハングルからの利用者の選択を覚えておき、 次に同じ漢字が出現したときの既定値として使うことができます。 >>1

[15] 応用は、 >>14 のような事前情報がないときは、 候補一覧の最初のハングル好ましい形 (preferred form) と仮定して構いません。 >>1

[12] hngl は実効的には文字コードの変更と等価でありますから、 応用は新しいグリフ文字コード蓄積 (store) するべきです (should) >>1

[13] フォント機能はあくまでグリフグリフに変換する方法を記述するものですが、 なぜか文字コードまで変更するように要求しています (元の文字コードを破棄するべきなのか、 両方を保持するべきなのかまでは明言していません)。 OpenType フォントには cmap によって文字コードからグリフへと変換する情報が提供されていますが、 逆変換の情報は入っていません。文字コードからグリフへと1対1対応が保証されるなら cmap を逆変換すればグリフから文字コードに戻せるのですが、 一般にはそれが保証されないので、 複数の文字コードの候補が出現することになりますが、 これをどう解決するべきかは不明です。

メモ