現在の状況

• 2009-03-06 とりあえずグリフ全部埋まる。お疲れ様でした＆ありがとうございました。
• 2009-03-16 実装ミスを思われるものの修正が終了。ひとまず完成。

(Group:CJK統合漢字拡張Cに移動しました)

凍結した後の方針再修正について

過去の議論の最後に以下の方針にする、と書きました。

 Ext.Cについては、（望ましくは）相応の理由の提示（ノートにお願いします）の
 上で、規格票字形ではない（その登録者の考える）適切な字形への変更を許容する。
 もし変更前の字形が規格票字形である場合は、それを「-j」に移動する

しかしながらこのケースについては、規格票の字形とAnnex.Sの基準のみで考慮すべきであり、グリフを実装する際に原典をチェックするようなことをすべきではない、という原則を再確認し、規格票の字形については、JCSの方針で採取、規格化された字形（＝平成明朝体字形）を想定する、と考えます。

つきましては、u2b66aおよびu2af7aは元に戻しました。また、上記の方針については撤回し、あくまで「-itaiji-###」での登録をお願いします。

過去の議論

検討対象になりそうなもの

u2a714 u2a721 u2a744 u2a909 u2a965

u2ace0 u2ace2 u2acf8 u2ad05 u2ad1f

u2ad21 u2adeb u2ae8a u2aecc u2aece

u2aedc u2aefc u2af2f u2af46 u2af4b

u2af5c u2afa8 u2afae u2afc1 u2afd4

u2b0c4 u2b0c7 u2b0f2 u2b0fa u2b105

u2b14a u2b160 u2b18b u2b191 u2b1a8

u2b1af u2b1dc u2b1e7 u2b1e8 u2b1e9

u2b1ef u2b1fb u2b1ff u2b202 u2b206

u2b207 u2b213 u2b224 u2b239 u2b23d

u2b240 u2b247 u2b251 u2b252 u2b259

u2b25c u2b260 u2b26b u2b270 u2b27b

u2b280 u2b284 u2b298 u2b29c u2b2a6

u2b2b0 u2b339 u2b34e u2b3cf u2b3f9

u2b475 u2b493 u2b49c u2b4a6 u2b4cd

u2b4cf u2b59f u2b60b u2b615 u2b639

u2b644 u2b645 u2b665 u2b669 u2b66a

u2b66e u2b674 u2b67a u2b6b2 u2b6ba

u2b6c4 u2b6c7 u2b6c9 u2b6d2 u2b6d7

u2b727

字形について

はじめに決めても良かったのですが、調査の対象になりそうなので字形実装の方針について特に決めていませんでした。できれば以下のような方針でチェックと修正・調整をお願いします。ただし字形のチェックはあまり厳密でなくても、早く公開できるほうが望ましいと考えます。--kamichi 2009年3月6日(金) 16:57

• 日本の字形デザインで考える、もしくは原字（PDF)に忠実に、できれば前者で
• 日本ソースがない場合に想定する日本の字形デザインとは（常用漢字の新字体ではなく）印刷標準字形寄りで
• 日本ソースがある場合は忠実に

議論

アクセス元が違うので匿名で失礼します。日本ソースに盲従するのは反対です。日本提案の文字はせっかくすべて典拠が公開されているのですから、典拠も確認してみるべきです。JIS X 0213は勝手に字形を作らない 方針であるようなので規格票を忠実に写し取ってもあまり問題なさそうですが、UCSはそうでもないようです。

たとえばu2af7aやu2b66aは露骨に字形が違います。Ext.Cの直接のソースは〓〓〓〓〓 なのですから、うかつに字形を丸写ししたら〓〓〓〓〓の無断使用になりかねません。

だからと言って典拠の字形をそのまま写しとればいいというものでもありません。u2b6c7のu706cを[一]にすべきだとは思いません。規格票の草冠はufa5eに統一されているようですが、典拠ではバラバラです、だからと言って典拠が手書きの楷書になっているもののufa5dを忠実に写し取るのが適切とは思いません。手書きのソースでは[青]でも規格票ではu9751に統一されているのは適切だと思います。

典拠が「人名」であるものは丸写しするしかないとも一瞬思ったのですが、u2acacとかu2b027とか本当にこれでいいの?--匿名利用者 2009年3月11日(水) 12:01

ご意見ありがとうございます。匿名発言ということでバックグラウンドが不明なので文字面だけで解釈させていただきます。混乱する前に問題を2つに分けたいと思います。

• 集合A：Jソースがあるもの
• 上地意見：規格票（平成明朝体による解釈、作字）に沿う
• 集合B：Jソースが無いもの
• 上地意見：Jソースを想定したデザイン（印刷標準字寄り）、もしくは、規格票上の字形そのまま

集合Aについて規格票の字形が〓〓〓〓〓云々という件については、さらにいえば参照番号も〓〓〓〓〓の番号と偶然一致しています。ですが、これは規格票として出版された時点で切り離されると思いましたが違うのでしょうか（以前、問題無いような事を口頭で聞いただけなのできちんと根拠を調べていませんでした）。

仮に日本のどこかのフォントベンダーがExt.Cを実装すれば規格票どおりになると思うので、敢えて出典の字形を議論して「出典に一致させる・手書きなので明朝体で解釈しなおす」という作業を行うのは、その意義と作業量のバランスが悪いと考えます。

一つ見落としていたのは、私はX0213の件（新たな作字形はしない）が今回のExt.Cの日本提案字でも同じであると勝手に思っていたので、そうではないということがショックです。ただ、〓〓〓〓〓の文字収録時の字形がどのようなルールだったのか、時期などでばらつきがないか、などを考えると原資料に沿う、ということには反対です。まとめると集合Aは規格票追従を主張します。

集合Bについては、本当は作字形をしたくない、だから規格票字形追従も考えましたが、それだとあまりにも、というものも多いので、とりあえず字形がわかればよい、ということで２つの方針の混在を考えました。私が思うに、UCS（もしくはこれは昔のUnicode標準だけの話？）の収録字は、あくまで「字形」であって、もともとの典拠の字からは切り離されている、と考えれば、(特に手書き人名で)新たな解釈で作字形してもいいのではないかと思います。あまりまとまっていませんが、ざっとコメントでした。--kamichi 2009年3月11日(水) 14:45

一つ書き間違えていました「ただ、〓〓〓〓〓の文字収録時の字形がどのようなルールだったのか、時期などでばらつきがないか、などを考えると原資料に沿う、ということには反対です」以下の部分は、読み間違えていたので削除してください。

GlyphWiki小会議でも議論しました。私の理解した範囲での結論は「工業標準規格として制定されたものに準拠するのが妥当」とし、その過程で提出された原資料に当たることまでする必要はない、という趣旨でした。

私の個人的意見としては、特にExt.Cは使われてこそ意味があり、またグリフウィキ本来はあらゆる字形を収録できるべき、と思いますので、実際に使って下さる（登録する）人の自由に任せようと思います。そこで、別の人からまた別の意見が出たら、もう一度議論するということでいかがでしょうか。

それを踏まえて、以下のようにしたいと思います。--kamichi 2009年3月11日(水) 23:56

• 今回（Ext.C集合の花園明朝への追加に向けた作業）は、ルールを決めて字形をいじることはせず、将来の使いたいと思う人、直したいと思う人の意思に委ねる
• 明らかにグリフ登録者が間違っていると思われるケース以外の字形修正は行わない
• さらに、デザイン調整も行わない（調整が終わるまで公開しない、ということにはしないで時期が来たら公開する）
• UCS符号位置に相当するグリフは、今までは規格票のJソースに沿うことを原則としていたが、Ext.Cについては、（望ましくは）相応の理由の提示（ノートにお願いします）の上で、規格票字形ではない（その登録者の考える）適切な字形への変更を許容する。もし変更前の字形が規格票字形である場合は、それを「-j」に移動する

上記の匿名利用者は私です。身元を明かして発言することで解釈に何らかのバイアスがかかるなら、ずっと匿名で発言してたほうがいいような気がしてきましたが。

なお、原資料は規格票例示字形の無条件追従に反対する根拠の1つとして挙げただけで、原資料追従を必ずしも主張しているわけではありません。

上記で確認した原資料はIRGN 1225でしたが、さすがに制定前にツッコミが入っていたようで、おおむねIRGN 1348で訂正されていました(じゃあ前の"Evidence"は何だったんだ? と思わなくもないが)。ですがu2b66aの刀をクに、人を儿に作ってはならない理由はまだわかりません(というかそんな理由はないと思っています)。

Annex.Sも当然ながら「工業標準規格として制定されたもの」の一部ですよね? 工業標準規格として制定されたJISの包摂規準も常用漢字表の字体についての解説も無視して、ただひたすら規格票例示字形を厳密にコピーする慣習に従うことを日本では「妥当」と言わざるを得ないのは理解しますが、それならそうと正直に言ってください。--emk 2009年3月13日(金) 09:01

自己フォローもかねて２つ。（１）「身元を明かして発言することで解釈に何らかのバイアスがかかる」：もちろん人間ですから全くバイアスがかからないとは言いませんが、それが言いたいのではなくて、どれぐらい規格や漢字の知識を持っている人なのか、過去どういった意見を言っているので、今回の書き込みの意図にその流れを踏まえた解釈をすべきなのか、といった肉付けができないので、ここに書かれた分のみで解釈をせざるを得ないという意味です。それが「バイアス」である、というのでしたら否定しませんが、私としては「バイアスがかかる」という文言は少なからずマイナス方向の意味も含んでいると解釈するので、発言の意図としてそれ（マイナス方向の意味）については否定します。

（２）堂々巡りになると思いますが、フォントベンダーが規格票の文字表の字形に追従してフォントを実装することは妥当と片付けていいと思いますよ。その中でも楷書体フォントは楷書体の流儀で変更するとか、自社のデザインはこうだから敢えて例示字形とは違うものにする、といった工夫が出てくればいいですし、知識も予算もないから追従、という製品があったってかまわないと思います。今回のExt.Cの文字集合については、早く公開したいことが第一にあり、そして字形について日本ソースを規格票に追従することによって多数から大いに非難されるほどの存在ではないと思ったので、当初の字形チェック方針を決めましたが、今回の意見を受けてExt.Cについては規格票字形を「-j」に移してもかまわない、と考えたわけです。

議論のすり替え、と言えなくもないですが、Ext.C以降、日本提案字に扱いの面倒な団体のリソースが入ってしまっているので、一度法律的な解釈をしてもらった（グリフウィキとして１つの解釈を出す）方が良いですね。グリフウィキがあと10年早かったらよかったのかもしれませんが、10年前は文字コード問題の勉強で精一杯でした。--kamichi 2009年3月13日(金) 09:59

公開の形態について

• A案.花園フォントの拡張（Ext.C単独）として公開するか、B案.花園フォントに統合して公開するか、C案.別のフォントとして独立するか、コメントがありましたらお願いします。当初花園フォントはJIS X 0213が満たされたら打ち止めにするつもりでしたが、だいぶ周知されているような(気がする)ので、迷っています。特に意見が無ければB案を考えています。--kamichi 2009年3月6日(金) 16:57
• まずは拡張Cが埋まっておめでとうございます。JIS X 0213なんていわずにCJK統合漢字、拡張A、拡張B、拡張C(今回はこれ)、拡張D(これはまだ早い)と追加してください。今の所、B案に1票--uchi 2009年3月7日(土) 00:53
• TrueTypeフォントは1ファイルに65535グリフしか収録できないので、拡張Bまでを全部入れるならファイルを分割しなければいけないのです。でも今のところは1ファイル(つまりB案)でいいでしょう。--emk 2009年3月7日(土) 11:42
• お二方コメントありがとうございます。そうですね、JIS X 0213のことを考えると単純に今すぐにBMPとSIPで分離するのはいまいちと思います。B案で行くとするならば、今後64k分埋まる限り1フォントに詰め込んでいって、最終的にSIPを別フォントに分離、ただしSIP側で今まで収録した分は消さずに、分離先のほうで同じグリフを重複して収録というのはいかがでしょうか。現在BMP+Ext.ABCで38000弱なので、当分先の話だとは思いますが。個人的には漢字が65535グリフすべて埋まったフォントを作ってみたい気もします（.notdefなども入れるとフルは無理かもしれません）。--kamichi 2009年3月7日(土) 18:14

• B案で行くことにします。--kamichi 2009年3月11日(水) 23:56