[18] [[文字]]を[[小さな構造][書記素]]の組合せで表現しようという試みは古今東西にいろいろあります。 * 分合活字 [9] [CITE@ja[書体讃歌(復帰しました)さんはTwitterを使っています: 「ちなみのモリサワの外字用プレートには「𩵋」タイプの魚へんが分合活字のようにパーツとして標準搭載されており、魚系の漢字で作字できるようになっていました。 「ネタは大きいほうがいい」と縁起担ぎした関西の特徴でしょうか……☺️ https://t.co/4xEaO6N4dW」 / X]], [TIME[午後10:45 · 2023年7月30日][2023-07-30T13:45:18.000Z]], [TIME[2023-07-30T13:30:07.000Z]] [13] [CITE@ja[Xユーザーの書体讃歌さん: 「読めないけど、どうやら韓国の電算でもパーツを合わせて合成造字するシステムがあったみたい...... 本来の意味での〈作字〉だあぁぁ!! https://t.co/B9Qchi4Ofl」 / X]], [TIME[午後9:54 · 2024年5月4日][2024-05-04T12:54:04.000Z]], [TIME[2024-05-08T09:09:36.000Z]] [10] [CITE@ja[Xユーザーの書体讃歌さん: 「これ! このオリジナル「分合活字」がみたかった!!!!!作字のご先祖様✨😎 やはり不自然なところも所々ありますが、後年のものと比べると違和感はまだ少ないように見えます。完成度の高さゆえなのか...... https://t.co/gUx4MH1aiZ https://t.co/bxytA5U7VA」 / X]], [TIME[午後9:53 · 2024年12月21日][2024-12-21T12:53:05.000Z]], [TIME[2026-04-18T12:42:42.000Z]] * 文字を文字素の組合せで表現する文字コード技術 [35] [[文字コード]]レベルで文字合成を行う手法はいろいろあります。 - [19] [[Unicode]] 式の後置の[[結合文字]] - [36] [CODE(charname)@en[BS]] や [CODE(charname)@en[CR]] をつかった[[重ね打ち]] [SEE[ [[重ね打ち式文字合成]] ]] - [37] 前置型の[[非spacing文字]]をつかった合成 [SEE[ [[非spacing文字]] ]] - [69] [CODE(charname)@en[GCC]] - [SEE[ [[Muleの文字合成]] ]] -- [214] [[Emacs]] の[[私用制御機能]] -- [215] [[Mule内部コード]] - [20] [[subtending mark]] [21] 関連: [[文字のレンダリング]], [[合字]] [15] [[アジア]]諸国の実用や[[欧米]]の研究者の研究目的で一時期広く使われた各種の[[フォント依存符号化]]は、 [[文字]]を[[文字素]]や見た目の類似部分など各種の基準で分割して収録し、 前後の[[文字]]を同じ位置に重ね合わせるような[[フォント]]とすることで合成していました。 前置[[非spacing文字]]型が多いようですが、 後置[[結合文字]]型もあるようで、 どちらにも当てはまらない複雑なものもあるようです。 [227] [[JIS X 0207]] にも何かあったらしい。 [276] [[Windows-1258]] には後置型[[結合文字]]があります。 [84] どうして [[Unicode]] は後置型を採用したのでしょう。 文字列を前から走査して [[grapheme cluster]] を見つけていくには前置型の方が都合がいい気もしますが。 [241] [[基底文字]]を[[レンダリング]]して、その前後に[[ダイアクリティカルマーク]]を付加していく、という方式なら後置型の方が都合がよかったのかもしれません。 [6] [CITE[wg2-n937.pdf]], [TIME[2009-02-13T23:43:40.000Z]], [TIME[2023-07-16T14:07:12.109Z]] [7] >>6 これ29区から46区の01から59って変な範囲だけど[[94[SUP[2]]集合]]なのだろうか? [8] >>6 #page=12 は [[IDC]] の祖? [11] [CITE@ja[IRGN2578OrganicChemical.pdf]], [TIME[2022-10-13T22:40:25.000Z]], [TIME[2024-04-27T08:21:12.126Z]] [12] [CITE@ja[Feedback on IRGN2578 ``Comments on encoding early Chinese organic chemical character in WS2021 and other complex ideographs" - IRGN2578JunliangFeedback.pdf]], [TIME[2023-03-16T09:27:31.000Z]], [TIME[2024-04-27T08:35:51.304Z]] * Unicode の結合文字 [SEE[ [[結合文字]] ]] * JIS X 0208 と [CODE(charname)@en[LARGE CIRCLE]] [SEE[ [CODE(charname)@en[LARGE CIRCLE]] ]] * JIS X 0213:2000 [70] [[JIS X 0213:2000]] は、 [[重ね打ち式文字合成]]を禁止する [[JIS X 0208:1997]] の規定を引き継ぎました。 かわりに新方式の文字合成の規定を持っていました。 [FIG(quote)[ [51] [[JIS X 0213:2000]] 6.5.2 > [B[4) ダイアクリティカルマーク (合成可能)]] ダイアクリティカルマーク (合成可能) 32文字の名前及 びビット組合せは, [B[附属書4表4]]による。 > [BOX(indent)[ [B[備考]] 文字合成を実装する場合には, 合成を行う際に, ダイアクリティカルマーク (合成可能) を, 現在位置の前進を伴わない文字として用いることができる。なお, ダイアクリティカルマーク を用いた文字の合成を想定する場合は, 文字合成の実装の有無にかかわらず, ダイアクリティ カルマーク (合成可能) を使用することを推奨する。 ]BOX] ]FIG] [71] 文字の合成を想定する場合であって、 文字合成の実装が無い場合とは、 どういう場合なのでしょうか? よくわかりません。 文字合成の実装が無いのにダイアクリティカルマーク (合成可能) を適切に使用することができるものでしょうか。 [27] 文字合成を実装しない場合には、これらの文字は使えるのでしょうか。 使った場合どう扱われるのでしょうか。 [102] 「合成可能」という表現と「文字合成を実装する場合」 という規定は、 合成する場合としない場合が両方存在し得ることを意味しているようですが、 両者はどう区別されるのでしょうか。 [[JIS X 0213]] を使った[[テキストファイル]]を受信した時、 それがどちらであるかは決定できるのでしょうか。 [FIG(quote)[ [52] [[JIS X 0213:2000]] > [B[8. 合成文字の取扱い]] この規格で規定する符号化文字集合中のすべての図形文字は, 別に規定するもの を除き, 現在位置の前進動作を伴う文字とする。 [SNIP[]] 文字合成を実装する場合は, ダイアクリティカルマーク (合 成可能) は, 現在位置の前進を伴わない文字として用いてもよい。 ]FIG] [72] [[現在位置の前進を伴わない文字]]がどのようなもので、 どう利用するものかは、 [[JIS X 0213]] には書いてありません。 これは規格として成り立っているのでしょうか? [73] 既存の [[ISO文字コード]]には[[現在位置の前進を伴わない文字]] ([[非spacing文字]]) を定めたものがいくつかありますが、 それらは前置アクセント方式を採用しています。 [SEE[ [[現在位置の前進を伴わない文字]] ]] ところが [[JIS X 0213]] が定めるダイアクリティカルマーク (合成可能) の[[文字の名前]]と一致する [[ISO/IEC 10646]] の[[文字]]は、 後置アクセント方式で使う[[結合文字]]です。 [[基底文字]]を先に書くか後に書くか、 どちらの解釈もあり得ます。 [FIG(quote)[ [74] [[JIS X 0213:2000]] 附属書7 > [B[1.3.3 ダイアクリティカルマーク (合成可能)]] この規格は, 実用的な見地から, 音声記号を広く採録することとした。 音声記号では, 基本となる図形文字を合成することにより, 対象となる音声を図形文字として表現することが行わ れている。[B[JIS X 0208]]は, 図形文字の合成を禁止しているが, この規格では, 音声記号に必要な図形文字について は, 合成の許容についての規定を設けた ([B[本体8.]]参照)。 > 合成が許容される音声記号の採録に当たっては, IPAの音声記号チャートから, 音声記号としての図形文字の合 成の際に必要となる基本的なダイアクリティカルマークを選定し, それらの32の図形文字を, 現在位置の前進を伴 わない文字として利用することができるダイアクリティカルマーク (合成可能) として追加することとした。ダイ アクリティカルマーク (合成可能) の中には, [B[JIS X 0208]]で規定しているダイアクリティカルマーク, 又は, 今回 新たに追加したダイアクリティカルマークと類似するものがあるので, そのような図形文字については, それぞれ の図形文字の区別に注意する必要がある。なお, ダイアクリティカルマーク (合成可能) の例示字体は, [ASIS[ ̤][点線円、囲み四角形]] (1-11-82, COMBINING DIAERESIS BELOW, 下ダイエレシス (合成可能), かすれ音) のように, 合成対象となる図 形文字の位置を破線の丸で示しているので, これらの文字の同定の際には, 注意する必要がある。 ]FIG] [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 [REFS[ - [66] [[JIS X 4051:2004]] 3. - [58] [[JIS X 4051:2004]] 4.10 ]REFS] [59] [[結合文字]]の処理は、 1つの[[基底文字]]と、 それに続くすべての連続する[[結合文字]]で構成される、 [[合成列]]を処理するものです。 [SRC[>>58]] [[基底文字]]は、 [[結合文字]]に先行する非結合文字です [SRC[>>66 22)]]。 [DFN[結合文字]]は、 [[基底文字]]の直後に続き、[[基底文字]]または既に合成した[[合成列]]と組み合わせることを意図した[[図形文字]]です [SRC[>>66 45)]]。 [[合成列]]は、 [[基底文字]]とそれに続く1つ[[以上]]の[[結合文字]]とからなる[[図形文字]]の列です [SRC[>>66 47)]]。 [61] [[合成列]]に対応する[[字形]]が用意されているばあい、 それを使います。 そうでない場合、 [[合成]]します。 [SRC[>>58]] [62] [[合成]]は、 記述された[[結合文字]]の順に、 [[JIS X 0221]] に従い、 [[結合文字]]の位置属性に従い、[[基底文字]]または既に[[合成]]した[[合成列]]の上、 下、 右上、 左下などに配置します。 [SRC[>>58]] (従って同じ位置に複数の[[結合文字]]があれば、 だんだん外側へと付け足されていきます。) [63] [[結合文字]]は、[[基底文字]]の大きさに合わせて配置するべきです。 [SRC[>>58]] (例えば上に配置するとき、 [CODE[e]] よりも [CODE[E]] のときの方が高く配置します。) [65] [CODE[i]] や [CODE[j]] の上に[[結合文字]]を配置するときは、 [[基底文字]]の[[点]]を削除するべきです。 [SRC[>>58]] [64] [[基底文字]]が[[斜体]]のとき、 斜めになった[[基底文字]]の縦軸に合わせて[[結合文字]]の位置をずらすべきです。 [SRC[>>58]] [67] [[結合文字]]の[[文字クラス]]は[[欧文間隔以外の欧文用文字]]とされます。 [SRC[>>58]] [[結合文字]]に[[文字クラス]]をこのように定めて正しく処理できるのかどうか不明です。 [[合成列]]の[[文字クラス]]ではないのでしょうか。 [[基底文字]]が[[欧文間隔以外の欧文用文字]]のときはいいですが、 そうでないときもこの扱いでいいのでしょうか。 (おそらく想定外なのでしょうが、そのように書かれてはいません。) ;; [60] [[結合文字]]とは別に、[[囲み文字]]の規定もあります。 [79] ([[Unicode]] や [[OpenType]] ではなく) この [[JIS X 4051]] の規定に基づく実装があるのかどうかは不明です。 * OpenType [SEE[ [[マークグリフ]] ]] * 分合活字的デジタルフォント技術 [1] [CITE[[[Droid Sans Fallback]]]] [3] [[和田研フォント]], [[KAGE]] [4] 今だったら小さい[[文字集合]] ([[教育漢字]]くらいの規模) の[[グリフデータ]]と既存の大きな [[OSS]] [[フォント]] (の文字の骨組み) を使って [[AI]] で残りの[[グリフ]]を補完して独自の[[フォント]]を生成するようなやつ、 実用的なレベルで作れるのではないのかねえ? [5] 例えば[[教育漢字]]の丸ゴシックを作って [[IPAmj明朝]]と一緒に入力したら[[文字情報基盤]]全部の丸ゴシックフォントが出てくるみたいなシステムがあったらすんごい嬉しくない? [14] [CITE@ja[Xユーザーの4b³さん: 「Windows付属繁体字フォントの標楷體、全漢字が1画ずつのグリフを引用してTrueType命令で変形させてできているらしい…と以前(多分Twitterで)読んだけど、実際覗いてみるとちょっとやそっとの変形ではなく例えば「匹」の3・4画目が同じコンポーネント(黒線が変形前)でできている… https://t.co/N3BSsH67SK」 / X]], [TIME[午後11:20 · 2019年11月4日][2019-11-04T14:20:00.000Z]], [TIME[2024-08-28T07:37:55.000Z]] [16] [CITE@ja[TrueTypeヒンティングを利用した筆画ベースフォントについて - にせねこメモ]], [TIME[2024-10-24T12:49:38.000Z]] * 関連 [22] [[漢字構造記述]], [[ハングル]], [[ダイアクリティカルマーク]], [[文字のようなもの]] * メモ