[2] かつては、タイプライター時代のような重ね打ちで基底文字とアクセントなどの組み合わせを表現できると (理論上) されていました。
[14]
制御文字 BACKSPACE
(後退) や
CR
(復帰)
を使用することで、2文字以上の図形文字を同じ文字位置に
重ねて表示することが出来ます。 (重ね打ちといいます。
タイプライタに由来します。) たとえば "/" (SOLIDUS)
と "=" (EQUALS SIGN) を組み合わせることで、 "≠"
(NOT EQUALS SIGN) を表示出来ます。組み合わせられた合成文字は
一つのCCデータ要素として扱われます。
[10] ISO/IEC 646 や JIS X 0201 に、 そのような合成が可能であるとの規定があります。 ただし出来るという事実や用法、 いくつかの例示はありますが、 肝心のどのようなビット組合せ列によってそれを行うかは規定されていません。 どのような文字の記述が可能であるかの範囲 (文字レパートリー) も規定されていません。 これらは応用が定めることとされています。
[18]
例えば「≠」は
=
BS
/
とも
/
BS
=
とも表し得ます。
それ以外にも、
CR
や SP
を自由に使えるなら無限の可能性が現れます。
また
「≠≠」
は
=
=
BS
BS
/
/
とも表し得ます。
[1] JIS X 0201 における合成文字 JIS X 0201:1997 7.
BACKSPACE
や CARRIAGE RETURN
を使用して2文字以上の図形文字を同じ文字位置に重ねて表示できる。SOLIDUS
と
EQUAL SIGN
で
≠
を表示できる。LOW LINE
や
OVER LINE
は単独でも使用できるし、
アンダライン付きや
オーバライン付きの文字を表示させることもできる。
QUOTATION MARK
,
APOSTROPHE
,
COMMA
,
CIRCUMFLEX ACCENT
,
GRAVE ACCENT
はそれぞれ
アクサンテギュ付き、
ウムラウト付き、
セディユ付き、
アクサンシルコンフレックス付き、
アクサングラーブ付きの文字を合成するのに使用できる。
[17] 一般に合成文字を含むデータを情報交換する場合には、 あらかじめ送受信者間で合成文字の種類及び合成方法に関する 合意が必要です。開放型環境での情報交換を確実にするために、 合成文字は使用しないほうが良いとされています。
[19] ISO/IEC 646 IRV や JIS X 0201 は、 C0文字集合として ISO/IEC 6429 C0 を使っています。 従って制御機能の用法には ISO/IEC 6429 の規定も適用されます。
[33] JIS X 0202:1998 6.3.3
には、
このような合成の方法が存在するという程度の言及がありました。
(他には Unicode 型の結合文字の方法と、
GCC
が言及されていました。)
[34] NS39012siba, , http://web.archive.org/web/20000903220115/http://www.itscj.ipsj.or.jp/jp/ns39012.html
また,646での文字合成は,一意に決まらず,例えば,“a”にアキュートアクセントを付けようとすると,“a”の直後にBACKSPACE,そして,アキュートアクセントで表現するだけではなく,CARRIAGE RETURNと複数個のSPACE,そして,アキュートアクセントなど幾つもの表現ができる.この合成の曖昧さは,符号化文字集合の満たすべき基本性質である一意な符号化に反する.
[22] 合成図形文字は、 formator function のみを使って得られなければなりません。 editor function をその目的に使ってはなりません。 >>21
[6] 合成図形文字は書式機能だけを使用して作る。 編集機能は、この目的に使用してはならない。 (JISX0211-1994 6.4.2)
[8] 重ね打ち型の合成方法はタイプライタの時代からのものです。 しかし、同じ図形記号の表現に BS や CR を自由自在に 組み合わせた無限の方法が存在し得るのですから、 表示以外の処理には向きません。実際この方法を使っているのは タイプライタと端末装置くらいでしょう。
[4] 従ってこの合成方法は現在では推奨されず、 代わりに結合文字を使う方法が採られています。 そこに至るまでにもいろいろな手法が使われました。
[31] ISO/IEC 6429
は、
重ね打ちによる文字合成に使う
BS
などの制御機能と、
また別の文字合成法である制御機能の
GCC
を定めていました。
[25]
複数の図形文字を組合せて1つの図形記号として表示したいときは、
重ね打ちではなく
GCC
を使うべきです。
>>24 (参考)
[35]
Mule内部コードは内部処理用に最適化された完全独自の文字コード体系でしたが、
その合成文字の表現は、
構造的には
GCC
に近いものだったようです。
[9]
ISO/IEC 4873 附属書C (参考) は、
ISO/IEC 646
の定めるような
BS
や
CR
による合成は、
図形文字レパートリを未定義とするものであって、
送受信者間の合意が必要となるところ、
そのような要件はなかなか満たされないものであるとして、
こうした合成を禁止していました。
>>26
[29]
なおその前の ECMA-43 第2版は、
GCC
には言及がなく、
かわりに
BS
などによる重ね打ちを認めており、
送受信者間の合意を要件としていました。
第3版の要件云々は、第3版だけ読んでいると理解できませんが、
第2版のこの要件を指していたようです。
[12]
CCITT 系の文字コードは、
重ね打ち式文字合成ではなく、
非spacing文字による合成をつかっていました。
[23]
ANSEL は非spacing図形文字による合成に対応しており、
重ね打ち式文字合成は使わないとしていました。
[13] ISO/IEC 8859 やそれに相当する ECMA の文字コードは、 アクセント付きのラテン文字を合成によらず、 合成済の文字に独立した符号位置を割り当てることで表現していました。
[3]
Unicode は
ISO/IEC 8859
の系統の合成済の文字を持ちつつ、
後置の結合文字を使う方式を採用しています。
[36] ISO-IR 68 は APL 用の94集合で、ビット組合せの組合せを規定していますが、 ただ並べるだけでいいのか、順序はどうなのか、説明がないのでよくわかりません。