[18] 文字を小さな構造の組合せで表現しようという試みは古今東西にいろいろあります。
[9] 書体讃歌(復帰しました)さんはTwitterを使っています: 「ちなみのモリサワの外字用プレートには「𩵋」タイプの魚へんが分合活字のようにパーツとして標準搭載されており、魚系の漢字で作字できるようになっていました。 「ネタは大きいほうがいい」と縁起担ぎした関西の特徴でしょうか……☺️ https://t.co/4xEaO6N4dW」 / X, , https://twitter.com/typeface_anthem/status/1685647758894694400
[13] Xユーザーの書体讃歌さん: 「読めないけど、どうやら韓国の電算でもパーツを合わせて合成造字するシステムがあったみたい...... 本来の意味での〈作字〉だあぁぁ!! https://t.co/B9Qchi4Ofl」 / X, , https://twitter.com/typeface_anthem/status/1786741083214610506
[35] 文字コードレベルで文字合成を行う手法はいろいろあります。
BS や CR をつかった重ね打ち
GCC[15] アジア諸国の実用や欧米の研究者の研究目的で一時期広く使われた各種のフォント依存符号化は、 文字を文字素や見た目の類似部分など各種の基準で分割して収録し、 前後の文字を同じ位置に重ね合わせるようなフォントとすることで合成していました。 前置非spacing文字型が多いようですが、 後置結合文字型もあるようで、 どちらにも当てはまらない複雑なものもあるようです。
[227] JIS X 0207 にも何かあったらしい。
[276] Windows-1258 には後置型結合文字があります。
[84] どうして Unicode は後置型を採用したのでしょう。 文字列を前から走査して grapheme cluster を見つけていくには前置型の方が都合がいい気もしますが。
[241] 基底文字をレンダリングして、その前後にダイアクリティカルマークを付加していく、という方式なら後置型の方が都合がよかったのかもしれません。
[6] wg2-n937.pdf, , http://www.unicode.org/L2/Historical/wg2-n937.pdf
[7] >>6 これ29区から46区の01から59って変な範囲だけど942集合なのだろうか?
[11] IRGN2578OrganicChemical.pdf, , https://appsrv.cse.cuhk.edu.hk/~irg/irg/irg59/IRGN2578OrganicChemical.pdf
[12] Feedback on IRGN2578 ``Comments on encoding early Chinese organic chemical character in WS2021 and other complex ideographs" - IRGN2578JunliangFeedback.pdf, , https://appsrv.cse.cuhk.edu.hk/~irg/irg/irg60/IRGN2578JunliangFeedback.pdf
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 の規定に基づく実装があるのかどうかは不明です。
[4] 今だったら小さい文字集合 (教育漢字くらいの規模) のグリフデータと既存の大きな OSS フォント (の文字の骨組み) を使って AI で残りのグリフを補完して独自のフォントを生成するようなやつ、 実用的なレベルで作れるのではないのかねえ?
[5] 例えば教育漢字の丸ゴシックを作って IPAmj明朝と一緒に入力したら文字情報基盤全部の丸ゴシックフォントが出てくるみたいなシステムがあったらすんごい嬉しくない?
[14] Xユーザーの4b³さん: 「Windows付属繁体字フォントの標楷體、全漢字が1画ずつのグリフを引用してTrueType命令で変形させてできているらしい…と以前(多分Twitterで)読んだけど、実際覗いてみるとちょっとやそっとの変形ではなく例えば「匹」の3・4画目が同じコンポーネント(黒線が変形前)でできている… https://t.co/N3BSsH67SK」 / X, , https://x.com/fourbthree/status/1191359446020055040
[16] TrueTypeヒンティングを利用した筆画ベースフォントについて - にせねこメモ, https://nixeneko.hatenablog.com/entry/2024/07/02/000000