GlyphWiki:井戸端

出典: フリーグリフデータベース『グリフウィキ(GlyphWiki)』

グリフウィキで利用しているKAGEエンジンは明朝体の表現を主目的としています。グリフウィキに教科書体を模したグリフがいくつか登録されていますが、目的に合わないので整理する予定でした。このたびGデザイン、Tデザインのガイドラインを提示する予定となりましたので、合わせて教科書体についても分別します。

まず、無理やり教科書体を模したグリフは削除したいと考えます。

kyoukasho-nisui kyoukasho-shinnyo kyoukasho-uji-sennashi u5fc3-kyoukasho u7cf8-kyoukasho u8fd1-kyoukasho

それ以外の学参明朝体は明朝体の字体の一種としてとらえたいと思います。ただし、命名法は「u####-var-###」に変更します。

以下のグリフについては、形状を変更します。どう変更するかはGデザイン、Tデザインのガイドラインと絡めて後日記述します。

kyoukasho-onna-btm u51fa-kyoukasho

以下のグリフは、学参明朝体として実績があるか不明なため、調査ののち判断します。

u5b50-kyoukasho

以上、ご了承願います。--kamichi 2010年8月26日(木) 22:31

以下の4グリフについても削除対象とします。

u4e7e-natiomoji u548c-natiomoji u6c17-natiomoji u96fb-natiomoji

以上追記。--kamichi 2010年8月27日(金) 17:11

UCSグリフのあいまいなJ欄優先について

現在、UCS符号位置に相当するグリフ（u4e00、u20000）は、日本字形を優先、という漠然とした方針になっていますが、これを改めたいと思います。いくつか方法があると思いますが、たとえば以下の3つです。

（１）指定なしの場合に地域優先順位をつける

たとえば、J欄、K欄、T欄、G欄…、という風に、寄せるべき優先順位をつけるというものです。特にExt.BなどのJソースがない集合について、Jらしくないデザインが混ざってしまうことがデメリットです。メリットは規格票に沿えばいいので作字しやすいことです。

（２）指定なしを「J欄」または「仮想J字形」とする

地域の指定がない場合は、規格票でJ欄があればJ欄を、J欄がなければ「仮想J字形」とし、それ以外は必ず地域指定をする、という方針です。

そうなるとu7eebは、簡体字ではありますが、右のつくりはu590cがルール上妥当、ということになります（嘘字が生じるというデメリットになります）。従来のu7eebはu7eeb-gに移動させます。

メリットは、あまり現状と差がないこととルールが明確化されることです。

もう一つの問題点は「仮想J字形」の定義ですが、康煕字典体、おおよそ常用漢字外の漢字字形に共通するデザイン、あるいは字書に出てくるデザイン、を想定します。

（３）地域指定なしを捨てる、あるいは抽象化する

具体的なグリフは必ず地域指定することとし、地域指定なしグリフを除去する、あるいは、J欄などへのエイリアスにする、方針です。この場合日本優先ではなくなります。

個人的には一番使うであろうUCS地域なしグリフがなくなることに拒絶感があります。エイリアスにした場合、長い目で見た場合に、どの地域にエイリアスを張るのかで編集合戦が起きる可能性があります（せっかく日本偏向をやめた意味がない）。

メリットは一番明快であること、CHISEとの統合構想にもっとも近い方法であることです。

今あるUCSグリフをすべて地域に振り分ける作業が生じます。

ということで

上記案へのコメントや改良案がありましたらお知らせ願います。このところグリフウィキのコアメンバーが減少していますが、できれば1週間ぐらいで方向性を決めたいと思います。--kamichi 2010年8月10日(火) 02:37

個人的な意見としては、「仮想J字形」だけはやめてほしいです。例えばu5de0の簡体字はu22016ですが、「仮想J字形」とするならばu5723にしなければいけないのか(ちなみにu5723はu8056の簡体字)、u95e8はaj1-14061にするのか、u6797がu233dfである可能性はないのかなど、すべて考慮しなければいけなくなるからです。(続く)
それに、u8353とu84f1の様に、J欄ですらデザインが統一されないのですから、人によって「仮想J字形」の定義の取り方は違ってくると思いますよ。--daekyo 2010年8月13日(金) 03:57

余り深く考へたわけでは有りませんが、小生はkamichiさんの例挙した中の一つであるJ欄・仮想日本字形案が良いと存じます。何を以て仮想日本字形とするかに就ては、最終的に個別の規則を定むべきであると考へますが、問題となる者はさう多くないと思ふので、差し当つては各々好きに作り、之に異見が有れば議論すると云ふ形で良いと存じます。――lizard 2010年8月13日(金) 04:19

１つ誤解を生んでいました。「仮想J字形」は正しくは「仮想Jデザイン」です。つまり、daekyoさんがご懸念の上記事例はほとんどは現状維持になります。「仮想Jデザイン」の指すところは以下のようなものです。--kamichi 2010年8月13日(金) 10:07

言偏の1画目は「横棒」
「ム」は3画のようにデザインする
「u590c」や「骨」、「糸偏」などは日本デザインに
ソース分離されているものは、それに従う

lizardさんがおっしゃるように、議論となるものはそれほどは多くないだろうということと、意思決定に関与する人数は残念ながらそれほど多くないだろう、という判断でこの仮想J字形(デザイン)の案があります。逆に議論が多くなって大変だ、という見通しであれば、根拠が明確となりやすい第3案が妥当ですね。この見極めも必要かと存じます。--kamichi 2010年8月13日(金) 10:07

私の意見としては，(2)の案が妥当と考えますが，若干の修正が必要と考えます。u7eebのように「簡体字としてしか使われない文字」にまで「仮想Jデザイン」を適用するのは行き過ぎではないでしょうか。そうすると「簡体字としてしか使われない文字」の定義が問題になりますが，例えば，

ご意見ありがとうございます。たしかに明らかに簡体字と思われるものまでJデザインにすべきかという問題があります。それでこの「明らか」というのが結構曲者で、たとえばu57b4は、一見簡体字のように見えますが、正式な簡体字のルールでは簡体字になりません。このような判別不能なものがままあります。ですので１つの考え方としてまずは「類推適用可能な偏旁簡化部品」が用いられている（UCSの並び順で通常の部首内の後ろに来る）文字をJデザインの原則からはずすという運用で第2案が考えられます。また個人的に嫌なのはKAGEエンジンではGデザイン（時々Tも）に無理が生じるケースがあり、これをどうにかしないといけないとも感じています。--kamichi 2010年8月13日(金) 23:27

まさに議論中でありますが、Jデザインを4画草冠と勘違いしてExt.Bの漢字を多数登録してしまいました。JIS規格の場合常用漢字表外字も3画ですね…。修正します。--kamichi 2010年8月14日(土) 12:16

修正しようとして気が付きましたが、結構なExt.Bの草冠が4画でした。あえて4画にする字書系と3画の規格票、どちらにそろえるべきか悩みます。やはり規格票の3画でしょうか。--kamichi 2010年8月14日(土) 12:47

個人的には4画のほうが好きですが、「仮想Jデザイン」に拘泥るのであれば3画にすべきではないでしょうか。--daekyo 2010年8月14日(土) 22:49
規格票通りの三画とすべきであると思ひます（尚小生が作る時は三画として来たし、他人の作つた四画の者を三画に直した事もあつたと記憶します。あと、草冠が四画であると、其の字を使ひたくとも使はれない（使ひたくない）＞＜）。――lizard 2010年8月14日(土) 23:08
部品切り替え機能を強化したので割と簡単に統一できると思います。--kamichi 2010年8月14日(土) 23:32

もう一つu2a690のような簡体字について、u7259をGデザインu7259-gにすべきかという議論もあります。というのは、KAGEエンジンとGデザインは親和性が低いため、できれば正しいGデザインではなく、アレンジしてほしいという意向があります。たとえばMingLiUフォントが簡体字をデザインする場合もGデザインではなくT寄りになっていると思います。これをグリフウィキでも採用したいのですが、いかがでしょうか。--kamichi 2010年8月14日(土) 19:02

その程度(左下カドのデザインの違い)であれば私は構いませんが、u7eebにu590c-02を使用するのにはやっぱり反対です。 --daekyo 2010年8月14日(土) 22:49
daekyoさん、仮に「簡化偏旁」が含まれる字のみは規格票により、それ以外はJ・仮想Jとした場合はいかがでしょうか？つまり、u7eebは維持され、それ以外はu590c-02になる感じです。--kamichi 2010年8月14日(土) 23:32

「仮想Jデザイン」の問題に、GlyphWiki:命名ガイドラインにある「日本の規格にない文字ということは常用漢字外ですのでいわゆる旧字体のデザインとしてください。」というところもあると思っています。特に簡体字は「日本の規格にない文字」なのですから、極端に言えば、すべて旧字体ということは繁体字のJデザインと同じような字形になる?なんておかしなことになるのではと思ってしまいます。実際にはそんなことにならないのでしょうが。(続く)
最近更新したページ(Special:Recentchanges)を少し覗いてみましたが、kamichiさんですら「いわゆる旧字体のデザイン」というルールを守っていないときがあるようなので、これは廃止したほうがいいと思います。入れるとしても異体字として登録するような形にすればいいのではないでしょうか。(それは嘘字なので異体字として登録すべきではない、という議論もありそうですが) --daekyo 2010年8月14日(土) 22:49

すみません、「グリフがあること」の目的を優先して、「部品がないから・先に見つけたから」わざと守っていない時と、「気が付いていない・知識が間違っている」時のどちらも考えられます。（続く）
言われてみると、難しい問題ですね。もう少し、他の方のご意見を待ってもいいでしょうか。私は今ニュートラルというか混乱してしまいました。--kamichi 2010年8月14日(土) 23:33

仮にJ優先をやめ、完全分離するとした場合、花園フォントを構築する際にJがない場合にどれを優先するかを考えることになります。おそらくK→T→Gとなると思うのですが、そうすると草冠はT欄の4画がたくさん出てくるといった問題も出てくると思います。かといってGを優先したくはないです。旧字体という概念も、使う活字によって揺れがあるといいますし、康煕字体・諸橋石井字体もしかりです。（つづく）
話が大きくなりますが、一般的なJ字体のガイドラインといえるものを並行して作ってみるというのはいかがでしょうか。活字畑の方に言わせると無謀？でしょうか。--kamichi 2010年8月14日(土) 23:49

最後の1文余計でした。~~活字畑~~とは、旧字体・印刷活字字体に詳しい方、という風に読み替えてください。--kamichi 2010年8月14日(土) 23:51

現状

間が空きましたが、以下のようにまとめてみました。

仮想JデザインをUCS符号位置にすることに反対

仮想Jデザインは字形を一意に決めることが難しい
ウソ字の大量生産が発生する
簡体字をJデザインにしたくない
かねてからの目標であるCHISE-DB（CHISE-Wiki）との統合に必要
日本人以外にアピールする際に有益

仮想JデザインをUCS符号位置にすることに賛成

それほどメンバーが多くないので調整可能か
代表字形を1つにするとフォントとしてまとめた時にデザインがぶれない
グリフウィキとしてJデザインのガイドラインをまとめられないか

簡体字デザイン、繁体字デザインについて、日本デザインアレンジすべきか否か

賛成：統一感が出る
反対：おかしい
将来的にユーザーを日本での利用に絞るのか否か

今考えているのは、やや「反対」寄りです。「ハイフン＋地域」について、ローカル規格にあるものは「規格票字形」、ないものは「仮想字形」と解釈することにして、「-j」を復活させ、無印UCSをいったんすべて「-j」に移します。今後も「-j」の登録を推奨し、字形がぶれた場合はその都度議論し、「仮想Jデザイン」のガイドラインをまとめていく、というものです。

問題点は無印UCSをどうするかです。現段階では「廃止」し、特殊ページ扱い（各地域の列挙）とするのが妥当と考えます。ただし、無印UCSのグリフ画像を要求されたときに何を返すかの問題が残ります。現状では欄ごとの優先度を決めることを考えています。花園フォントに収録するグリフについても同様となります。

簡体字デザイン、繁体字デザインのKAGEエンジンでの対応も課題です。今問題となっているのは箱形状の下側角なので、端形状を追加することが妥当と考えます。仮想Jデザインを併用することで、Jフォントにした際のブレの解消と、簡体字フォントにした時の違和感の双方が解消できると考えます。

議論がいったん止まりました。現状認識と現時点で私が考えている方向性について記述しました。認識違い、漏れ、およびコメントがありましたら以下にお願いします。--kamichi 2010年8月26日(木) 10:27

「縦払い」ストロークで３つの点が並ぶ現状について

縦払いストロークは、初めの３つの点が１直線に並ばないとポリゴンが切れる不具合があります。この解決方法として

（１）常に１直線になるように固定する（２点目のX座標は無視する）（２）直線部分と曲線部分が切れないようにする（直線部分の末端に丸ポリゴンを置く）

の２つがあると思いますが、デザイン上（１）の１直線に「ならない」ケースは存在するでしょうか？するのであれば（２）にすべきですし、存在しないなら（１）にしたいと思います。--kamichi 2010年8月9日(月) 22:39

グリフ検索機能のテストについて

その１ http://fonts.jp/glyphwiki/kensaku.cgi
その２ http://fonts.jp/glyphwiki/hwr.html
その３ http://fonts.jp/glyphwiki/hwr2.html

グリフウィキに登録されているグリフをストローク種別の指定で検索するテストページを作成しました。ストロークを8種類に分けて指定します。書き順が意味を持ちます（グリフデータの書き順が間違っている場合はヒットしません）。文字を記述すると自動的にストロークに変換して検索します。

あまり実用度が高くないですが、手直しして検索補助機能として採用したいと考えます。コメント、ご意見ありましたらお知らせ願います。--kamichi 2010年8月7日(土) 17:31

追記：検索用データの生成は手動です。現状では2010-08-07 17:00ごろのデータとなっています。--kamichi 2010年8月7日(土) 17:35

大幅に作り替えました。ワイルドカードの導入と画数の範囲も指定できるようにしました。--kamichi 2010年8月11日(水) 21:30

手書き検索を追加しました。どちらかというと、あるのを知っていて探すための用途になる感じです。--kamichi 2010年8月20日(金) 00:00

手書き検索２を追加しました。こちらの方は使い物になりそうです。速度が遅いのが問題点です。--kamichi 2010年8月20日(金) 22:51

花園フォントのライセンスについて

今思ったのですが、現状の「フォントに自由なライセンス」と一般的なフォントのライセンス（SIL-OFLを想定）のデュアルにすれば混乱が少ないのかと思いました。現状と比較して制限が増えるわけではなく（OFLを選べば制限が生じますが、それはお好きにどうぞ、ということで）、メリットとして既知のライセンスが使えるという安心感もあります。いかがでしょうか。--kamichi 2010年7月19日(月) 21:16

特にコメントがありませんので、次回公開分からSIL-OFLと独自ライセンスのデュアルライセンスに変更することを考えています。--kamichi 2010年8月1日(日) 14:51

2010年度の収録方針

さまざまなペンディング事項が山積しており大変恐縮ですが、それとは別に2010年度のグリフ収録の方針を以下のようにします。すでに一部は登録されているので、未収録をなくす、という方針です。

ISO/IEC 10646 Ext.B
ISO/IEC 10646 Ext.E
『大漢和辞典』（諸橋轍次著）
『日本人の作った漢字』（ライマン著）
「第二次漢字簡化方案・第一表」（中国行政法令、廃止済）
ベトナムのチュノム（字喃）
国字の字典（菅原・飛田）
和製漢字の辞典（大原望）
その他数種

仮名の収録について

現在の花園フォントにはひらがな・カタカナが入っていないため、Linuxのfontconfigで日本語フォントとして判定されない、とのご指摘をいただきました。KAGEエンジンでは無理があることは承知していますが、積極的に両仮名を埋める方針にしたいと思います。あるいは習作でもいいので、両仮名の原字データを提供していただければ、その部分だけ提供のあったアウトラインデータを収録するようにしたいと思います。--kamichi 2010年7月13日(火) 22:12

まずはすべて埋まりました。ご協力ありがとうございました。チェックミスにより2字ほど白抜けが発生しておりますが、次回更新時に修正ということでの対処を予定しています。--kamichi 2010年7月20日(火) 00:42

メタ情報の付与

以前から要望のあるグリフに対するメタ情報の付与について具体的に検討したいと思います。仕組みとしては新たな機能追加ではなく、同名「ノート」ページへのテンプレートの記述を考えています。ノートページにテンプレートを書くと、グリフページの表示時に差し込み表示されるという形態を考えています。

記述するメタ情報については、おそらくさまざまなニーズがあり初めから規定することは難しいと思います。ある程度の同意が取れたものをテンプレートに追加しつつ、それ以外の記述もできると良いと思います。記述式は「項目名=値」の一般的な形です。

また、１つのグリフに２つ以上の字が重なって解釈されることがあると思います。本来は重なっていると認識した時点でグリフを分ける（別名エイリアス）必要があるのですが、判断できない場合など、メタ情報も２つ以上のブロックに分けられる必要があるかもしれません。--kamichi 2010年3月3日(水) 09:56

先に大まかな項目名を挙げたいと思います。ほかにありましたらどんどん追加願います。

使用例・典拠

辞書、書籍、資料名、URL
版、刷、時間情報
URLの場合、確認時間

よみ、部首、画数
関係のある字、関係
複数ある場合はカンマ区切りではなく多重記述の方がよいか？

意見させていただきます。先ず「辞書、書籍、資料名、URL」について。どのような辞書なのでしょうか？また、どのような情報を載せるのでしょうか？(私は辞書のページ数を載せることを考えています。)
URLについては、確証があることが条件だと思います。(ジョーク・創作漢字の場合は除いて。)
読みについては、常用漢字は常用漢字表。表外漢字、常用漢字の表外読みは漢検の漢字必携一級などから、と考えています。ただ、戸籍統一文字にはそれ以外の読みも載っていたりします。(たとえば、規の常用読みはキ、表外読みはのり，ただす、戸籍統一文字の読みはぶんまわし等)
関連字は、グリフウィキに既に存在する異体字一覧の中から、主要なものを取り出して書くということでいいと思います。「関係」というのは、旧字、誤字などということでしょうか。それは問題ないと思います。--tomomo 2010年3月18日(木) 19:25

質問

先程グリフウィキを知り、とても素晴らしいと感嘆しました。そのような初心者で恐縮ですが、質問させていただきます。各グリフの記事には、その字と、異体字やグループなどが記載されていますが、その字の説明などがありません。グループに記載されているものもありますが、各記事にその字の軽い説明・出典がないと分かりにくいですし、幽霊文字のように何に使うのか分からない字が生まれる可能性があるように存じます。そのようなところは、どうなっているかお訊きしたいです。匿名利用者 2010年2月28日(日) 08:30

ご質問ありがとうございます。なかなかお答えするのは難しいのですが、次のように考えています。まず、グリフウィキは「グリフ」の管理システムですので、個々のグリフが何の「字」であるかは規定しません。ですので、ある「字」のグリフがグリフウィキ上では2種類以上になることがあります。また、1つの「グリフ」に対して、別の2種類以上の「字」と結びつくことがあります（この場合、基本的には同じグリフが2つ以上のグリフページに分かれることになります）。これらはすべて「人によって」もしくは「地域や時代、文脈によって」解釈が異なることあり、グリフウィキではその結びつけが個々の利用者にすべて任されています（続く）。
またグリフウィキでは個々のグリフを名前で区別します（厳密には名前＋バージョン番号）。その名前の中に暗黙的（もしくは明示的に）に「字」あるいは他の文字の概念と結びつくことがあります。たとえばGlyphWiki:命名ガイドラインに沿うような命名をした場合、他の文字コードで規定されている字（ただし文字コードも「字」を規定しているのではなく、あくまで「字形」と符号位置との対応関係であったりもします）と結びつくことがあります（続く）。
ということで、もともとの目論見としては、グリフウィキはあくまで「グリフ」の保存管理庫であり、「字」などの関連付けやメタ情報の付与は他に存在する専用のデータベースで行い、そのグリフ情報をグリフウィキとリンクする、形態を想定していました。対象としてはたとえばCHISE文字データベースなどを考えていました（続く）。
しかしながら、グリフに対するメタ情報がないと、まさに幽霊文字のようなものが沢山存在してしまうことは起こります（ただし、それはある人にとっては幽霊文字であっても、ある人にとっては「字」に対する結び付けができているのであれば、本来の目的が達成されているといえます）。ですので、「メタ情報」の付与ができる仕組みの検討が一応進んでいて、現状は「関連字」の改良と一緒に機能拡張を行う予定となっています（この井戸端ページの下のほうにその議論があります）。残念ながらグリフウィキは運営者の問題もありイベントが起きてから対処する開発形態となっているため、なかなか開発が進まないという問題点は存在します。もう少しお待ちいただきたいと思います。--kamichi 2010年2月28日(日) 10:04

保安のこと

今のグリフウィキはとても性善説な感じで、匿名で世界中の誰でも何でも弄れる様になってますが、このままで行くのは危ないのではないでしょうか。個々のグリフを壊されるだけでも一々差し戻すのは大変だし、壊した上でそれを引用するグリフの一括更新までされると、昔の一括更新なら位置補正がなかったので単に差し戻し再更新で元に戻ったけど、今やメチャクチャな位置補正値を与えれば簡単に多数のグリフが壊滅的に壊れてしまいます。また、命名ガイドラインに無い命名は基本的に自由としつつも、実際にポツポツ投稿されると全体の編成などの面で困ります。（つづく）
命名の方は何も壊れないからまだ宜いけど、グリフが壊れるのは問題だと思うので、例えば最低限、既存のグリフを更新するのは登録利用者でなければならないという様な設定にしてはどうでしょうか。（その場合、その本人が新規作成したグリフだけは更新を許可するという事になるかも知れませんが。）一括更新は、出来るとしても位置補正は許可しないとか。（つづく）
新規命名・新規作成の方まで制限するとしたら、例えば未登録の誰かが漢字字形について論文を書きたいという時、ちょちょいとここでグリフを作ってくという利用を妨げてしまうかも知れません。ああ、まあ、画像を持ち帰って貰うか、「@」で版まで指定して貰えれば、削除されても別に問題無いですね。（つづく）
それと、グリフの改称について現在は「旧名称データの削除」と「新名称への複写」を手動で行っているものを、システム上の処理で一度に移動できたら良いんですけどね。グリフデータを移動し、移動元の編集コメントに移動先を書き、移動先の編集コメントに移動元を書くというのを一括して呉れるだけの機能でも。今は編集コメントに意識的に書かないと歴史を引き継げなくなってしまい、書き忘れると過去の編集協力者に申し訳無くなります。— sayunu 2010年1月10日(日) 14:17

以前匿名利用者（厳密には国外ユーザー。理由は著作権譲渡ができるか（制度・言語）どうかの懸念）の機能制限を考えましたが、反対意見があり流れました。ある程度グリフウィキが順調に運用がされるようになってから2年経ちましたが、コアなユーザーというのはおおむね5本の指に余るかあまらない程度、匿名利用者はほとんど無し、ということで、私としては性善説のままで継続し、トラブルドリブンでそのときに対処法を考えるというのでいいのではないかと思います。まだ両手を広げて来訪者を待つ段階と考えています。（つづく）
グリフ改称機能は便利だと思います。検討します。--kamichi 2010年2月11日(木) 19:04

私も、匿名利用者を制限するということには若干抵抗がありますし、ちゃんとした作業をしてくださってる方も多いように思えます。併し、ひとたび荒らしが発生すれば、それを修正するだけでも大変ですから、対策が必要なのかもしれません。とりあえず思っていることは、「緊急停止」機能。匿名利用者、ないし登録利用者の編集を一時的に禁止することなのですが、どうでしょうか。--tomomo 2010年2月12日(金) 21:43
あまり「荒らし」の経験が無いのですが、活動時に直接制限を設けるのは逆効果なのではないかと考えます（機械的に大量の操作を実行されるばあいは有効ですね。考えます）。ですので、収まった後に時間と実行元IPを指定すると該当する投稿を一括でリバートする機能を用意しておけばいいのかなと思います。--kamichi 2010年2月12日(金) 21:58

グリフ内の部品を一括で変更する機能が手元で完成しました。制限なしで公開するか少々躊躇しています。--kamichi 2010年2月12日(金) 17:10

非漢字グリフについて

当初グリフウィキでは全く非漢字は対象外と考えていましたが、現状では結構な非漢字が収録されています。「かな」など、明朝体向けのKAGEエンジンを使って技巧的なデザインをされていて感心しつつも、もったいないと思っています。非漢字について方針を決める必要がありそうです。
基本的には非漢字を収録する、という方向はとくにご異論はないと思いますが、その手段についてご意見をいただきたく思います。以前にも同じ話をしたと思いますが、単純に画像ファイルを登録する、という形式は、ライセンス違反のデータを受け付けやすくなる可能性が高いので反対です。
等幅の線と数種類の幾何学模様を使えるようにする、という考え方もあります。
以上いかがでしょうか--kamichi 2010年1月1日(金) 15:41

おもしろいと思います。
非漢字はいろいろな種類がありますが、デザインが簡単なものと難しいものがあります。カタカナなどは簡単ですが、ひらがななどは難しそうです。
tomomo_mysandbox@38で記号(地方港)を作ってみましたが、爪の部分のデザインがうまくできませんでした。そのようなデザインが簡単に出来るようになるのが目標ですね。
あと、u2011e@3のようなゴシック風の直線(曲線、接続、右払い)では、ありえない組み合わせですと表示されます。便利だと思うので、認めて欲しいです。--tomomo 2010年1月1日(金) 16:25

これ、本来は専用の線種を用意すべきと思うので、ペンディングとします。--kamichi 2010年2月12日(金) 17:12

私が以前平仮名を幾つか投稿したのは冗談みたいなもので、漢字の為の道具を使って工夫してデザインするのが楽しいからというだけの理由です。（だから最初は符号位置(u3042) ではなく砂場(sandbox@219) でやっていた訳ですが。）本気で収録しようとするなら、今のやり方ではいけませんね。漢字グリフの改良を目的に肉付けエンジンが更新されれば、こういった無理やりなグリフは崩れる可能性が有るし。
漢字以外も収録するなら、範囲をどこまでにするのか問題ですかね。私はせいぜい仮名と「々」ぐらい有れば充分ぢゃないかという気分ですが。まあ登録したい物が有れば登録するという事で、制限はしなくていいのかな。（ところで最初このウィキを見た時は、グリフって名前だから漢字に限らないのかとは思いました。）
一番柔軟性の有る方法は、ベジエ曲線で輪郭を自由に描ける様にするというものでしょうけど、実装も大変だしデザインも難しいし、良くないですよね。平仮名を作ってて「こんな機能があれば便利だなあ」と思ったのは、こんな感じです。

名前は「自由曲線」。
制御点を自由に増やせて、間は曲線で補間される。
個々の制御点に五段階ぐらいで太さを設定できて、間はなだらかに太さが変化する。
末端の形状は円と棊子麺〔きしめん〕から選べる。

— sayunu 2010年1月3日(日) 15:43
変体かなが作成され始めました。少なくとも「戸籍統一文字」「住基文字」で文字コードが振られています。これら以外の文字も多くあるため元とするグリフ名の命名規約を決めてはどうでしょうか。ためしに「hentaikana-u9999-yomi-999」とし作ってみました。hentaikana-u963f-a-001　また、元の字を関連字としてみました。 --tsuruki 2010年1月8日(金) 01:41
もし「hentaikana-u9999-yomi-999」とするのであれば、「hentaikana」は「hentaigana」と改むべきであると存じます。―lizard 2010年1月8日(金) 17:39

「hentaikana-yomi-uXXXX-999」を名前とし、関連字を「ひらがな」にするのが良いような気がします（漢字ではなく、かなとしてかなとして認識するためです）。--uchi 2010年1月8日(金) 18:16

現在関連字としてひらがなは指定できないようです。元の字を表示したときに「漢字」と混在して「変体かな」がぞろぞろ出るのは気持ち悪いような気がします。 --tsuruki 2010年1月9日(土) 11:22

質問ですがなぜ「hentai k ana」と清音にするのでしょうか。ローマ字表記時の濁音化をどうするかに関して一般的なルールが明示されていたら教えてください。--kamichi 2010年1月9日(土) 09:33

清音表記になったのは「変体仮名」ではなく「変体かな」と普段使用していたためです。「変体仮名」と「変体かな」で好みはありますがこだわりはありません。 --tsuruki 2010年1月9日(土) 11:22

明朝体縦線の太さ自動調整機能について

ついに着手しました。現状ではまだチューンアップが不完全かも知れません。不具合やご意見ありましたらお知らせください。
現状では垂直の「縦線、折れの縦線、縦左はらい」について、他の垂直の縦線とある程度接近している場合に細くしていきます。5段階（無調整含め）になります。同時に左はねの大きさも調整しています（ややイマイチ）。「折れ」については折れた後の横線は調整していません。--kamichi 2009年12月28日(月) 09:36
機能として落ち着くまでは既存グリフの再生成は行いません。--kamichi 2009年12月28日(月) 09:37

かなり美しく効いている場面も多いですね。でも、少し傾斜した縦画とか曲線にも反応できないと…。「酬」は縦画の詰まった字とされていますが、挟まってるのが点なので、縦画が細くなって呉れません。
それと、今回の更新からか、起筆形状「接続」の切り口が横画に沿わなくなってしまった様ですが。— sayunu 2009年12月29日(火) 13:22

コメントありがとうございます。今回のエンジン変更は、やや影響が大きく、早めに調整を進める必要があると思います。それで、上記不具合などが見られましたら、該当グリフを例示していただきたく思います。よろしくお願いします。「酬」の直線テスト版は調整の参考になります。いろいろアイデアは思い浮かぶのですが…--kamichi 2009年12月29日(火) 21:23
「接続」の件については、例えば u5bb6@5 の五画目の左拂いです。このグリフをそのまま編集プレビューで再生成させると、起筆部が水平でなく斜めに切り落とされる様になります。あるいは u5ba4@5 は、そうなってしまった状態で実際に投稿した物です。— sayunu 2009年12月30日(水) 14:25

確認しました。また理由もわかりましたので直します。ご指摘感謝。--kamichi 2009年12月30日(水) 14:30
修正しました。KAGEエンジンがややスパゲッティ状態になってきています。もし他に変なところがありましたらお知らせください。--kamichi 2009年12月30日(水) 14:44

垂直線から曲線に移行するところで段差が出来てしまいます。u4db5の龠の右下や

uchi

tomomo_mysandbox@27で試しましたが、折れ、乙線、縦払いの上に縦線を重ねると少々おかしくなります。

tomomo_mysandbox@28

tomomo

すみません、先の修正で間違えました。再修正しました。調整終了後に全グリフを再生成するので、おかしくなった分はそのままでお願いします。--kamichi 2009年12月30日(水) 23:25

車を細くすると真ん中の線のみ細くなります。u27216 --tsuruki 2009年12月30日(水) 21:07

ご指摘ありがとうございます。現状では仕様です。長い線と短い線の重み付けが必要かもしれません。--kamichi 2009年12月30日(水) 23:25

楚系文字について

kawamuraさんがitaijiで作成されているのは楚系文字と言われている物なのでしょうか？そうでしたら、それ用のプレフィックスを付けた名前があったほうがわかりやすいのではないでしょうか(その場合、甲骨文字や金文、秦系文字等も要るのかな)。

ご本人の意図も伺ってみたいところですが、おそらく楚系文字の翻刻字と思います。プレフィクスの案は賛成です。あと楚系文字は関連字が確定できない（あるいは揺れている）ものもあるのでやや扱いが難しいですが、グリフウィキとしては積極的に取り込みたいと思います。--kamichi 2009年12月22日(火) 14:39
もう一つ議論をお願いしたいのは、たとえば今回「-itaiji-###」の一部にすでにUCSに登録されているものがあります。これらは後でUCS側のグリフに移行するべきですが、その結果使わなくなった「-itaiji-###」の番号をどうするか（再利用するか、欠番とするか）です。再利用すると時間とともにグリフの指す対象が変化します。欠番とすると欠番であるという情報を付与する必要が出てきます。私の意見としては「-itaiji-###」はテンポラリなものと位置づけ、将来的により適切な命名グリフに移行することを前提とし、番号は再利用することを考えますがいかがでしょうか。--kamichi 2009年12月22日(火) 14:39

番号を再利用して字形が変わったり欠番になると、グループから参照されていた時や、外部から参照されていた時に問題になります。より適切な名前が見つかった場合はitaijiの方をエイリアスなどにして残しておくことを提案します。--mandel59 2009年12月23日(水) 15:18
そうですね。現状ではグループページでの引用についてはグリフ更新時に何も行わないので、それをどうするかとあわせて議論が必要と思います。とはいえ「グループページは自動更新しない、削除したitaiji-###は再利用しない」が妥当で、削除したものについて再利用できない（させにくくする）工夫の追加が必要と思います。--kamichi 2009年12月28日(月) 09:32

偏化変形、バリアントについて

すでに議論が行われましたが、それも踏まえて以下のような方針としたいと思います。

偏化変形命名グリフの設置には2つの目的があります

部品化に伴いデザインの変更が必要なグリフの登録
将来の自動生成で利用

デザインの変更がない場合は偏化変形グリフを独立して用意しません

なるべく汎用的な番号で登録してください

「-07：自由部品」と「-02：右」が同じデザインであるならばより汎用的な「-07」に登録し、「-02」は登録しません
現状で同じ部品を利用して位置だけの異なる別グリフが登録されているケースについては、議論が尽くされていないと判断し現状のままとします

漢字の部品結合は「左右」がほとんどなので、必然的に「-07」は左右部品の対象となりやすいのですが、左右幅を縮めるときに必要な修正を「-07」に施すと、上下部品として使いにくくなるので、この場合は「-08」に移設してください

結合相手との兼ね合いによる特殊なデザインのグリフは汎用的ではないので「-##-var-###」を使ってください

「-##」自体が存在しなくても、「var」を使ってください

「var」と「itaiji」の違いは、ユニフィケーションの範疇に収まる差異は「var」、それ以外を「itaiji」としてください。厳密な判断は難しいのでその都度議論することとします