[20] 結合文字は、 直前の基底文字と合成されて表示されるべき文字です。
[116] 結合文字の適用については、 The Unicode Standard は規定と指針を示しています。 特に文字のレンダリングに関する指針については、 レンダリングについて特に情報が与えられない場合の既定のレンダリングの挙動を示すものとされています。 個々の文字について typograph 的な慣習がある場合には、 適宜それを使って最適なレンダリングを実現することが期待されています。 >>115
[141] 文字の扱いは文化と慣習に依存した部分が大きく、 フォントやレンダリングシステムの影響も大きいので、 厳密に規定することには困難が多いのでしょう。 それにしても曖昧な規則が多く、 こんなので相互運用性は保てるのか疑問に思ってしまいますが、 実際相互運用性はかなり低いと言わざるを得ません。 違うシステムでレンダリングが違うのは当たり前で、 同じシステムでもインストールされているフォントの違い程度の些細な要因で違って表示されることがよくあるのが現状です。
[10] 結合文字 =
結合マークは、
General_Category が
Combining Mark (Mark, M) の文字
(符号位置)
です。
>>9, >>101, >>18
[12] 私用文字 (Co) を結合文字と解釈するか否かは、
実装によります >>9。
原則は基底文字扱いとされています。
[143] 結合文字は、 関連付けられた基底文字に対して相対的に決まる位置に表示される文字です >>142。
[150] 具体的には、 アルファベット系文字などに対するダイアクリティカルマーク、 アラビア文字の harakat、 デバナガリ文字の matra、 仮名の濁点・半濁点、 記号用ダイアクリティカルマーク、 囲み文字を作るための外枠文字などが結合文字として用意されています。
[210] 異体列に使われる異体選択子も結合文字とされています。
[144] 結合文字には、 非前進マークと前進マークがあります。 >>142
Mn)
か
Enclosing Mark (Me)
の結合文字です。
>>30Me)
であるものです。
囲みマークは、
非前進マークの部分クラスであって、
基底文字の上中下に配置するのではなく、囲むものです。
>>38[113] この分類は書記素クラスターの定義に関わってきます。
[26]
General_Category の値
Mark = M
は、
Spacing Combining Mark (Mc),
Nonspacing Mark (Mn),
Enclosing Mark (Me)
のいずれかであることを表します。
>>9, >>103
Co を除く)
https://chars.suikawiki.org/set/%24unicode%3Aspacing-markGeneral_Category=Mn の一覧
https://chars.suikawiki.org/set/%24unicode%3AMnGeneral_Category=Me の一覧
https://chars.suikawiki.org/set/%24unicode%3AMeGeneral_Category=Mc の一覧
https://chars.suikawiki.org/set/%24unicode%3AMc[211]
ZWJ,
ZWNJ
は結合文字列に含まれ得る文字で、
結合文字に近い扱いを受けていますが、
結合文字ではありません。
[13] 結合文字は、通常は単独では用いません。 >>9 基底文字の後に0個以上の結合文字を続ける形で使います。 結合文字は、その依存する基底文字の後に続けます >>115 P1, >>142, >>164。
[83]
Unicode
の結合文字は後置です。
Unicode 以前の文字コード規格には前置式を採用したものもありましたが、
Unicode
との変換では順序を入れ替える必要があります。
[156] 結合文字の数には制限がありません。 >>142, >>115
[46]
結合文字列 (CCS) は、
基底文字が0個または1個の後に、
1つ以上の結合文字、
ZERO WIDTH JOINER、
ZERO WIDTH NON-JOINER
のいずれかが続くような列であって最長のものです。
>>45
[48]
拡張済み結合文字列 (ECCS) は、
拡張済み基底が0個または1個の後に、
1つ以上の結合文字、
ZERO WIDTH JOINER、
ZERO WIDTH NON-JOINER
のいずれかが続くような列であって最長のものです。
>>47
[82]
「結合文字」の列というと0文字以上の結合文字の列のように聞こえますが、
実はそうではなく基底文字も (あれば) 含まれますし、
結合文字のかわりに
ZWJ / ZWNJ
が含まれる列のこともあります。
[114]
結合文字列、
拡張済結合文字列は書記素クラスターと似ていますが、
違うこともあります。
[212] 結合文字の順序には、意味があることも、ないこともあります。 (>>186)
[146] Unicode と Unicode 以外の文字コードを混在させられるシステムもあります。 例えば ISO/IEC 2022 は ISO/IEC 10646 と混在させる仕組みを定義しています。 すると Unicode (ISO/IEC 10646) とそれ以外の基底文字と結合文字の組合せも理屈の上では存在し得ます。 しかし Unicode はそうしたものを想定していないので何も言及していませんし、 ISO/IEC 2022 側にもそうした規定はありません。 結局そのようなシステムがどう動作するべきかは不明と言わざるを得ません。
[232] 現実的には、 そのシステムにおいて Unicode文字と非Unicode文字に対応関係が存在するなら、 その対応関係に基づきすべてUnicode文字だった場合と同等に動作するのでしょうし、 そうでなくても非Unicode文字が基底文字であるか、 結合文字相当のものであるかに応じて動作するのでしょう。
[233] また非spacing文字など Unicode にない概念の文字と Unicode文字との組み合わせもありえます。
[234] すると基底文字、結合文字、非spacing文字のすべての組み合わせで構成される文字列の出現の可能性も一応考えておかなければなりません。
[88] 結合文字の関連付けられた基底文字は、 その属する結合文字列中の基底文字です。 >>115 D61a
[14] 結合文字の図形の位置付けは、直前の基底文字であって非結合文字で zero width joiner でも zero width nonjoiner でもないものに依存します。 この時結合文字を基底文字に適用するといいます。 >>9 結合文字は関連付けられた基底文字に依存するといいます (依存性) >>115 D61a。
[118] 関連付けられた書記素基底とそれへの適用 (図形的適用) と似た意味ですが、 少しずつ定義が違います。 依存性はすべての種別の結合文字に関係します。 図形的適用は可視グリフを持つ nonspacing mark に関係します。
[15] 結合文字が適用されるべき基底文字がない場合 (結合文字が文字列の先頭の場合や、 制御文字や書式文字が前にある場合) には、 孤立結合文字といいます。 >>9
[81] 結合文字列のうち基底文字がないものを欠陥結合文字列といいます。 >>49
[117] 欠陥結合文字列中の結合文字には関連付けられた基底文字がありません。 どの基底文字にも依存するとはいえません。 >>115 D61a
[19] 完全正規化済みなど孤立した結合文字が出現しないことを要求する応用もあります。
[89] 意図的に使うことはあまりありませんが、 Unicode文字の一覧表などに出現することがあります。 結合文字を考慮しない文字列の分断 (一定の文字列長での分割など) で生じることもあります。
[198]
なお、
文頭において結合文字を含まず
ZWJ,
ZWNJ
のみで構成される欠陥結合文字列は、
正当に利用され得るものであるはずです。
[231] 結合文字はフォント上で現在位置より前に表示されるなど、 単独でレンダリングするとき取り扱いに注意を要することがあります。
[86]
結合文字自体を単独の文字として使いたいときは、
基底文字として
U+00A0 NO-BREAK SPACE
を使うことが出来ます。
>>142, >>164
[162]
Unicode 4.1
までは、
U+0020 SPACE
を使うことが推奨されていましたが、
推奨されなくなりました。
XML
などの
U+0020
の扱いと衝突することが理由とされています。
>>142, >>164
[87]
HTML と CSS (white-space:normal)
のような空白を正規化する処理が適用される環境では、
U+0020 を使うと思わぬ意図せぬ結果がもたらされることがあります。
[92]
CSS の text-emphasis は Z*
の文字かどうかで挙動が変わりますが、
間隔と結合文字が組み合わさったケースでは一般の文字と同じ扱いになります。
[163]
The Unicode Standard
の「推奨」
は変更されましたが、
互換分解は変更されていません (一度決めたら変更されないこととされています)。
多くの単独のダイアクリティカルマークは
NFKC、
NFKD
を適用すると
U+0020
が生成されてしまいます >>164。
(もっとも U+00A0 も NFKC, NKFD では U+0020
になります。)
[85] 結合文字が適用される基底文字には制約がありません。 すべての結合文字は、すべての基底文字に対して使うことが出来ます >>142。 普通はありえない基底文字と結合文字の組合せ、 例えば基底文字を「。」 (句点)、 結合文字を濁点とするような組合せは日本語としておおよそあり得ませんが、 Unicode として禁止されていません。 (それが意味を成すか、 意図した通りにレンダリングされるかどうかは、 また別の問題です。 >>148)
[169]
U+00A0
を始め中立方向性の文字を基底文字とするとき、
bidi
処理によって基底文字とspacing結合文字が分離されて意図せぬ形で表示される場合があります。
>>164
これを避けるには
LRM,
RLM,
bdi
の類を適宜使う必要があります。
[139] 韓音節の書記素クラスターにあっては、 結合文字は最後の字母だけではなく音節全体に適用されます。 enclosing combining mark も音節全体を囲みます。 >>115
[161] 基底文字の並びが合字として表示される場合であっても、 結合文字はそれが適用されるべき各部分の基底文字の後に置きます。 結合文字は ligated glyph の各部分に対して表示します。 >>142, >>164
[11] 正準結合クラスが 0 でない文字は、結合文字です。 しかし逆は真ではありません。正準結合クラスが 0 の結合文字もあります。 >>9
[153] 多くのアルゴリズム (すべてではありません。) は、 基底文字に結合文字が続く列を、 基底文字の特性を持つものとして扱います。 >>142 (これがうまく機能しないケースもあります (>>149)。)
[186] 1つの基底文字に対して、 結合文字はいくつでも適用できます。 結合文字の順序には制約がありません。 順序が意味を持つケースと、 意味を持たないケースがあります。 正準等価なものは同じようにレンダリングしなければなりません >>185。
[14] typograph的相互作用は、 grapheme base に対する相対的な位置が既に他の nonspacing mark に占有されているような nonspacing mark の図形的応用であって判読不能な重ね打ちやグリフの衝突を防ぐべく何らかのレンダリング上の調整 (default stacking や side-by-side placement など) が行われなければならないものをいいます。 >>209 D106
[119] 指針として、 同じ結合クラスの nonspacing mark は、 通常、 適用する書記素基底から図形的に外側に向かって配置していきます (inside-out application, default stacking behavior)。 >>115 P2, >>185 上側に置く結合文字は垂直に上方向へ、 下側に置く結合文字は垂直に下方向へと重ねていきます。 >>142, >>115 P2
[157]
タイ文字にあっては、
子音文字に対して
U+0E34 - U+0E37 の母音を上に置き、
更に
U+0E48 - U+0E4B の声調記号をその上に置きますので、
この順序で文字を並べます。
>>142
[120] 指針として、 特定の nonspacing mark については、 垂直に並べる default stacking behavior ではなく、 書記素基底の上下に横並びで、 言語依存の正書法規則に従い配置します (side-by-side application)。 >>115 P3
[121] side-by-side application における結合文字の視覚的なレンダリング順序は、 当該用字形における支配的な順序に依ります。 >>115 P3, >>142 左横書きでは左から右に並べます。 >>142 ギリシャ文字では書記素基底の上に、 1つ目の結合文字を左側、 2つ目の結合文字を右側に置きます。 ヘブライ文字では逆側に置きます。 >>115 P3
U+0313 COMBINING COMMA ABOVE,
U+0314 COMBINING REVERSED COMMA ABOBE
は、
acute accent, grave accent
と併用する時、
side-by-side application
します。
基底文字、
breathing mark、
accent mark
の順に並べ、
基底文字の上に左が
breathing mark、
右が
accent mark
と表示されます。
>>142U+1ABB COMBINING PARENTHESES ABOVE,
U+1ABC COMBINING DOUBLE PARENTHESES ABOVE,
U+1ABD COMBINING PARENTHESES BELOW
は side-by-side application します。
>>115 P3
これらはドイツ語の方言学で、
発音の修飾子の効果が弱められることを表します。
これらよりも前にあるダイアクリティカルマークを囲むように配置します。
>>164[123] 指針として、 伝統的な typographic な挙動により nonspacing mark の既定の配置を上書きする場合があります。 >>115 P4
[136]
指針として、
Soft_Dotted
特性の文字に
nonspacing mark above
(ccc = 230
の結合文字)
が適用されるとき、
基底文字に元々有る点は、
表示しません。
>>115 P9
[137] i や j の類が該当します。
この上にダイアクリティカルマークが来る時、
点のかわりにダイアクリティカルマークを書きます。
リトアニア語のように点とダイアクリティカルマークの両方を書く言語では、
U+0307 COMBINING DOT ABOVE
を使います
>>115 P9。
[127] 0 でない結合クラスの non-spacing mark の順序を入れ替えても、 結合文字列の視覚的表示や解釈は変化しません (nondistict order)。 >>115 P5 そのような場合は任意の順序で書くことが出来ます >>142。 実装は内部的に任意の順序に置き換えて処理できます >>185。 正準再順序付けアルゴリズムはこの性質に関する正規化の処理です。 NFC などの正規化を適用すると、 結合文字の順序が交換されることがありますが、 それは解釈に影響が出ない場合に限られます。
[128] combining grapheme joiner を使うと nondistinct order であっても正準再順序付けを抑制できます。 >>115 P5
[129] 指針として、 enclosing mark は、 関連付けられた書記素基底やそれとの間にある enclosing mark を囲むものとなります。 >>115 P6
[130] 囲み文字に nonspacing mark を付けて更に囲むような入れ子の構造も記述できます。
[182]
U+1DC0 COMBINING DOTTED GRAVE ACCENT,
U+1DC1 COMBINING DOTTED ACUTE ACCENT
は、
ギリシャ文字で使われ、
dialytika varia
と
dialytika oxia
の組み合わせの異体字です。
U+0308 COMBINING DIAERESIS,
U+0300 COMBINING GRAVE ACCENT,
U+0301 COMBINING ACUTE ACCENT
と混じると通常の stacking rule
では結果が信頼できないために別の文字として追加されたといいます。
>>164
[170] 二重ダイアクリティカルマークの結合文字は、 2つの基底文字の上や下に表示されますが、 1つ目の基底文字の後に続く結合文字として使います。
[131] 指針として、 二重ダイアクリティカルマークな nonspacing mark は、 書記素基底に適用しますが、 次の書記素基底も包むようなグリフとしてレンダリングされることが意図されています。 >>115 P7
U+0360 COMBINING DOUBLE TILDE
が該当します。
>>115 P7[133] 指針として、 二重ダイアクリティカルマークな nonspacing mark は、 書記素基底の上下に積んだ通常の nonspacing mark の最外側に「浮動」します。 >>115 P8, >>164 (surrounding diacritics は除きます。 >>164)
[135] ただ enclosing mark と二重ダイアクリティカルマークとの図形的な相互作用は十分に定義されておらず、 多くのフォントやレンダリング処理はこれを適切に扱えないかもしれません。 従って両者を同じ書記素クラスターに含めることは推奨されません。 >>115 P8
[171]
COMBINING GRAPHEME JOINER
を使うと正準再順序付けが抑制されます
>>164。
それ以前の結合文字とそれ以後の結合文字が区別されることになります。
これを使うと、通常なら二重ダイアクリティカルマークより内側に表示される結合文字を、
二重ダイアクリティカルマークより外側に表示するよう指定できます。
COMBINING GRAPHEME JOINER
[178]
縦書き時の扱いは特に規定されておらず、注意が必要となります。
[172] 3文字以上に対するダイアクリティカルマークは、 Unicode では扱えないとされています。 マーク付けによって記述するべきだとされています。 >>164
[173] 限られた状況では combining half mark が活用できることもあるものの、 平文で満足できるレンダリングは成せないといいます。 >>164
[174] こうしたものを用いる応用の実装のためには、 Unicode で結合文字として記述できる二重ダイアクリティカルマークだけでなく、 マーク付け言語により記述される三重以上のダイアクリティカルマークをも扱える仕組みが (共通であれ別々であれ) 必要となってきます。
[260]
なお、後続の文字 (3文字以上の場合も含みます。) に作用する文字として、
Prepended_Concatenation_Mark
たる文字があります。
U+0332 COMBINING LOW LINEU+0333 COMBINING DOUBLE LOW LINEU+0305 COMBINING OVERLINEU+033F COMBINING DOUBLE OVERLINE[177] これらは左右と接続されることが想定され、 組み合わせて使うことで文字列の上や下の連続線となります。 他の結合文字との相互作用や、 字間のアキその他の扱いのことがありますから、 こうした文字によって下線や上線を引くのは非推奨で、 スタイル指定を使うのがよいとされています。 >>164
[179]
縦書き時の扱いは特に規定されておらず、注意が必要となります。
[184] 二重ダイアクリティカルマークを分割した結合文字である combining half marks もあります。 これらは互換性文字で、 二重ダイアクリティカルマークが好ましいとされます。 >>164
[148] 任意の結合文字は任意の基底文字に適用できます (>>85) が、 実装はすべての組合せを等しく良く対応する必要はありません。 >>85
[189] 基底文字 + 結合文字の組み合わせという仕組みから、 文字の図形も合成で表示できそうな気がしますが、 現実には組み合わせごとに調整しなければ実用できる品質にはなりません。
[243] 例えば「A」と「a」の上部にアクセント記号を付け加えることを考えると、 汎用アクセント字形を単純に重ね合わせるだけでは美しくならないことがわかります。
[242] 大抵のフォントは、 一般的に用いられる組み合わせのグリフを予め用意しています。 これが結合文字列の表示方法の1つです >>185。 グリフ全体を別途用意しなくても、 基底文字のどの位置に結合文字を配置するかの情報があれば足りることもあります >>185。 こうした手法の実現には フォントの ligature や kerning のような技術が使われることがあります >>185。
[190] ですが、任意の組み合わせが許されている以上、 あらゆる組み合わせを想定したフォントを用意することは不可能です。 用意された組み合わせはフォントによっても異なります。 従って文字のレンダリングの実装は、 用意されていない組み合わせも何らかの形で扱える仕組みを持っていなければなりません (>>244)。
[194] 基底文字と結合文字の関係は、 書字方向とは関係しません。 結合文字は表示上の左側の文字に適用されるのではなく、 論理順の前の文字に適用されるのです。 従って右横書きでは左側の文字ではなく右側の文字に適用されることになります >>185。
[152] インド系文字の母音記号の結合文字には、 子音文字や子音クラスターの左側にレンダリングされるものもあります。 左横書きで左から右に文字を並べ、 基底文字の後に結合文字を置く順序であっても、 基底文字が右、結合文字が左とそこだけ逆転します。 これは表示順ではなく発音順を取ったもので、 Unicode 以前の文字コード ISCII の方式に倣ったものとされます。 >>142
[202] 結合文字が組み合わさることで、 結合文字列の幅と高さは基底文字の幅と高さから変化させることがあります。 文字や行の配置、 字間、行間の調整においては、 結合文字列の幅と高さを使って適切にレイアウトする必要が出てきます。
[203]
通常では使わないような異常な(1つ以上の)結合文字の利用によって、
上下左右の文字その他の構造に重ねて表示させる悪戯があります。
悪戯で済めば良いですが、
フィッシングなどに悪用できないとも限りません。
[32] 非前進マークの表現上の位置は基底文字に依存します。 通常はそれ自体に関して visual baseline に対して間隔を消費しません。 >>30
[33] ただし、非前進マークの大きさによって基底文字の表示位置が影響されることはあります。 >>30
[34] 例えば U+20DD COMBINING ENCLOSING CIRCLE
を使うと (それ自体が独立して表示幅を取ることはありませんが)
その前の基底文字の周りに円を描画して、かつ前後の文字と表示が重ならないよう、
基底文字の表示位置が通常と変化することになります。
U+0301 COMBINING ACUTE ACCENT
のように、
ラテン文字としての字形とギリシャ文字としての字形が異なるものもあります
>>164。
つまり基底文字によって字形が変化します。
なおラテン文字であってもポーランド語とフランス語とでは字形
(角度) が違います
>>164。g の下方と combining comma below
が衝突してしまうので、
かわりに
inverted comma above
として伝統的にレンダリングされてきました。
>>115 P4, >>164d の上方と
combining caron
が衝突してしまうので、
かわりに
apostrophe
として伝統的にレンダリングされてきました。
>>115 P4, >>164[195] 字間の調整は、 基底文字と結合文字の間で行うべきではありません >>185。 原則書記素クラスターの間で行うべきものでしょう (が、二重ダイアクリティカルマークなど注意が必要なケースがあります)。
[149] combining enclosing mark は、 記号を表現する文字に使うのに留めるのがいいです。 >>142
[155] その理由は、 文字特性の不一致が起こることでの驚きを抑えられることとされています。 >>142
[236]
例えば
U+0021 EXCLAMATION MARK
と
U+20E4 COMBINING ENCLOSING UPWARD POINTING TRIANGLE
で警告マークを表せますが、
!
が句読点であるが故に改行について通常の記号とは異なる挙動を示します。
[237]
故に
U+26A0 WARNING SIGN
は別に単独の記号として用意されており、
正規化による分解もされません。
>>153
[154] Vertical_Orientation
は書記素クラスターに対して定義され、
Me
の場合だけ書記素基底のものではなく固定値が割り当てられます。
Vertical_Orientation
Vertical_Orientation が比較的新しい特性であることと関係するのでしょう。[140] 古い実装は、 Indic consonant conjunct や、 combining grapheme joiner で連結された書記素クラスター群全体に対して enclosing combing mark で囲んでいました。 そうした手法には数々の問題があるので、 推奨されません。 >>115
[201] なぜか非推奨であって禁止はされていないようです。 相互運用性は低そうです。
[200] 非推奨とするだけで、 代替手段は用意されていないようです。
[41] 前進マークは一般に基底文字とそう違わない挙動を示します。 >>39
[42]
しかし U+0BCA TAMIL VOWEL SIGN O
のように、
(囲みマークでないにも関わらず)
基底文字の両側にレンダリングされるものもあります。
>>39
[217] OpenType development (LEGACY INFORMATION) - Typography | Microsoft Docs, nihar, https://docs.microsoft.com/ja-jp/typography/develop/otdevinfo#suggested-glyphs-for-complex-scripts
[220] OpenType におけるグリフ級 3 は、 マークグリフを表します。
[221] グリフにおけるマークグリフは文字における結合文字 (結合マーク) に近い概念です。 マークグリフは単体で使うことが想定されず、 基底グリフまたは合字グリフと組み合わせて使います。
[222]
マークグリフを基底グリフや合字グリフと組み合わせるには、
基底グリフや合字グリフの表すグリフの形状や、
他のマークグリフの形状が関係してきます。
フォントの設計者は関係グリフの相互関係を記述しなければなりません。
OpenType フォントではその情報を
GPOS 表に格納できます。
[246]
マークグリフであるかどうかはフォントの GDEF 表で指定でき、
結合文字のグリフをマークグリフでなく基底グリフとすることも可能です。
これがどのような意味を持つのか (同じフォントの GPOS 等からの参照以外に影響があるのか)
は十分明らかではありません。
[247]
例えば結合文字のグリフを基底グリフとすることで、
グリフの表示や文字列の選択の挙動を基底文字であるかのように変更できるでしょうか。
少なくても Windows の Chrome や Firefox では、
文字列の選択の単位や (kern がないときの) 結合文字のグリフの描画位置について、
GDEF の指定は効果がないように見えます。
[255]
>>247
GDEF によりマークグリフとして指定されると、
横書きなら横方向、
縦書きなら縦方向の現在位置の進行が0とみなされます。
後続のグリフの描画位置に影響するのはもちろん、
文字列の選択の範囲にも影響します。
[257]
>>247 GDEF で指定がないときの既定値が違うのか、
U+3099 だと進行しない、
U+16FF1 だと進行するのが何も指定しないときの挙動で、
GDEF で挙動を切り替えられます。
[249] Windows の Chrome や Firefox では、 専用グリフの有無に関わらず、結合列 (なのか書記素クラスターなのかその他なのか、詳細は要検証) は文字列の選択において1単位として扱われます。
[250]
Windows の Chrome や Firefox では、
GPOS
があれば、
結合文字のグリフの配置もそれに従うようになります。
それがない場合には、
結合文字のグリフを (結合文字の X軸の絶対値は無視して)
基底文字上の左右中央に揃えて配置します。
[251]
縦書きのとき、 Windows の Chrome も Firefox も、
GPOS
があれば結合文字を下隣に、高さ方向の現在位置を移動させずに配置します。
GPOS
がなければ結合文字を右上に、高さ方向の現在位置を移動させずに配置します。
[252] 縦書きのときの文字列の選択の挙動は、 Firefox は基底文字部分を選択するまあ妥当な挙動ですが、 Windows はそれより大きく、しかし結合文字部分を含めているわけでもない謎の範囲を選択するように見える謎挙動です。
[256]
現在位置を移動しないので次のグリフに重なる、という部分はマークグリフにしないことで回避できます
(>>255)。
基底グリフでなくてもマークグリフでも可で、 GDEF
が存在しないことでも回避可能です。
[254]
グリフ間の位置関係は kern / vkrn で調整できそうなものですが、
Firefox でも Chrome でも効果があるようには見えません。
[244] 基底文字と結合文字の組み合わせは任意のものがあり得ますから、 従って文字のレンダリングの実装は、 フォントに用意されていない組み合わせも何らかの形で扱える仕組みを持っていなければなりません。
[17] Unicode 符号表の代表画像には点線の円が示されています。 >>9, >>164 直前の基底文字と図形的結合して表示する場合には、基底文字を点線円部分に示すことが想定されています。 >>9
[159] default stacking behavior は素朴な方法で基底文字と結合文字を重ねて表示することで (品質はともかく) 一応実現可能です。 しかしその他の処理が必要となってくると、 表示位置や表示サイズを細かく制御する必要が生じてきます。
[188] 未対応の組み合わせの実装戦略 Simple Overlap は、 基底文字に重なる既定の固定の位置に結合文字を描画するもので、 大文字に合わせて高い位置に置くと小文字との間に空間が生じたりします >>185。
[16] 結合文字が孤立結合文字である場合や、図形的結合を行えない場合には、 図形的結合なしに、基底文字であるかのように表示して構いません。 >>9 未対応の組み合わせの実装戦略 Show Hidden は、 基底文字と結合文字をそれぞれ独立した単位として配置し、 結合文字には Unicode 符号表のように点線円を表示するといったものです >>185。
[248]
条件が複雑なので正確な挙動かどうかわかりませんが、
Windows の Chrome は基底文字と結合文字が同じフォント内にないと次のフォント候補を探し、
Windows の Firefox は基底文字と結合文字が別のフォントにあっても同じ位置に重ねるように見えます。
(GPOS との絡みは要検証, 基底文字側フォントの GPOS
の有無は影響しなそう。)
[258]
Windows の Chrome だと結合文字に明示的に対応したグリフがないとき (GPOS がないとき??)
に結合文字の通常の配置に合わせて(?)基底文字の上方にずらして結合文字用グリフを置くような未対応フォント向け制御も反映されているようです。
[192]
欠陥結合文字列は、
U+00A0 NO-BREAK SPACE
が基底文字であるかのようにレンダリングするべきです。
>>185
[196] とされますが、 実際には必ずしもそう実装されてはいないようです。 零幅で、 直前の余白や他の構造に被さって表示されたりします。
[197]
欠陥結合文字列のうち、
ZWJ,
ZWNJ
のみから構成されるものは、
零幅でレンダリングされるべきものであるはずです。
またカーソル移動なども直後の基底文字と一体的に扱うべきかと思われます。
[223] Unicode文字列としては基底文字とその後の0個以上の結合文字は連続していなければなりません。 しかし応用によってはソースコード上の文字列と表示される文字列とが違っていて、 基底文字と結合文字の関係性に変化が生じることがあります (例えば >>96)。 また、文字列とは別に与えられたフォント指定等で基底文字と結合文字の関係性に変化が加えられることがあります。
[218]
OpenType 的にはフォントが違うと別の連なりに属するということになっています。
[95] テキスト系のデータ形式 (マーク付け言語) と結合文字の関係は、 テキストファイルとしての表示や編集を考慮する時、 やや複雑になります。
[98] 文字参照やエスケープのような機能を使うと、 結合文字を直接入力しづらいときでも、 代替表現で容易に指定できます。
[94]
CSS の結合文字の扱いは仕様書上は必ずしも明らかではありません。
例えば基底文字と結合文字が連続する別の要素に属する時でも合成されて表示されるべきかどうか、
両方の要素で特性 (例えば 'color') が違うときどう表示されるべきか、
明確ではありません。
[93]
::first-letter
は最初の文字の後に結合文字があれば、
それも含みます。
CSS2
仕様書には結合文字だけ子要素に入っている場合であっても、
そこまで含まれるという実例が示されていました。
CSS2
の改訂である
Selectors 3、
その改訂である
CSS Pseudo-Elements Module Level 4
ではなぜかその実例はなくなっています。
[90] html - Highlighting Combining Characters - Stack Overflow, https://stackoverflow.com/questions/26407896/highlighting-combining-characters
[91] 書字方向は結合文字処理などを経た grapheme cluster
を対象に挙動が定義されています。
[68] 前置式の subtending mark もあります。
[35] 現在の Unicode 式の結合文字以前には、 文字コードレベルで文字合成を行う手法として、 次のものがありました。
BS や CR をつかった重ね打ち
GCC[227] JIS X 0207 にも何かあったらしい。
[84] どうして Unicode は後置型を採用したのでしょう。 文字列を前から走査して grapheme cluster を見つけていくには前置型の方が都合がいい気もしますが。
[241] 基底文字をレンダリングして、その前後にダイアクリティカルマークを付加していく、という方式なら後置型の方が都合がよかったのかもしれません。
[107] ISO/IEC 10646 は文字集合として Unicode と同じであるだけでなく結合文字の扱いも一致しています。 ただし Unicode と ISO/IEC 10646 とでは用語法に若干の違いが見られます。
- 結合文字 (combining character)
- この規格群で規定する符号化文字集合の識別された部分集合の構成単位であって、先行する非結合文字 (以下、基底文字という。) と組み合わせることを意図したもの、又は基底文字の後に結合文字の列が続いた形のものと組み合わせることを意図したもの (4.14 参照)。 (JIS X 0221‐1:2001 4.12)
[1] 2002-11-03 (日) 15:52 名無しさん: 非結合文字は被結合文字の typo じゃないかと一瞬思いますが、規格を良く読むとこれで正しいことが分かります。
備考 1. 合成列からなる図形記号は、通常、 その合成列を構成する各文字の図形記号の組合せからなる。
2. 合成列は、文字とはみなさない。したがって、 この規格群のレパートリの構成単位ではない。 (JIS X 0221‐1:2001 4.14)
[108] 合成列は結合文字列と同じようなものですが、
基底文字が必須で、
ZWJ
や
ZWNJ
は含まれません。
[104]
ISO/IEC 2022
にも合成に関する規定があります。
合成手法として、
重ね打ち式文字合成、
Unicode 式結合文字、
GCC
が示されています。
6.3.3 図形文字の結合 特に指定されない限り、図形文字は、 結合文字としてはならない。すなわち、 隣接する図形文字と組み合わせようとしてはならない。
図形文字集合によっては、複数の図形文字を一つの図形記号として可視化することによって、 追加の図形記号 (例えば、アクセント付き文字) を図形表現することを許しているものもある。この規格では、 二つの結合方法があることを認識している。
a) 基底文字の図形文字は、制御文字の
BACKSPACE(後退) 又はCARRIAGE RETURN(復帰) を使用して、組み合わせてよい。b) 結合文字として指定されている図形文字は、 基底文字の図形文字と組み合わせてもよい。
ISO 2375 に従って、図形文字集合の登録を行おうとする申請者は、 集合中の結合文字を明らかにしておくことが期待される。
参考1. 登録では、これらの要件の詳細を求められないので、 文字集合を規定する規格は、結合文字がある場合、 それ自身で、これを指定しその用法を示しておくのがよい。
2. ISO/IEC 646 の図形文字では、 アクセント付き文字を表現するのに、 a) の方法が認められている。
3. JIS X 0211 では、第3の方法として、文字自身の仕様に関係なく、
GRAPHIC CHARACTER COMBINATION(GCC) の制御機能を使った図形文字の結合を規定している。 JIS X 0202:1998
- 結合文字 (combining character)
- 符号化文字集合の識別された部分集合の構成単位であって、先行する非結合文字 (以下、基底文字という。) と組み合わせることを意図したもの、又は基底文字の後に結合文字の列が続いた形のものと組み合わせることを意図したもの。 (JIS X 0202:1998 4.8)
[105] ISO/IEC 2022 の体系で使われる ISO-IR に登録された図形文字集合では実はなぜかここに挙げられていない非spacing文字 (前置アクセント型) 方式の文字合成が一番よく使われているのではないかと思われます。
[106] Unicode 型の結合文字を使った ISO-IR に登録された図形文字集合はどれだけあるのでしょうか。 JIS X 0213:2000 と JIS X 0213:2004 が思い浮かびますが、 他にもあるのでしょうか。
[3] 10646 での結合文字の使い方は、 24. に規定があります。結合文字の一覧は附属書 B にあります。結合文字が使えるかどうかは実装水準と関係します。
COMBINING MACRON
と COMBINING DIAERESIS)
は、だんだん外側に
(MACRON より DIAERESIS を上に) 配置していきます。[147]
当初の
ISO/IEC 10646
は、
実装水準を3つに区別していました。
その違いは主に結合文字の利用の可否でした。
LARGE CIRCLE[70] JIS X 0213:2000 は、 重ね打ち式文字合成を禁止する JIS X 0208:1997 の規定を引き継ぎました。 かわりに新方式の文字合成の規定を持っていました。
4) ダイアクリティカルマーク (合成可能) ダイアクリティカルマーク (合成可能) 32文字の名前及 びビット組合せは, 附属書4表4による。
備考 文字合成を実装する場合には, 合成を行う際に, ダイアクリティカルマーク (合成可能) を, 現在位置の前進を伴わない文字として用いることができる。なお, ダイアクリティカルマーク を用いた文字の合成を想定する場合は, 文字合成の実装の有無にかかわらず, ダイアクリティ カルマーク (合成可能) を使用することを推奨する。
[71] 文字の合成を想定する場合であって、 文字合成の実装が無い場合とは、 どういう場合なのでしょうか? よくわかりません。 文字合成の実装が無いのにダイアクリティカルマーク (合成可能) を適切に使用することができるものでしょうか。
[27] 文字合成を実装しない場合には、これらの文字は使えるのでしょうか。 使った場合どう扱われるのでしょうか。
[102] 「合成可能」という表現と「文字合成を実装する場合」 という規定は、 合成する場合としない場合が両方存在し得ることを意味しているようですが、 両者はどう区別されるのでしょうか。 JIS X 0213 を使ったテキストファイルを受信した時、 それがどちらであるかは決定できるのでしょうか。
8. 合成文字の取扱い この規格で規定する符号化文字集合中のすべての図形文字は, 別に規定するもの を除き, 現在位置の前進動作を伴う文字とする。 文字合成を実装する場合は, ダイアクリティカルマーク (合 成可能) は, 現在位置の前進を伴わない文字として用いてもよい。
[72] 現在位置の前進を伴わない文字がどのようなもので、 どう利用するものかは、 JIS X 0213 には書いてありません。 これは規格として成り立っているのでしょうか?
[73]
既存の
ISO文字コードには現在位置の前進を伴わない文字
(非spacing文字)
を定めたものがいくつかありますが、
それらは前置アクセント方式を採用しています。
1.3.3 ダイアクリティカルマーク (合成可能) この規格は, 実用的な見地から, 音声記号を広く採録することとした。 音声記号では, 基本となる図形文字を合成することにより, 対象となる音声を図形文字として表現することが行わ れている。JIS X 0208は, 図形文字の合成を禁止しているが, この規格では, 音声記号に必要な図形文字について は, 合成の許容についての規定を設けた (本体8.参照)。
合成が許容される音声記号の採録に当たっては, IPAの音声記号チャートから, 音声記号としての図形文字の合 成の際に必要となる基本的なダイアクリティカルマークを選定し, それらの32の図形文字を, 現在位置の前進を伴 わない文字として利用することができるダイアクリティカルマーク (合成可能) として追加することとした。ダイ アクリティカルマーク (合成可能) の中には, JIS X 0208で規定しているダイアクリティカルマーク, 又は, 今回 新たに追加したダイアクリティカルマークと類似するものがあるので, そのような図形文字については, それぞれ の図形文字の区別に注意する必要がある。なお, ダイアクリティカルマーク (合成可能) の例示字体は,
̤ 点線円、囲み四角形 (1-11-82, COMBINING DIAERESIS BELOW, 下ダイエレシス (合成可能), かすれ音) のように, 合成対象となる図 形文字の位置を破線の丸で示しているので, これらの文字の同定の際には, 注意する必要がある。
[75] 「音声記号に必要な図形文字については」 と限定しているかのように聞こえますが、 本体8.は合成の一方を 「ダイアクリティカルマーク (合成可能)」 と指定しているだけです。 基底文字側は何も制約がありませんが、 任意の図形文字を使えると理解していいのでしょうか? それとも 「音声記号に必要」と何らかの基準で限定されるべきものなのでしょうか。 この説明で意図はわかりましたが、 使い方は全然わかりません。
[99] 合成済の文字が既に JIS X 0213 に含まれているときも、文字合成は使っていいのでしょうか。 両方が認められるとすると、どちらが優先されるべきなのでしょうか。 文字列の比較はどうするべきなのでしょうか。
[100] 合成可能な文字を複数使うことはできるのでしょうか。 その際合成可能な文字の順序はどう解釈されるのでしょうか。 合成済の文字に更に別の合成可能な文字を使うこともできるのでしょうか。
[76] こうした疑問点は、 JIS X 4051:2004 を読めば一応ある程度は解決します (>>59)。 想定される利用法は Unicode の結合文字と同じであるようです。
[77] JIS X 0213:2000 には (JIS X 0213:2004 にも) JIS X 4051 を読めとは一言も書いてありませんし、 JIS X 4051 以外の JIS X 0213 の応用には適用されない規定なので、 この解釈でいいのか疑問は残りますが...
[78] JIS X 0213 は誰もつかっていないようなので、 今後の改正でこうした謎が明かされる可能性も低そうです。
[59] 結合文字の処理は、 1つの基底文字と、 それに続くすべての連続する結合文字で構成される、 合成列を処理するものです。 >>58 基底文字は、 結合文字に先行する非結合文字です >>66 22)。 結合文字は、 基底文字の直後に続き、基底文字または既に合成した合成列と組み合わせることを意図した図形文字です >>66 45)。 合成列は、 基底文字とそれに続く1つ以上の結合文字とからなる図形文字の列です >>66 47)。
[61] 合成列に対応する字形が用意されているばあい、 それを使います。 そうでない場合、 合成します。 >>58
[62] 合成は、 記述された結合文字の順に、 JIS X 0221 に従い、 結合文字の位置属性に従い、基底文字または既に合成した合成列の上、 下、 右上、 左下などに配置します。 >>58 (従って同じ位置に複数の結合文字があれば、 だんだん外側へと付け足されていきます。)
[63] 結合文字は、基底文字の大きさに合わせて配置するべきです。
>>58
(例えば上に配置するとき、 e よりも E のときの方が高く配置します。)
[65] i
や
j
の上に結合文字を配置するときは、
基底文字の点を削除するべきです。
>>58
[64] 基底文字が斜体のとき、 斜めになった基底文字の縦軸に合わせて結合文字の位置をずらすべきです。 >>58
[67] 結合文字の文字クラスは欧文間隔以外の欧文用文字とされます。 >>58 結合文字に文字クラスをこのように定めて正しく処理できるのかどうか不明です。 合成列の文字クラスではないのでしょうか。 基底文字が欧文間隔以外の欧文用文字のときはいいですが、 そうでないときもこの扱いでいいのでしょうか。 (おそらく想定外なのでしょうが、そのように書かれてはいません。)
[79] (Unicode や OpenType ではなく) この JIS X 4051 の規定に基づく実装があるのかどうかは不明です。
[5] I'm not a Klingon (<span style="font-family:pIqaD,code2000"> </span>) : Most combining characters in a Unicode glyph/character/whatever ( 版) http://blogs.msdn.com/shawnste/archive/2010/01/25/most-combining-characters-in-a-unicode-glyph-character-whatever.aspx
[6] Web Applications 1.0 r6611 Allow combining characters wherever, per Mark Davis. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=6610&to=6611
[7] Bug 13502 – Text run starting with composing character should be valid ( ( 版)) https://www.w3.org/Bugs/Public/show_bug.cgi?id=13502
[25] 合成用の「☆」や「★」がほしい。合成用丸があるんだしw
[50] た͜͜͏̘̣͔͙͎͎̘̜̫̗͍͚͓͜͜͏̘̣͔͙͎͎す͜͜͏̘̣͔͙͎͎ơ̟̤̖̗͖͇̍͋̀͆̓́͞͡け̜ͪ̅̍̅͂͊てとは (タスケテとは) [単語記事] - ニコニコ大百科 () https://dic.nicovideo.jp/a/%E3%81%9F%CD%9C%CD%9C%CD%8F%CC%98%CC%A3%CD%94%CD%99%CD%8E%CD%8E%CC%98%CC%9C%CC%AB%CC%97%CD%8D%CD%9A%CD%93%CD%9C%CD%9C%CD%8F%CC%98%CC%A3%CD%94%CD%99%CD%8E%CD%8E%E3%81%99%CD%9C%CD%9C%CD%8F%CC%98%CC%A3%CD%94%CD%99%CD%8E%CD%8E%C6%A1%CC%9F%CC%A4%CC%96%CC%97%CD%96%CD%87%CC%8D%CD%8B%CC%80%CD%86%CC%93%CC%81%CD%9E%CD%A1%E3%81%91%CC%9C%CD%AA%CC%85%CC%8D%CC%85%CD%82%CD%8A%E3%81%A6
[208] Quivira Combining Characters - QuiviraCombining.pdf, , http://www.quivira-font.com/files/QuiviraCombining.pdf
[213] さく҉らん҉̴҉҇ぼ小҉̷҉学校҉̶҉҇҉̨҉͌3.҉̸҉̕҉̢҉̔m҉̵҉͝҉̢҉̓҉̓҉̚҉͌҉p҉҉҉͠҉͢҉͋҉͋҉̈҉4҉̷҉͝҉̨҉̏҉̀҉͔҉̜҉̙ - ニコニコ動画 () https://www.nicovideo.jp/watch/sm38869649
[219] ず҈̡̟͎̙̗̪̓̀̓̃̆͊͗̆̕んだ̴̮̣̙͇҇̃̈̔͐͢も҈̨̳̱͍̗̑̍͂̎̕̚̚̚̚ん҉マンションの日常 - ニコニコ動画 () https://www.nicovideo.jp/watch/sm40995049
[228] Unicode正規化 用語の混乱について 第4.2版 – ものかの, , https://tama-san.com/unicode-normalize-confusion/
[259] 「文̥字̥打̥つ̥と̥車̥輪̥が̥つ̥く̥よ̥う̥に̥な̥っ̥た̥の̥で̥す̥が̥こ̥れ̥は̥な̥に̥な̥の̥か̥誰̥か̥ご̥存̥知̥な̥い̥で̥す̥か̥;;」謎のバグに苦しむVTuberに解決案が寄せられるもお手上げ状態 - Togetter () https://togetter.com/li/2323359