分合活字

[9] 書体讃歌(復帰しました)さんはTwitterを使っています: 「ちなみのモリサワの外字用プレートには「𩵋」タイプの魚へんが分合活字のようにパーツとして標準搭載されており、魚系の漢字で作字できるようになっていました。 「ネタは大きいほうがいい」と縁起担ぎした関西の特徴でしょうか……☺️ https://t.co/4xEaO6N4dW」 / X, 午後10:45 · 2023年7月30日2023-07-30T13:45:18.000Z, 2023-07-30T13:30:07.000Z https://twitter.com/typeface_anthem/status/1685647758894694400

[13] Xユーザーの書体讃歌さん: 「読めないけど、どうやら韓国の電算でもパーツを合わせて合成造字するシステムがあったみたい...... 本来の意味での〈作字〉だあぁぁ!! https://t.co/B9Qchi4Ofl」 / X, 午後9:54 · 2024年5月4日2024-05-04T12:54:04.000Z, 2024-05-08T09:09:36.000Z https://twitter.com/typeface_anthem/status/1786741083214610506

[10] Xユーザーの書体讃歌さん: 「これ! このオリジナル「分合活字」がみたかった!!!!!作字のご先祖様✨😎 やはり不自然なところも所々ありますが、後年のものと比べると違和感はまだ少ないように見えます。完成度の高さゆえなのか...... https://t.co/gUx4MH1aiZ https://t.co/bxytA5U7VA」 / X, 午後9:53 · 2024年12月21日2024-12-21T12:53:05.000Z, 2026-04-18T12:42:42.000Z https://x.com/typeface_anthem/status/1870452431370559785/photo/1

文字を文字素の組合せで表現する文字コード技術

[35] 文字コードレベルで文字合成を行う手法はいろいろあります。

• [19] Unicode 式の後置の結合文字
• [36] BS や CR をつかった重ね打ち 重ね打ち式文字合成
• [37] 前置型の非spacing文字をつかった合成 非spacing文字
• [69] GCC
• Muleの文字合成
  • [214] Emacs の私用制御機能
  • [215] Mule内部コード
• [20] subtending mark

[21] 関連: 文字のレンダリング, 合字

[15] アジア諸国の実用や欧米の研究者の研究目的で一時期広く使われた各種のフォント依存符号化は、 文字を文字素や見た目の類似部分など各種の基準で分割して収録し、 前後の文字を同じ位置に重ね合わせるようなフォントとすることで合成していました。 前置非spacing文字型が多いようですが、 後置結合文字型もあるようで、 どちらにも当てはまらない複雑なものもあるようです。

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

[276] Windows-1258 には後置型結合文字があります。

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

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

[6] wg2-n937.pdf, 2009-02-13T23:43:40.000Z, 2023-07-16T14:07:12.109Z http://www.unicode.org/L2/Historical/wg2-n937.pdf

[7] >>6 これ29区から46区の01から59って変な範囲だけど94²集合なのだろうか?

[8] >>6 #page=12 は IDC の祖?

[11] IRGN2578OrganicChemical.pdf, 2022-10-13T22:40:25.000Z, 2024-04-27T08:21:12.126Z 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, 2023-03-16T09:27:31.000Z, 2024-04-27T08:35:51.304Z https://appsrv.cse.cuhk.edu.hk/~irg/irg/irg60/IRGN2578JunliangFeedback.pdf

Unicode の結合文字

結合文字

JIS X 0208 と LARGE CIRCLE

LARGE CIRCLE

JIS X 0213:2000

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

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

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

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

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

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

[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] i や j の上に結合文字を配置するときは、 基底文字の点を削除するべきです。 >>58

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

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

[79] (Unicode や OpenType ではなく) この JIS X 4051 の規定に基づく実装があるのかどうかは不明です。

OpenType

マークグリフ

分合活字的デジタルフォント技術

[1] Droid Sans Fallback

[3] 和田研フォント, KAGE

[4] 今だったら小さい文字集合 (教育漢字くらいの規模) のグリフデータと既存の大きな OSS フォント (の文字の骨組み) を使って AI で残りのグリフを補完して独自のフォントを生成するようなやつ、 実用的なレベルで作れるのではないのかねえ?

[5] 例えば教育漢字の丸ゴシックを作って IPAmj明朝と一緒に入力したら文字情報基盤全部の丸ゴシックフォントが出てくるみたいなシステムがあったらすんごい嬉しくない?

[14] Xユーザーの4b³さん: 「Windows付属繁体字フォントの標楷體、全漢字が1画ずつのグリフを引用してTrueType命令で変形させてできているらしい…と以前(多分Twitterで)読んだけど、実際覗いてみるとちょっとやそっとの変形ではなく例えば「匹」の3・4画目が同じコンポーネント(黒線が変形前)でできている… https://t.co/N3BSsH67SK」 / X, 午後11:20 · 2019年11月4日2019-11-04T14:20:00.000Z, 2024-08-28T07:37:55.000Z https://x.com/fourbthree/status/1191359446020055040

[16] TrueTypeヒンティングを利用した筆画ベースフォントについて - にせねこメモ, 2024-10-24T12:49:38.000Z https://nixeneko.hatenablog.com/entry/2024/07/02/000000

関連

[22] 漢字構造記述, ハングル, ダイアクリティカルマーク, 文字のようなもの

メモ