default stacking

結合文字 (Unicode)

[20] (けつ) (ごう) () () (combining character) は、 直前の基底文字合成されて表示されるべき文字です。

仕様書

[116] 結合文字適用については、 The Unicode Standard規定指針 (guideline) を示しています。 特に文字のレンダリングに関する指針については、 レンダリングについて特に情報が与えられない場合の既定のレンダリングの挙動を示すものとされています。 個々の文字について typograph 的な慣習がある場合には、 適宜それを使って最適なレンダリングを実現することが期待されています。 >>115

[141] 文字の扱いは文化と慣習に依存した部分が大きく、 フォントレンダリングシステムの影響も大きいので、 厳密に規定することには困難が多いのでしょう。 それにしても曖昧な規則が多く、 こんなので相互運用性は保てるのか疑問に思ってしまいますが、 実際相互運用性はかなり低いと言わざるを得ません。 違うシステムでレンダリングが違うのは当たり前で、 同じシステムでもインストールされているフォントの違い程度の些細な要因で違って表示されることがよくあるのが現状です。

結合文字とその分類

[10] 結合文字 (combining character) = 結合マーク (combining mark) は、 General_CategoryCombining Mark (Mark, M) の文字 (符号位置) です。 >>9, >>101, >>18

[12] 私用文字 (Co) を結合文字と解釈するか否かは、 実装によります >>9。 原則は基底文字扱いとされています。 基底文字私用文字

[143] 結合文字は、 関連付けられた基底文字に対して相対的に決まる位置に表示される文字です >>142

[150] 具体的には、 アルファベット系文字などに対するダイアクリティカルマークアラビア文字harakatデバナガリ文字matra仮名濁点半濁点記号用ダイアクリティカルマーク囲み文字を作るための外枠文字などが結合文字として用意されています。

[210] 異体列に使われる異体選択子結合文字とされています。

[144] 結合文字には、 非前進マーク前進マークがあります。 >>142

[166] Unicode 以前の文字コード結合文字に相当するものは非spacing文字などと言っていました。 しかし Unicode結合文字には spacing な文字も非spacing な文字もあるのです。

[113] この分類は書記素クラスターの定義に関わってきます。

[26] General_Category の値 Mark = M は、 Spacing Combining Mark (Mc), Nonspacing Mark (Mn), Enclosing Mark (Me) のいずれかであることを表します。 >>9, >>103

[211] ZWJ, ZWNJ結合文字列に含まれ得る文字で、 結合文字に近い扱いを受けていますが、 結合文字ではありません。

結合文字列

[13] 結合文字は、通常は単独では用いません。 >>9 基底文字の後に0個以上の結合文字を続ける形で使います。 結合文字は、その依存する基底文字の後に続けます >>115 P1, >>142, >>164

[151] この順序は、 Semitic scriptsインド系文字論理順と一貫したものとされます。 更に、 近代フォント技術の nonspacingグリフの取り扱いとも合致しているため処理しやすいとされます。 >>142, >>164

[83] Unicode結合文字は後置です。 Unicode 以前の文字コード規格には前置式を採用したものもありましたが、 Unicode との変換では順序を入れ替える必要があります。 非spacing文字

[156] 結合文字の数には制限がありません。 >>142, >>115

[229] 現実には、セキュリティーのため実装は現実的な個数に制限する必要があります。 プラットフォーム制限条項 上限を超えた場合は、合成しないで表示するなど、代替手段を採ることになります。

[46] 結合文字列 (combining character sequence) (CCS) は、 基底文字が0個または1個の後に、 1つ以上結合文字ZERO WIDTH JOINERZERO WIDTH NON-JOINER のいずれかが続くような列であって最長のものです。 >>45

  1. ?
    1. 基底文字
  2. +
    1. |
      1. 結合文字
      2. ZERO WIDTH JOINER
      3. ZERO WIDTH NON-JOINER

[48] 拡張済み結合文字列 (extended combining character sequence) (ECCS) は、 拡張済み基底が0個または1個の後に、 1つ以上結合文字ZERO WIDTH JOINERZERO WIDTH NON-JOINER のいずれかが続くような列であって最長のものです。 >>47

  1. ?
    1. 拡張済み基底
  2. +
    1. |
      1. 結合文字
      2. ZERO WIDTH JOINER
      3. ZERO WIDTH NON-JOINER
[80] ただの結合文字列とは、 標準韓音節ブロックが含まれるかどうかが違います。 拡張済み基底

[82] 「結合文字」の列というと0文字以上の結合文字の列のように聞こえますが、 実はそうではなく基底文字も (あれば) 含まれますし、 結合文字のかわりに ZWJ / ZWNJ が含まれる列のこともあります。

[114] 結合文字列拡張済結合文字列書記素クラスターと似ていますが、 違うこともあります。 書記素クラスター

[212] 結合文字の順序には、意味があることも、ないこともあります。 (>>186)

[146] UnicodeUnicode 以外の文字コードを混在させられるシステムもあります。 例えば ISO/IEC 2022ISO/IEC 10646 と混在させる仕組みを定義しています。 すると Unicode (ISO/IEC 10646) とそれ以外の基底文字結合文字の組合せも理屈の上では存在し得ます。 しかし Unicode はそうしたものを想定していないので何も言及していませんし、 ISO/IEC 2022 側にもそうした規定はありません。 結局そのようなシステムがどう動作するべきかは不明と言わざるを得ません。

[232] 現実的には、 そのシステムにおいて Unicode文字非Unicode文字に対応関係が存在するなら、 その対応関係に基づきすべてUnicode文字だった場合と同等に動作するのでしょうし、 そうでなくても非Unicode文字基底文字であるか、 結合文字相当のものであるかに応じて動作するのでしょう。

[233] また非spacing文字など Unicode にない概念の文字と Unicode文字との組み合わせもありえます。

[234] すると基底文字結合文字非spacing文字のすべての組み合わせで構成される文字列の出現の可能性も一応考えておかなければなりません。

基底文字と結合文字の関係性

[88] 結合文字関連付けられた基底文字 (associated base character) は、 その属する結合文字列中の基底文字です。 >>115 D61a

[14] 結合文字図形の位置付けは、直前の基底文字であって非結合文字zero width joiner でも zero width nonjoiner でもないものに依存します。 この時結合文字基底文字適用する (apply) といいます。 >>9 結合文字関連付けられた基底文字依存する (depend) といいます (依存性 (dependence) ) >>115 D61a

[118] 関連付けられた書記素基底とそれへの適用 (図形的適用) と似た意味ですが、 少しずつ定義が違います。 依存性はすべての種別の結合文字に関係します。 図形的適用は可視グリフを持つ nonspacing mark に関係します。

孤立結合文字

[15] 結合文字適用されるべき基底文字がない場合 (結合文字文字列の先頭の場合や、 制御文字書式文字が前にある場合) には、 孤立結合文字 (isolated combining character) といいます。 >>9

[81] 結合文字列のうち基底文字がないものを欠陥結合文字列 (defective combining character sequence) といいます。 >>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 を使うことが推奨 (recommended) されていましたが、 推奨されなくなりました。 XML などの U+0020 の扱いと衝突することが理由とされています。 >>142, >>164

[87] HTMLCSS (white-space:normal) のような空白を正規化する処理が適用される環境では、 U+0020 を使うと思わぬ意図せぬ結果がもたらされることがあります。

[92] CSStext-emphasisZ* の文字かどうかで挙動が変わりますが、 間隔結合文字が組み合わさったケースでは一般の文字と同じ扱いになります。

[163] The Unicode Standard の「推奨」 は変更されましたが、 互換分解は変更されていません (一度決めたら変更されないこととされています)。 多くの単独のダイアクリティカルマークNFKCNFKD を適用すると U+0020 が生成されてしまいます >>164。 (もっとも U+00A0NFKC, NKFD では U+0020 になります。)

[235] 方向性との相互作用にも注意が必要です (>>169)。

基底文字の種類

[85] 結合文字適用される基底文字には制約がありません。 すべての結合文字は、すべての基底文字に対して使うことが出来ます >>142。 普通はありえない基底文字結合文字の組合せ、 例えば基底文字を「。」 (句点)、 結合文字濁点とするような組合せは日本語としておおよそあり得ませんが、 Unicode として禁止されていません。 (それが意味を成すか、 意図した通りにレンダリングされるかどうかは、 また別の問題です。 >>148)


[169] U+00A0 を始め中立方向性文字基底文字とするとき、 bidi 処理によって基底文字spacing結合文字が分離されて意図せぬ形で表示される場合があります。 >>164 これを避けるには LRM, RLM, bdi の類を適宜使う必要があります。


[139] 韓音節書記素クラスターにあっては、 結合文字は最後の字母だけではなく音節全体に適用されます。 enclosing combining mark音節全体を囲みます。 >>115

[225] ハングル音節に対しては、声調符号濁点が付与されることがあります。

[161] 基底文字の並びが合字として表示される場合であっても、 結合文字はそれが適用されるべき各部分の基底文字の後に置きます。 結合文字ligated glyph の各部分に対して表示します。 >>142, >>164

[175] ただし合字になるかどうかは typographic 的な慣習に依存します。 ダイアクリティカルマークが付かない時合字化されても、 ダイアクリティカルマークが付いたことで合字化されないこともあります。 >>164

性質

[11] 正準結合クラスが 0 でない文字は、結合文字です。 しかしは真ではありません。正準結合クラスが 0 の結合文字もあります。 >>9

[153] 多くのアルゴリズム (すべてではありません。) は、 基底文字結合文字が続く列を、 基底文字特性を持つものとして扱います。 >>142 (これがうまく機能しないケースもあります (>>149)。)

結合文字相互の順序

[186] 1つの基底文字に対して、 結合文字はいくつでも適用できます。 結合文字の順序には制約がありません。 順序が意味を持つケースと、 意味を持たないケースがあります。 正準等価なものは同じようにレンダリングしなければなりません >>185

[14] typograph (てき) 相互作用 (そうごさよう) (typographic interaction) は、 grapheme base に対する相対的な位置が既に他の nonspacing mark に占有されているような nonspacing mark図形的応用であって判読不能な重ね打ちやグリフの衝突を防ぐべく何らかのレンダリング上の調整 (default stackingside-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

[123] 指針として、 伝統的な typographic な挙動により nonspacing mark の既定の配置を上書きする場合があります。 >>115 P4

[136] 指針として、 Soft_Dotted 特性文字nonspacing mark above (ccc = 230結合文字) が適用されるとき、 基底文字に元々有るは、 表示しません。 >>115 P9

[137] ij の類が該当します。 この上にダイアクリティカルマークが来る時、 のかわりにダイアクリティカルマークを書きます。 リトアニア語のようにダイアクリティカルマークの両方を書く言語では、 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 variadialytika oxia の組み合わせの異体字です。 U+0308 COMBINING DIAERESIS, U+0300 COMBINING GRAVE ACCENT, U+0301 COMBINING ACUTE ACCENT と混じると通常の stacking rule では結果が信頼できない (cannot be reliably formed) ために別の文字として追加されたといいます。 >>164

[183] 理由が「表現できない」ではなく「信用できない」であるところにを感じます...

二重ダイアクリティカルマーク

[170] 二重ダイアクリティカルマーク結合文字は、 2つの基底文字の上や下に表示されますが、 1つ目の基底文字の後に続く結合文字として使います。

[131] 指針として、 二重ダイアクリティカルマークnonspacing mark は、 書記素基底適用しますが、 次の書記素基底も包むようなグリフとしてレンダリングされることが意図されています。 >>115 P7

[133] 指針として、 二重ダイアクリティカルマークnonspacing mark は、 書記素基底の上下に積んだ通常の nonspacing mark の最外側に「浮動」します。 >>115 P8, >>164 (surrounding diacritics は除きます。 >>164)

[135] ただ enclosing mark二重ダイアクリティカルマークとの図形的な相互作用は十分に定義されておらず、 多くのフォントレンダリング処理はこれを適切に扱えないかもしれません。 従って両者を同じ書記素クラスターに含めることは推奨されません (not recommended) >>115 P8

[134] 二重ダイアクリティカルマークnonspacing mark結合クラスは非常に高く設定されているので、 正準順序では結合文字列の最後の方に現れます。 >>115 P8, >>164

[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 たる文字があります。

結合文字の前後連結

[176] 結合文字として傍線を表す文字があります。

[177] これらは左右と接続されることが想定され、 組み合わせて使うことで文字列の上や下の連続線となります。 他の結合文字との相互作用や、 字間アキその他の扱いのことがありますから、 こうした文字によって下線上線を引くのは非推奨 (discouraged) で、 スタイル指定を使う (styling text) のがよいとされています。 >>164

[180] 実質的にこの4文字の利用は非推奨ということでしょうか。

[179] 縦書き時の扱いは特に規定されておらず、注意が必要となります。 縦書き字形組み合わせて使う文字


[184] 二重ダイアクリティカルマークを分割した結合文字である combining half marks もあります。 これらは互換性文字で、 二重ダイアクリティカルマーク好ましい (preferred) とされます。 >>164

レンダリング

[148] 任意の結合文字は任意の基底文字適用できます (>>85) が、 実装はすべての組合せを等しく良く対応する必要はありません。 >>85

[189] 基底文字 + 結合文字の組み合わせという仕組みから、 文字の図形も合成で表示できそうな気がしますが、 現実には組み合わせごとに調整しなければ実用できる品質にはなりません。

[243] 例えば「A」と「a」の上部にアクセント記号を付け加えることを考えると、 汎用アクセント字形を単純に重ね合わせるだけでは美しくならないことがわかります。

[242] 大抵のフォントは、 一般的に用いられる組み合わせのグリフを予め用意しています。 これが結合文字列の表示方法の1つです >>185グリフ全体を別途用意しなくても、 基底文字のどの位置に結合文字を配置するかの情報があれば足りることもあります >>185。 こうした手法の実現には フォントligaturekerning のような技術が使われることがあります >>185

[190] ですが、任意の組み合わせが許されている以上、 あらゆる組み合わせを想定したフォントを用意することは不可能です。 用意された組み合わせはフォントによっても異なります。 従って文字のレンダリングの実装は、 用意されていない組み合わせも何らかの形で扱える仕組みを持っていなければなりません (>>244)。


[194] 基底文字結合文字の関係は、 書字方向とは関係しません。 結合文字表示上の左側の文字に適用されるのではなく論理順の前の文字に適用されるのです。 従って右横書きでは左側の文字ではなく右側の文字に適用されることになります >>185

[152] インド系文字母音記号結合文字には、 子音文字子音クラスターの左側にレンダリングされるものもあります。 左横書きで左から右に文字を並べ、 基底文字の後に結合文字を置く順序であっても、 基底文字が右、結合文字が左とそこだけ逆転します。 これは表示順ではなく発音順を取ったもので、 Unicode 以前の文字コード ISCII の方式に倣ったものとされます。 >>142


[202] 結合文字が組み合わさることで、 結合文字列の幅と高さは基底文字の幅と高さから変化させることがあります。 文字の配置、 字間行間の調整においては、 結合文字列の幅と高さを使って適切にレイアウトする必要が出てきます。

[203] 通常では使わないような異常な(1つ以上の)結合文字の利用によって、 上下左右の文字その他の構造に重ねて表示させる悪戯があります。 悪戯で済めば良いですが、 フィッシングなどに悪用できないとも限りません。 文字のセキュリティー

非前進マーク

[32] 非前進マーク表現 (presentation) 上の位置は基底文字に依存します。 通常はそれ自体に関して visual baseline に対して間隔を消費しません。 >>30

[33] ただし、非前進マークの大きさによって基底文字の表示位置が影響されることはあります。 >>30

[34] 例えば U+20DD COMBINING ENCLOSING CIRCLE を使うと (それ自体が独立して表示幅を取ることはありませんが) その前の基底文字の周りに円を描画して、かつ前後の文字と表示が重ならないよう、 基底文字の表示位置が通常と変化することになります。

[195] 字間の調整は、 基底文字結合文字の間で行うべきではありません >>185。 原則書記素クラスターの間で行うべきものでしょう (が、二重ダイアクリティカルマークなど注意が必要なケースがあります)。

囲み結合マーク

[149] combining enclosing mark は、 記号 (symbol) を表現する文字に使うのに留めるのがいいです (best to limit) >>142

[155] その理由は、 文字特性の不一致が起こることでの驚きを抑えられることとされています。 >>142

[236] 例えば U+0021 EXCLAMATION MARKU+20E4 COMBINING ENCLOSING UPWARD POINTING TRIANGLE警告マークを表せますが、 !句読点であるが故に改行について通常の記号とは異なる挙動を示します。

[237] 故に U+26A0 WARNING SIGN は別に単独の記号として用意されており、 正規化による分解もされません。 >>153

[238] その他一般に合成済の囲み文字互換分解はあっても正準分解はされません。 これは特性の不一致が理由とされます >>164
[239] その種の特性は本来書記素クラスターに対して適切に設定されるべきだったのでしょう。 これは仕様の欠陥と言えますが、後方互換性のため今更修正するわけにもいかないのでしょう。

[154] Vertical_Orientation書記素クラスターに対して定義され、 Me の場合だけ書記素基底のものではなく固定値が割り当てられます。 Vertical_Orientation

[240] このような扱いなのは Vertical_Orientation が比較的新しい特性であることと関係するのでしょう。

[140] 古い実装は、 Indic consonant conjunct や、 combining grapheme joiner で連結された書記素クラスター群全体に対して enclosing combing mark で囲んでいました。 そうした手法には数々の問題があるので、 推奨されません (not recommended) >>115

[201] なぜか非推奨であって禁止はされていないようです。 相互運用性は低そうです。

[200] 非推奨とするだけで、 代替手段は用意されていないようです。

前進マーク

[41] 前進マークは一般に基底文字とそう違わない挙動を示します。 >>39

[42] しかし U+0BCA TAMIL VOWEL SIGN O のように、 (囲みマークでないにも関わらず) 基底文字の両側にレンダリングされるものもあります。 >>39

フォント情報に基づく結合文字列のレンダリング

[216] GSUB, cmap

[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 は、 マークグリフ (mark glyph) を表します。

[221] グリフにおけるマークグリフ文字における結合文字 (結合マーク) に近い概念です。 マークグリフは単体で使うことが想定されず、 基底グリフまたは合字グリフと組み合わせて使います。

[222] マークグリフ基底グリフ合字グリフと組み合わせるには、 基底グリフ合字グリフの表すグリフの形状や、 他のマークグリフの形状が関係してきます。 フォントの設計者は関係グリフの相互関係を記述しなければなりません。 OpenType フォントではその情報を GPOS に格納できます。 グリフ位置決定

[246] マークグリフであるかどうかはフォントGDEF で指定でき、 結合文字グリフマークグリフでなく基底グリフとすることも可能です。 これがどのような意味を持つのか (同じフォントGPOS 等からの参照以外に影響があるのか) は十分明らかではありません。

[247] 例えば結合文字グリフ基底グリフとすることで、 グリフの表示や文字列の選択の挙動を基底文字であるかのように変更できるでしょうか。 少なくても WindowsChromeFirefox では、 文字列の選択の単位や (kern がないときの) 結合文字グリフの描画位置について、 GDEF の指定は効果がないように見えます。

[255] >>247 GDEF によりマークグリフとして指定されると、 横書きなら横方向、 縦書きなら縦方向の現在位置の進行が0とみなされます。 後続のグリフの描画位置に影響するのはもちろん、 文字列の選択の範囲にも影響します。

[257] >>247 GDEF で指定がないときの既定値が違うのか、 U+3099 だと進行しない、 U+16FF1 だと進行するのが何も指定しないときの挙動で、 GDEF で挙動を切り替えられます。


[249] WindowsChromeFirefox では、 専用グリフの有無に関わらず、結合列 (なのか書記素クラスターなのかその他なのか、詳細は要検証) は文字列の選択において1単位として扱われます。

[250] WindowsChromeFirefox では、 GPOS があれば、 結合文字グリフの配置もそれに従うようになります。 それがない場合には、 結合文字グリフを (結合文字X軸の絶対値は無視して) 基底文字上の左右中央に揃えて配置します。

[251] 縦書きのとき、 WindowsChromeFirefox も、 GPOS があれば結合文字を下隣に、高さ方向の現在位置を移動させずに配置します。 GPOS がなければ結合文字を右上に、高さ方向の現在位置を移動させずに配置します。

[253] なぜ右隣でも上隣でもなく右上なのか謎です。 本来ならフォントに情報がないときに最も好ましい挙動は、 書記素クラスターだけ縦中横レンダリングすることで横書き時と同じ表示にすることでしょうか。 濁点U+16FF0 が典型例でしょうが、 下に置くより右に置く方が遥かにマシな表示になるはずです。

[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

[193] nonspacing mark零幅の文字で、現在位置より左側に描画する、 という考え方が採られてきました。 この戦略は左横書きの場合にはそのままでうまくいきますが、 他に右横書き上縦書き下縦書きの場合も想定する必要があります。

[16] 結合文字孤立結合文字である場合や、図形的結合 (graphical combination) を行えない場合には、 図形的結合なしに、基底文字であるかのように表示して構いません。 >>9 未対応の組み合わせの実装戦略 Show Hidden は、 基底文字結合文字をそれぞれ独立した単位として配置し、 結合文字には Unicode 符号表のように点線円を表示するといったものです >>185

[191] 別々に表示されるとしても単独の書記素クラスターとして、 1文字表示のときと同じようにカーソル移動するべきかもしれません。 禁則処理にも注意が必要となります。 また左横書き以外に右横書き上縦書き下縦書きの場合も想定する必要があります。
[205] 点線の円は U+25CC DOTTED CIRCLE () として用意されています。 これを基底文字とすることで、 符号表の字形を再現できます (少なくても理屈の上では)。

IDS との関係は IDC

[248] 条件が複雑なので正確な挙動かどうかわかりませんが、 WindowsChrome基底文字結合文字が同じフォント内にないと次のフォント候補を探しWindowsFirefox基底文字結合文字が別のフォントにあっても同じ位置に重ねるように見えます。 (GPOS との絡みは要検証, 基底文字側フォントの GPOS の有無は影響しなそう。)

[258] WindowsChrome だと結合文字に明示的に対応したグリフがないとき (GPOS がないとき??) に結合文字の通常の配置に合わせて(?)基底文字の上方にずらして結合文字グリフを置くような未対応フォント向け制御も反映されているようです。

欠陥結合文字列のレンダリング

[192] 欠陥結合文字列は、 U+00A0 NO-BREAK SPACE基底文字であるかのようにレンダリングするべき (should) です。 >>185

[196] とされますが、 実際には必ずしもそう実装されてはいないようです。 零幅で、 直前の余白や他の構造に被さって表示されたりします。

[197] 欠陥結合文字列のうち、 ZWJ, ZWNJ のみから構成されるものは、 零幅レンダリングされるべきものであるはずです。 またカーソル移動なども直後の基底文字と一体的に扱うべきかと思われます。

[245] >>16 も参照。

応用と結合文字

[223] Unicode文字列としては基底文字とその後の0個以上結合文字は連続していなければなりません。 しかし応用によってはソースコード上の文字列と表示される文字列とが違っていて、 基底文字結合文字の関係性に変化が生じることがあります (例えば >>96)。 また、文字列とは別に与えられたフォント指定等で基底文字結合文字の関係性に変化が加えられることがあります。

[218] OpenType 的にはフォントが違うと別の連なりに属するということになっています。 連なり もし基底文字結合文字で (または結合文字と別の結合文字で) 異なるフォントが指定されるとすると、 その両者は本来想定される「合成」状態で表示し得ないことになります。

[226] Unicode用字系特性値

データ形式と結合文字

[95] テキスト系のデータ形式 (マーク付け言語) と結合文字の関係は、 テキストファイルとしての表示や編集を考慮する時、 やや複雑になります。

[96] 例えば HTMLタグの直後に結合文字が来ると、 テキストファイルとして見た時タグの最後の >結合文字が合成されて表示されてしまいます。

[98] 文字参照エスケープのような機能を使うと、 結合文字を直接入力しづらいときでも、 代替表現で容易に指定できます。

[97] 完全正規化済はこうした不思議な挙動を避けることを求めたものでしたが、 普及しませんでした。

CSS と結合文字

[94] CSS結合文字の扱いは仕様書上は必ずしも明らかではありません。 例えば基底文字結合文字が連続する別の要素に属する時でも合成されて表示されるべきかどうか、 両方の要素特性 (例えば 'color') が違うときどう表示されるべきか、 明確ではありません。

[93] ::first-letter は最初の文字の後に結合文字があれば、 それも含みます。 CSS2 仕様書には結合文字だけ子要素に入っている場合であっても、 そこまで含まれるという実例が示されていました。 CSS2 の改訂である Selectors 3、 その改訂である CSS Pseudo-Elements Module Level 4 ではなぜかその実例はなくなっています。 ::first-letter

[90] html - Highlighting Combining Characters - Stack Overflow, https://stackoverflow.com/questions/26407896/highlighting-combining-characters

[91] 書字方向結合文字処理などを経た grapheme cluster を対象に挙動が定義されています。 CSS Writing Modes

正規化

正準等価性

セキュリティー

文字のセキュリティー

関連

[68] 前置式の subtending mark もあります。

[199] IDS との相互作用は謎です。 IDS

歴史

[224] 分合活字

[35] 現在の Unicode 式の結合文字以前には、 文字コードレベルで文字合成を行う手法として、 次のものがありました。

[227] JIS X 0207 にも何かあったらしい。

[84] どうして Unicode は後置型を採用したのでしょう。 文字列を前から走査して grapheme cluster を見つけていくには前置型の方が都合がいい気もしますが。

[241] 基底文字レンダリングして、その前後にダイアクリティカルマークを付加していく、という方式なら後置型の方が都合がよかったのかもしれません。

ISO/IEC 10646

[107] ISO/IEC 10646文字集合として Unicode と同じであるだけでなく結合文字の扱いも一致しています。 ただし UnicodeISO/IEC 10646 とでは用語法に若干の違いが見られます。

[2]

結合文字 (combining character)
この規格群で規定する符号化文字集合の識別された部分集合の構成単位であって、先行する非結合文字 (以下、基底文字という。) と組み合わせることを意図したもの、又は基底文字の後に結合文字の列が続いた形のものと組み合わせることを意図したもの (4.14 参照)。 (JIS X 0221‐1:2001 4.12)

[1] 2002-11-03 (日) 15:52 名無しさん: 結合文字は結合文字の typo じゃないかと一瞬思いますが、規格を良く読むとこれで正しいことが分かります。

[28]

合成列 (composite sequence)
基底文字とそれに続く一つ以上の結合文字からなる図形文字の列 (4.11 参照)。

備考 1. 合成列からなる図形記号は、通常、 その合成列を構成する各文字の図形記号の組合せからなる。

2. 合成列は、文字とはみなさない。したがって、 この規格群のレパートリの構成単位ではない。 (JIS X 0221‐1:2001 4.14)

[108] 合成列結合文字列と同じようなものですが、 基底文字が必須で、 ZWJZWNJ は含まれません。


[104] ISO/IEC 2022 にも合成に関する規定があります。 合成手法として、 重ね打ち式文字合成Unicode結合文字GCC が示されています。

[4]

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

[8]

結合文字 (combining character)
符号化文字集合の識別された部分集合の構成単位であって、先行する非結合文字 (以下、基底文字という。) と組み合わせることを意図したもの、又は基底文字の後に結合文字の列が続いた形のものと組み合わせることを意図したもの。 (JIS X 0202:1998 4.8)

[105] ISO/IEC 2022 の体系で使われる ISO-IR に登録された図形文字集合では実はなぜかここに挙げられていない非spacing文字 (前置アクセント型) 方式の文字合成が一番よく使われているのではないかと思われます。

[106] Unicode 型の結合文字を使った ISO-IR に登録された図形文字集合はどれだけあるのでしょうか。 JIS X 0213:2000JIS X 0213:2004 が思い浮かびますが、 他にもあるのでしょうか。


[3] 10646 での結合文字の使い方は、 24. に規定があります。結合文字の一覧は附属書 B にあります。結合文字が使えるかどうかは実装水準と関係します。

  • 結合文字は、基底文字の後でなければなりません。 (24.1)
  • 結合文字自体を一つの結合列としたい時は、 間隔を基底文字とします。 (24.1)
    • インド系用字系の matra (母音記号) は特殊で、周囲の複数の文字に依存するので、 間隔と結合させるのは望ましくありません。 (24.1 備考)
  • 一つの基底文字に結合できる結合文字の数は 10646 では規定しません。 (24.3)
  • 結合文字同士が表示に影響する場合 (例えば COMBINING MACRONCOMBINING DIAERESIS) は、だんだん外側に (MACRON より DIAERESIS を上に) 配置していきます。
  • 縦方向ではなく横方向に並べたり、 隣接する結合文字と合字を作る結合文字もある。 横方向に進むときは、書字方向に従う。
  • 結合文字同士が影響を与えない場合 (例えば上につくものと下につくもの) は、 逆の順序の場合と同じに見えてもよい。

[147] 当初の ISO/IEC 10646 は、 実装水準を3つに区別していました。 その違いは主に結合文字の利用の可否でした。 ISO/IEC 10646 現在はこの区分は廃止されました。実情にまったく即していなかったためでしょう。

JIS X 0208 と LARGE CIRCLE

LARGE CIRCLE

JIS X 0213

[70] JIS X 0213:2000 は、 重ね打ち式文字合成を禁止する JIS X 0208:1997 の規定を引き継ぎました。 かわりに新方式の文字合成の規定を持っていました。

[51] JIS X 0213:2000 6.5.2

4) ダイアクリティカルマーク (合成可能) ダイアクリティカルマーク (合成可能) 32文字の名前及 びビット組合せは, 附属書4表4による。

備考 文字合成を実装する場合には, 合成を行う際に, ダイアクリティカルマーク (合成可能) を, 現在位置の前進を伴わない文字として用いることができる。なお, ダイアクリティカルマーク を用いた文字の合成を想定する場合は, 文字合成の実装の有無にかかわらず, ダイアクリティ カルマーク (合成可能) を使用することを推奨する。

[71] 文字の合成を想定する場合であって、 文字合成の実装が無い場合とは、 どういう場合なのでしょうか? よくわかりません。 文字合成の実装が無いのにダイアクリティカルマーク (合成可能) を適切に使用することができるものでしょうか。

[27] 文字合成を実装しない場合には、これらの文字は使えるのでしょうか。 使った場合どう扱われるのでしょうか。

[102] 「合成可能」という表現と「文字合成を実装する場合」 という規定は、 合成する場合としない場合が両方存在し得ることを意味しているようですが、 両者はどう区別されるのでしょうか。 JIS X 0213 を使ったテキストファイルを受信した時、 それがどちらであるかは決定できるのでしょうか。

[52] JIS X 0213:2000

8. 合成文字の取扱い この規格で規定する符号化文字集合中のすべての図形文字は, 別に規定するもの を除き, 現在位置の前進動作を伴う文字とする。 文字合成を実装する場合は, ダイアクリティカルマーク (合 成可能) は, 現在位置の前進を伴わない文字として用いてもよい。

[72] 現在位置の前進を伴わない文字がどのようなもので、 どう利用するものかは、 JIS X 0213 には書いてありません。 これは規格として成り立っているのでしょうか?

[73] 既存の ISO文字コードには現在位置の前進を伴わない文字 (非spacing文字) を定めたものがいくつかありますが、 それらは前置アクセント方式を採用しています。 現在位置の前進を伴わない文字 ところが JIS X 0213 が定めるダイアクリティカルマーク (合成可能) の文字の名前と一致する ISO/IEC 10646文字は、 後置アクセント方式で使う結合文字です。 基底文字を先に書くか後に書くか、 どちらの解釈もあり得ます。

[74] JIS X 0213:2000 附属書7

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 は誰もつかっていないようなので、 今後の改正でこうした謎が明かされる可能性も低そうです。

JIS X 4051

[59] 結合文字の処理は、 1つの基底文字と、 それに続くすべての連続する結合文字で構成される、 合成列を処理するものです。 >>58 基底文字は、 結合文字に先行する非結合文字です >>66 22)結合文字は、 基底文字の直後に続き、基底文字または既に合成した合成列と組み合わせることを意図した図形文字です >>66 45)合成列は、 基底文字とそれに続く1つ以上結合文字とからなる図形文字の列です >>66 47)

[61] 合成列に対応する字形が用意されているばあい、 それを使います。 そうでない場合、 合成します。 >>58

[62] 合成は、 記述された結合文字の順に、 JIS X 0221 に従い、 結合文字の位置属性に従い、基底文字または既に合成した合成列の上、 下、 右上、 左下などに配置します。 >>58 (従って同じ位置に複数の結合文字があれば、 だんだん外側へと付け足されていきます。)

[63] 結合文字は、基底文字の大きさに合わせて配置するべきです。 >>58 (例えば上に配置するとき、 e よりも E のときの方が高く配置します。)

[65] ij の上に結合文字を配置するときは、 基底文字を削除するべきです。 >>58

[64] 基底文字斜体のとき、 斜めになった基底文字の縦軸に合わせて結合文字の位置をずらすべきです。 >>58

[67] 結合文字文字クラス欧文間隔以外の欧文用文字とされます。 >>58 結合文字文字クラスをこのように定めて正しく処理できるのかどうか不明です。 合成列文字クラスではないのでしょうか。 基底文字欧文間隔以外の欧文用文字のときはいいですが、 そうでないときもこの扱いでいいのでしょうか。 (おそらく想定外なのでしょうが、そのように書かれてはいません。)

[60] 結合文字とは別に、囲み文字の規定もあります。

[79] (UnicodeOpenType ではなく) この 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