[1] [DFN[complex script(s)]] は、 [[Unicode]] や [[OpenType]] にとって複雑な処理を必要とする[[用字系]]です。 [4] [[アラビア文字]]、[[インド系文字]]などが該当するようです。 [5] 使ってる当事者がどう思ってるのかは知りませんが、 欧米の[[IT技術者]]は複雑だと思って[[この名前で呼んでいる][欧米中心主義]]のではないでしょうか。 [6] [[Unicode]] [[アーキテクチャー]]に基づく[[計算機処理]]の観点の複雑さをみているので、 [[文字]]として、[[言語]]としての複雑さや[[ネイティブ]]の認知の「複雑」さとは必ずしも一致していません。 例えば[[日本人]]は[[仮名]]が単純、[[漢字]]を複雑と思っている人が多そうですが、 [[complex script]] に [[CJK]] は含まれていなそうです。 [7] [[現代ハングル]]も [[complex script]] には含まれていないようなのですが、 [[古ハングル]]は [[complex script]] の実装である [[Uniscribe]] の対象に入っています。 [[Unicode]] では[[現代ハングル]]に1音節1[[符号位置]]が与えられていて[[文字のレンダリング]]は[[文字コード]]に対応する[[フォント]]の[[グリフ]]をただ表示するだけで簡単なのですが、 [[古ハングル]]は[[ハングル字母]]ごとの[[符号位置]]の組み合わせで1音節を表すしかないので、 比較的複雑な処理になります。 この差は[[文字]]の性質の違いでは説明できなくて、 [[Unicode]] の構造から生じたものでしかありません。 [10] [[漢字]]も[[部分字形]]の[[合成]]で表現する技術 ([[デジタル]]版[[分合活字]]) は未だに実用化されていない (というか見込みがなく諦めてしまった) のですが、そちらが採用されていた[[世界線]]では紛うことなき [[complex script]] のはず。 [13] 実は[[ラテン文字]]にも複雑な処理を必要とするものがあるのですが、 なぜか[[基底文字]]と[[結合文字]]の組み合わせではなく合成済み文字として [[Unicode]] に追加されているので、 「complex」ではないことになっています。 [SEE[ [[ラテン文字]] ]] [20] 経済的植民地主義の視点からの批判: - [21] 本来はただの別の書記体系であって、劣っているわけでも特殊でもない。 - [22] しかし技術仕様を支配した側(欧米IT産業)が、自分たちにとって理解しやすい形を「シンプル」とし、それに適合しないものを「複雑」「特殊」「legacy」と呼んでしまう。 - [23] これはまさに、 --[25] 近代植民地主義が現地の言語や文化を「未発達」「原始的」と決めつけ、 --[24] 自国の制度や基準を「普遍的」「先進的」として押し付けた構図と同じ。 - [26] 欧米人にとって理解・実装しやすい文字(ラテン、ギリシャ、キリル)を標準・シンプルとみなし、 それに比べて多層的な母音記号や複合子音を持つ文字を「複雑」と呼ぶのは、すでに価値基準が偏っている。 [27] こういう問題があるので、 [[complex script]] という用語、分類法それ自体が偏見に満ち差別的であるともいわれます。 [28] ただ事実として今や [[Unicode]] と [[OpenType]] は世界中で不可避な技術基盤で、 [[Unicode]] と [[OpenType]] に於いて難しい、 複雑であることはもはや一般の技術者にはどうしようもないので、 複雑 (complex) と表現するしかないつらみはあります。 [3] 利用例: - [2] [CITE@ja-jp[OpenType development (LEGACY INFORMATION) - Typography | [[Microsoft]] Docs]], [[nihar]], [TIME[2022-08-27T07:27:20.000Z]] -[8] [CITE@ja-jp[OpenType glyph processing (part 1) - Typography | [[Microsoft]] Docs]], [[alib-ms]], [TIME[2022-08-27T07:55:01.000Z]] [9] [CITE[23107-terminal-suppt.pdf]], [TIME[2023-04-24T14:18:11.000Z]], [TIME[2023-06-16T10:53:15.493Z]] [11] [CITE[What Is Complex Text?]], [TIME[2023-08-05T13:50:28.000Z]], [TIME[2002-02-13T05:31:50.369Z]] complex text [12] [CITE@ja[IRGN2578OrganicChemical.pdf]], [TIME[2022-10-13T22:40:25.000Z]], [TIME[2024-04-27T08:18:42.698Z]] complex script vs simple script [14] [CITE@ja-jp[GPOS — Glyph Positioning Table (OpenType 1.9.1) - Typography | Microsoft Learn]], [[PeterCon]], [TIME[2024-05-31T17:42:24.000Z]], [TIME[2024-12-04T07:57:52.173Z]] [15] >>14 には[[越南語]]で使う[[ラテン文字]]の[[ダイアクリティカルマーク]]の配置が complex glyph positioning の事例として紹介されています。これが実現する前に比べれば complex ですが、 いわゆる complex script に比べるとずっと単純なものです。 [16] まあ >>15 の場合実際比較的 complex であるのは確かですし、 complex なのは glyph positioning という技術であって script には言及していないので、 >>15 のような表現は[[政治的正しさ]]的にも無問題なんですよね。 [17] [CITE@fr[ réputé nuisible]], [TIME[2025-06-16T14:25:10.000Z]], [TIME[1999-02-21T10:58:46.044Z]] Écritures complexes, écriture complexe [18] >>17 平成11年には既にこの概念が使われていた。[[中国語]]も他バイトだけど複雑ではない。 複雑なのは[[アラビア文字]]や[[インド系文字]]。 -*-*- [29] [[南アジア]]などでは[[Unicode]]普及前は素朴な[[8ビット符号]]などを使っていました。 [[Unicode]] / [[OpenType]] の概念でいえば[[グリフ]]の列に近い存在です。 そのためそれらから [[Unicode]] への[[変換][文字コードの変換]]は、 いわば [[Unicode文字]]から[[グリフ]]への変換 (= [[Unicode]] / [[OpenType]] の世界でいう complex な処理) の逆変換のようになるため、 かなり「複雑」な処理になってしまいます。 [19] 関連: [CODE[.map]] -*-*- [30] 関連: [[インド系文字の文字コード]], [[ビルマ文字の文字コード]]