[4] Web互換性のため、文字コード等に依存した特殊な表示処理が必要となることがあります。
[2] ISO-8859-8 は視覚順ですが、 Webブラウザーは基本的に論理順です。 そこで HTML Standard と Webブラウザーは ISO-8859-8 のときだけ特別な利用者エージェントスタイルシートを適用する >>1 形でこれを処理しています。
[10] 文書の文字符号化が ISO-8859-8 のとき、 HTML Standard が規定する利用者エージェントスタイルシート片を適用することが期待されます。 >>1
[5]
Shift_JIS
の
0x5C は U+005C に対応しますが、 U+00A5 YEN SIGN
の字形で表示する必要があります。
[6] 完全にフォント依存になっている実装もあれば、 特殊な処理が入っている実装もあります。
[7]
Shift_JIS のときだけ字形を差し替えるような何らかの GSUB
機能を CSS で適用する形で処理できれば綺麗なのでしょうが、
そのようなフォントは実在していないので、
個別の実装で対処が必要になります。
[8] UTF-8 でも同様の問題が存在するため、
文字コードと関係なくフォントの選択において処置が必要となります。
[9]
CP949
の
0x5C は U+005C に対応しますが、 WON SIGN
の字形で表示する必要があります。
[11]
円問題と同様に UTF-8 でも存在する問題で、
フォントの選択において処置が必要となります。
[32] OEMコードページは CL 領域にもグリフを割り当てていました。
[33] ところが多くの文字コードの変換の実装は C0制御文字 へと写像しています。 現在の一般的な Unicodeフォントを使ったシステムでは、 一部のシステムフォントが一部の C0制御文字に OEMコードページ相当のグリフを割り当てている場合もあるものの、 不完全です。
[34] OEMコードページのデータを表示するときは、 C0制御文字にOEMコードページ相当のグリフが割り当てられたフォントを選択する必要があります。
[35]
何らかの GSUB
機能を CSS で適用する形で処理できれば綺麗なのでしょうが、
そのようなフォントは実在していないので、
個別の実装で対処が必要になります。
[15]
ルーマニア語の文字について ISO-8859-2 と Windows-1250
は問題を抱えていました。
これについては Unicode でも ISO-8859-2/Windows-1250
に対応する符号位置と新設されたルーマニア語用の符号位置との問題という形で引き継がれています。
[16]
ルーマニア語用のフォントは新旧どちらの符号位置もルーマニア語用の字形を実装したり、
ルーマニア語専用でないフォントは locl を使ったりすることでこの問題は対処されています。
[17]
現在の多くの HTML文書は言語情報の指定がありますが、古い文書はそれが欠けている場合も多く、
locl を使って表示されるよう配慮が必要となります。
[12]
ルーマニア語に対応しないフォントが選ばれないよう、
フォントの選択の際に配慮が必要となります。
[13] フォント依存符号化を使った7ビット符号や8ビット符号についてはフォント依存符号化参照。
[14] Big5, GBK, EUC-KR のような多バイト符号の一部または全部が文字参照になっていることが稀にあります。
[18] 文字コードの判定に準じた手法で文字参照からバイトに復元したバイト列の文字コードの判定でいずれであるか (またはどれでもなく復元が不要か) を検知する必要があります。