各種議論の場として用意しました。個々の細かいルールはその都度決めていくということでお願いします。議論が終結したと判断したものはGlyphWiki:井戸端-保存に移動しました。
Unicodeにない戸籍統一文字等のIDS表現について
- Unicodeに存在しない戸籍統一文字(koseki-#####0)，住基ネット統一文字(juki-####)，登記統一文字(toki-0######0)，GTコード(gt-#####)について(以下，「戸籍統一文字等」とします)，私はIDS表現によるグリフを実体とし，これらUnicodeに存在しない戸籍統一文字等のグリフをそのエイリアスとするのが望ましい(例:
u2ffa-u8fb6-u9ce5を実体とし，
gt-52573をそのエイリアスとする)と考えますが，どうでしょうか。
- 私がIDSを優先すべきと考えるのは，IDSを用いればUnicodeに無い文字をUnicodeで疑似的に表現できるので望ましいと考えるからです。
- 以上，--spinda-kkmr 2013年4月19日(金) 18:29
JIS規格になくAdobe-Japan1だけに存在する漢字について
1年前、
ノート:u26c9eに書きましたが、返事がなくて井戸端で議論したいと思います。
𦲞(u26c9e) のように、JIS規格になくAdobe-Japan1だけに存在し、AJ1の字形がUnicode/ISOと異なると、AJ1の字形を優先するのはいかがでしょうか。AJ1は日本語表記に使われている文字を集めている集合なので、準JISみたいなものだと思われます。ちなみに、メイリオもそんな実装をしているようです。 --johotogoshinentai 2013年3月26日(火) 10:48
- ちょっと考えてみましたが、Jソース(JA、JHソースなど)とAJ1の字形異なると、JソースとAJ1のどっちを優先するほうが良いでしょうか。 --johotogoshinentai 2013年3月31日(日) 00:34
CJK互換漢字の字形の扱いについて
CJK互換漢字の無印グリフ（ないし、無印廃止後に花園フォントにおいて採用されるグリフ）の字形の扱いはどうなっているのですか？
互換漢字は統合されないにも拘らず一つのコードポイントに複数のソースが与えられています。無印グリフにjv字形を適用しないとしたら、いずれのソースを典拠にするのかを決めなければなりません。そもそも、互換漢字の無印グリフはそれがどこのソースに基づくものかすらグリフページからは分からないわけですから、いずれにしても現時点で統合漢字より、地域ソースグリフ作成の必要性が高いと思います。
現状の互換漢字は、無印グリフが無秩序な状況になっていると思います。たとえば
u2f88bはjvでもUCSソース（tとkp）でもない中途半端な字形です。またこの字について、UCSソースにあたる字形を持つグリフは現在存在していません。あるいは
u2f9bcは、TソースとHソースがある中でTソースが“恣意的に”採用されている状態です（Hソースは「ヨ」の中の棒が飛び出ません）。それともこれにはHソースではなくTソースを選ぶ特別の理由があるのでしょうか。
互換漢字の字形はどのようなものにするのかを決めてガイドラインに示すこと、そして全互換漢字について地域ソースグリフを作成していくことが必要だと思いますが、どうでしょうか。--kirikaxfan 2013年3月23日(土) 13:13
- ちょっと説明(解明？)します。互換漢字は、「その互換漢字がどんな字形の違いを目的としてエンコードされたか」をde factoの原則(？)としてきました。たとえばu2f88bは、
u5eb0-tとは「并」と「幷」の違いでエンコードされているものです。ですので、「并」と「幷」の違いを反映し、それ以外の違い(この字の場合、
u5e7f-05と
u5e7f-t05の違い)は反映しません(u5e7f-t05を使うと、ほかのグリフとのデザインが一貫性がなくなることもあります)。
- u2f9bcにTソースの字形が反映されているのは、もともと「CJK互換漢字補助」領域の文字は、複数欄ではなく、Tソースの字形しかなかったからです。ですのでTソースの字形に合わせられています。
- 互換漢字について地域ソースグリフを作成していくのは全く問題ないと思います。 --johotogoshinentai 2013年3月23日(土) 14:00
- まず、ここで使われている「エンコード」という言葉の意味が分かりません。「符号化」＝「コードポイントを与える」という意味ですか？
- であれば、之繞はどうです？KS X 1001用互換漢字は、統合先との間に字形の差を与えないものです。しかしその一つである
uf99aは、
u9023に統合される互換漢字であるにも拘らず、統合先とは異なり二点之繞になっています。これはどういう理窟ですか。
- またu2f9bcについては、理由は分かりましたが、私が言いたいのはそういうことではなく、では現時点にあって、それでいいのですか？ということです。「理由」ではなく「根拠」の問題として、歴史的にではなく論理的に、今TソースとHソースが対等の立場なのであれば、今Tソースが選ばれていることは“恣意的な状態”ではないですか、ということです。もし今、このグリフをTソースにしたい人とHソースにしたい人が現れて編集合戦を繰り広げたとしたら、どちらに決着させるのですか、ということです。もし現時点でそれに答えがないのだとすれば、これは普遍的な問題ですから、新たにルールを定めて解決する必要があるはずです。
- どうでしょうか。--kirikaxfan 2013年3月23日(土) 15:01
- 「符号化」のことです。
- 字形の差について、ちょっと補充します。「その互換漢字がどんな字形の違いを目的として符号化されたか。(仮想)J字形で使われているデザインなら、その差も反映する。使われていないと、その差は反映しない。」つまり、「なるべく元の字形を反映し、(仮想)J字形と合わない差は反映しない」ということです。2点之繞はJ字形でも使われているので、問題ないと思います。実際、メイリオなどもuf99aは2点之繞にしています。
- それについてはちょっと考える必要がありますね。 --johotogoshinentai 2013年3月23日(土) 15:59
- （インデント戻る）だからそもそもuf99aとu9023には「差」がないんでしょう！韓国ではu9023も二点之繞でしょう。K0-5627は確かに二点之繞になってますよ。GlyphWikiにグリフもありますよ（
u9023-k）。このグリフはuf99aと互いにエイリアスですよ！そりゃそうですよ“読み方”が違うだけなんですから。意図された字形の差なんてあるはずがない。差がないのに、「差として反映される」って、一体どういう理窟なのですか。johotogoshinentaiさんは韓国の方でしたよね。韓国のフォントではそうなっていないのですか？
- すみませんが、私はこの辺りでひとまずこの議論を離脱します。好んで編集合戦をする気はありませんが、当面この一連の問題について独断的にリバートを通告されても関知しませんので、編集内容に問題があるとお考えならば皆さんで議論して結論を出し、ガイドラインに成文化してください。私の編集のやり方はその段階で考えます。これがGlyphWikiに相応しくないと判断されるならばBANしてもらっても結構です。
- ノート:ufa5eにおける議論も収束はしていませんが、まとめてここで離脱を宣言します。ただ最後に最低限はっきりさせておくべきことは、互換漢字をエイリアス実体とすること、特に“排他的に”そのようにすることには私は複数のレベルで違和感を持っているということです。議論に集中していて曖昧なままになっていたのでここに記しました。以上です。--kirikaxfan 2013年3月24日(日) 19:45
- ご指摘ありがとうございます。私の中途半端な説明で気分が悪くなりましたら本当に申し訳ありません… 私は慣習や慣用などを規則として定立しようとすると、見落としが発見されることが多いので…
- 離脱を宣言しましたが、いったん改定案(？)を書いておきます。
- 意図した字形に違いがあると：「その互換漢字がどんな字形の違いを目的として符号化されたかを重点にする。(仮想)J字形で使われているデザインなら、その差も反映する。使われていないと、その差は反映しない。」
- 意図した字形に違いがないと(主にKS X 1001の重複漢字)：「できるだけ元の字形を反映する。ただし、(仮想)J字形で使われているデザインだけを反映する。」
- これで良いでしょうか。 --johotogoshinentai 2013年3月25日(月) 01:34
- 私が前段に書いた内容論の表現はレトリックです。口語的な表現の方が焦点の置き方が分かりやすいというのが根幹にありまして。許容範囲内とは思っていますが、攻撃的に見えたかもしれないので、その点お詫びしておきます。失礼しました。
- 提案がなされていますが、この問題はかなり大きな問題、根本的な問題を含んで一筋縄にはいかないように思うので、私としては引き続き意見の表明を控えさせていただきます。申し訳ありません。--kirikaxfan 2013年3月27日(水) 09:21
メタ情報の削除について
- 荒らしによってノート:aj1-20072に書き込まれたメタ情報を削除しようとしてもできません。これは仕様でしょうか? --spinda-kkmr 2013年2月28日(木) 19:01
- あれ？普通に白紙化できましたが、どのような状況でしょうか。（私はJavaScriptを切っているのでそれでOKだったのかもしれませんが…）--kamichi 2013年3月1日(金) 07:46
- 先ほど，匿名の状態でsandboxにメタ情報を書き込み，その後ログインして編集を試みたところ，正常に削除できました。ノート:aj1-20072の時はメタ情報が存在するにもかかわらずノートページにメタ情報が表示されませんでした。原因は不明です。--spinda-kkmr 2013年3月1日(金) 18:24
IVDグリフにおけるエイリアス・被エイリアスの優先について
- IVDとAJ1文字集合、戸籍統一文字などの関係において、どちらが主（実体グリフ）となるべきでしょうか。過去に言及された方はいますか？一見後者の方が字形の安定性がありますが、IVDは理論的には全く同じ字形になるので、前者を主としても構わないと思いますし、グリフウィキではUCSをベースに位置づけているのでより適切かと考えます。--kamichi 2013年2月23日(土) 15:30
- IVSグリフについては、私は現状に反して、IVSを実体とすべきではないのかなと思っていました。公共性も安定性もIVSだと思います。UCS優先なら尚更です。問題はソースがやや不明瞭（？）であることでしょうか？戸籍統一文字やCJK統合漢字のCode Chartsより汚いと思います。--kirikaxfan 2013年3月11日(月) 22:45
- 私もIVSグリフについて，IVSグリフ“u(2)####-ue01##”を実体とすることには基本的には賛成です。ただし例外として，JIS X 0208:1997字形“j90-####”(以降，旧JISとします)が含まれる場合は，例外としてそちらを優先するのがよいと思います。現在の日本語の情報機器の環境は，WindowsPCの多くはJIS X 0213:2004字形(以降，新JISとします)ですが，携帯電話などのモバイル機器では今でも旧JISがほとんどです。また，印刷物では旧JISと新JISが混在している状況です。ですので，旧JIS・新JISに関わる“j90-####”のうちグループ:JIS2004で例示字形が変更された文字に含まれるものについては，こちらを優先して“j90-####”を実体にするのがよいと思います。--spinda-kkmr 2013年3月27日(水) 19:34
- 追記。Jソースが存在するUnicodeのコード位置については，Jソース字形の無印UCSグリフを優先して実体とすべきと思います。--spinda-kkmr 2013年3月27日(水) 20:21
- 追記。前言とは意見が少し変わることになりますが，実体になると分かりにくいのは戸籍統一文字“koseki-#####0”や住基ネット統一文字“juki-####”などなので，「その字形が汎用電子にのみ存在する場合はIVSを優先するが，AJ1に存在する字形，またはJISのバージョン間で字形が異なる場合は，無理にIVSを優先しない」でどうでしょうか。「溢」等は，
j78-306e，
j90-306e，
jx1-2004-306eのようにJISのバージョンによって字形が異なるため，このようなグリフはJISを優先して実体化するほうが望ましいと思います。--spinda-kkmr 2013年4月20日(土) 10:48
- 追記。
ufa5bや
ufa5fのようにCJK互換漢字に存在する字形の場合は，CJK互換漢字コード位置のグリフを優先して実体にすべきと考えます。IVSに比べれば互換漢字のほうが利用できる環境が多いのでより重要と考えるためです。--spinda-kkmr 2013年4月20日(土) 11:01
KAGEエンジンの新しい改造内容について（2/12更新）
sandbox@1130のように、99で引用した部品について、ストレッチ機能を追加しました。中心(100,100)から第2項目をX座標、第3項目をY座標（ただし中心からの差分）で表現される座標に向けてリニアに変形させます。たとえば「99:-20:0」とすると左に圧縮します。「99:0:-20」とすると上に圧縮します。圧縮の端は0,0や200,200の外枠ではなく、その部品の最端座標になります。
大変申し訳ないのですが、現在のグリフエディタにこの機能を追加することができません（あまりに煩雑すぎて断念しました）。ですのでしばらく手作業になります。（根性でなんとかグリフエディタでも反映できるようにしました。99部品を選択すると真ん中につまみが表示されるので、それを0,0-200,200の範囲内（目安）で動かしてください。
- 現在試行中とし、しばらくしてこの機能がメリットがあるかないかを判断し、ないということでしたら廃止します。--kamichi 2013年2月1日(金) 22:09
- やはり中心から、というのは無理があるかもしれません。任意の点から任意の点への変形でしょうか。また、１つではなく２つ、という要望も出そうですが、そうすると現状のKAGEでは座標が足りなくなってしまいます。たとえば全面引用（0,0-200,200）のみ変形を認めるなどの限定が必要と思います。--kamichi 2013年2月2日(土) 00:29
2/2の変更
大変ご迷惑をおかけしました。99番による部品引用時のストレッチ機能に2種類用意しました。
- Aモード：中心点(100,100)から任意の1点に向けてのストレッチ
- Bモード：任意の点から任意の点に向けてのストレッチ
後者は例えば左右２部品の左右のバランスを変更するなど、いろいろ応用ができます。
使い方ですが、まず９９部品を選択すると灰色のつまみが中央に現れます。これを操作するとAモードの調整となります。つまみを右（X座標でいう２００以上）に持っていくとつまみが左にワープし、同時に中央に黄色のつまみが現れます。これがBモードです。黄いつまみが元の基準となる点を表し（黄つまみを動かすと灰色つまみも同じ位置に動きます）、灰色つまみがストレット先を表します。まず黄つまみで部品内で分割する位置を指定し、いったんマウスクリックを離し、再度クリックすると灰色つまりを動かせますので変形します（２つのつまみは全体（200ドット四方）に対するものなので、部品を100%の大きさにしてからでないとイメージがつかめずうまく調整できないと思われます）。
BモードからAモードに戻すには、灰色つまみを左（０以下）に動かします。
- 問題点として、上級者以外の人にとっては、変形機能よりも変形され終わった部品が用意されている方が便利、と思うことでしょうか。--kamichi 2013年2月2日(土) 18:07
- ちょっと自由度が高すぎますね。グリフウィキの理念とは若干ずれてしまっている気がします。パラメータ１つぐらいで調整できる範囲が望ましいかと考えます。--kamichi 2013年2月3日(日) 17:16
- 私もそう思います。構えや繞を調整するためならば，ストレッチ機能はAモードだけでもよいと思います。そうなると今までにBモードで調整されたグリフを再調整する必要がありますが… --spinda-kkmr 2013年2月3日(日) 19:06
- ありがとうございます。昔KAGEシステムが自動合成を主としていたときに、はめ込み用の枠（四角）、というものを設定できました。他の部品と組み合わせるとその部分にいれる、というものです。逆に言うとその枠を拡大縮小するような仕組みでいいのかとも思います。個々の筆画に影響を与える変形は上級者すぎるかなと思います。--kamichi 2013年2月3日(日) 21:39
いったん使用停止でお願いします
まだ議論は途中と思いますが、いったんストレッチ機能は新規の使用は停止して、再検討したいと思います。今考えているのは、グリフに新しい線分を設定できるようにします。この線分は始点と終点の２点で構成されます。視覚上はなにも表示されません。変形の度合いが０％〜１００％に相当します。つまり変形Bタイプの黄色の点が始点に相当し、灰色の点が終点に相当します。そして９９部品として利用するときにスライダで０％〜１００％の範囲で変形度合いを調節する、というものです。線分上をスライダでそうさするか、X軸とY軸に分けてスライドできるようにするか悩んでいます。--kamichi 2013年2月3日(日) 23:16
- 自由度が相当高いから、かなりデザインの得意な人が慎重に使わないと、グリフ同士の統一性が損なわれる恐れが有るなあなどと思っていました。それで私が考えていたのも、部品側に基準点と変形方向の情報を予め持たせるという案で、多分 kamichi さんが考えていらっしゃるのと似た話だと思います。
あるいは、変形度合いの異なる二つの部品グリフを参照して、マルチプルマスターみたいに補間する機能が有ったら、応用性と、簡便さと、デザインの統一性を満たせるかも知れません。ちょっと複雑ですけど。（ニンベンの右側には「去」と「去-02」の平均を使うとかいう事も…。）— sayunu 2013年2月4日(月) 00:02
- 仮にそうやるとしたら、二つの分離したグリフを参照するのではなくて、一つの部品グリフ内に二つのマスターを纏めて持っておくというシステムの方が良さそうですが、大きな改修になりますかね。— sayunu 2013年2月4日(月) 00:31
- いや、マルチプルマスターはまた別の話にした方がよさそうですね。単純な変形機能に関して言えば、変形方向に「斜め」って必要でしょうか ? モンガマエ・トラガシラ・シンニョウみたいな大抵の場合は垂直か水平だけでまかなえると思いますが、問題はヤマイダレとかでしょうか。タレの類はかつて「どれぐらいのバリエーションを用意すればいいか検討しないといけないなあ」と思いながら放置してしまったので、まだ自信を持って言えないのですが、ヤマイダレって実は縦の調整はそんなに要らないのではないかという印象が有ります。斜めが可能で困る事も無いでしょうけど。縦横別々に調整できる必要は無さそうに思います。
調整スライダーは、0〜100 の 101 段階という事でしたら、細か過ぎるのではないかと思います。0〜10 の 11 段階で足りるでしょうし、0〜5 の 6 段階ぐらいでもいい気がします。
部品を作る上では、もしかしたら「始点から終点まで」よりは「基準点からプラス方向とマイナス方向へ」変形できるしくみの方が扱い易いかも知れません。普通は中庸な大きさで部品をデザインしますし…。線分の中心点を基準にするとか ? いや、でもあまり自信は無いです。— sayunu 2013年2月4日(月) 06:18
- ご意見ありがとうございます。正負両方、荒めに調整、同意します。それで、XとYの分離が必要かどうか、ですが、よくわかりません。たとえば「まだれ」や「しんにょう」などの２方向囲いなどで必要か？と考えました。といっても囲うものはだいたい矩形ですので１軸でいいのかな？まず１軸で実装し、足りないと言うことであれば分離を検討、とも思います。--kamichi 2013年2月4日(月) 08:46
例:
ufa66 -> 65,100(L) LだけなのでX軸のみ。Y座標は無視される。X座標65から左端(12)の方向にストレッチ
2/12の変更（第３世代）
- 手を入れました。KAGEエンジン自体の変更はなく、あくまでグリフエディタにおいて今までのような詳細な変形をできなくしました。
- まずグリフのメタ情報に「ストレッチ境界」という属姓名で境界となる座標(x,y)とそこからのストレッチの方向（UDLRで上下左右。２つ指定すると四隅を指定）を指定します。
- その情報があるグリフについてはエディタで99部品として選択したときにストレッチの段階を-10〜10で変更できます。なお、すでに第2世代までで値を設定していた場合、今後メタ情報をセットして部品エディタで選択すると値が壊れますので、再度-10〜10で調節してください。
- まだ試行とします。各ユーザーの試用をお願い致します。--kamichi 2013年2月12日(火) 01:42
- メタ情報のセットが面倒なので、あまり使われていませんが、まずは大きな問題無しということで、このやり方での運用を行いたいと思います。メタ情報のセットのし易さについて機能追加を検討したいと思います。--kamichi 2013年2月15日(金) 08:23
UCSの地域＋偏化変形グリフについて
vnpf-60838→
u7fdf-v02→
ufa1e-v03という引用をvnpf-60838→
u7fdf-02-var-002→
ufa1e-03-var-003と変更しました。これは、「-jv」の設置により「地域ソースは規格表で規定されているものに限る」という方針を偏化変形にも適用したためです。
u7fdf、
ufa1eにはVソースはないので「地域＋偏化変形」グリフは登録できないと思います。しかし皆さんは今までは仮想地域字形として使われてきたかもしれません。
本来「偏化変形＋地域」グリフの場合、規格表でその字形が規定されていません。また地域字形にあたるものを地域指定ではなく「-var-###」に持ってくると、「-var-###」が日本では使わないものが並んで濁ってしまうことも考えられます。仮想地域字形を規定するのは面倒ですし、どちらの方針にするか悩みます。
以上ご意見ありますでしょうか？--kamichi 2013年1月20日(日) 16:25
- 部品グリフの例示ソース指定って、その欄で見受けられる部品の形状ではなくて、親字の特徴を引き継いだ部品を表すんですね。ソース指定と地域指定を別に用意するとしたら…しかし V 欄がベトナム字形の代表として妥当とも限らないし、或る字形を「ベトナムで通用している字形である」と認定するのは我々には中々難しいですね。
連番で var をガンガン作っていくとしたら、ガンガン作ってもゴッチャにならないユーザーインターフェイスが欲しいものです。— sayunu 2013年2月2日(土) 19:06
キャッチフレーズのこと
新しいロゴを kamiyo さんが作ったそうでお疲れ様です。悪くないと思います。（仮名が旧版なのが残念ですけど…。）それで、この「漢字グリフ登録管理サイト」というフレーズはこれが最も良いんですかね ? 初見の人にもこのサイトの目的が端的に伝わるといいなあと思うんですが、「登録・管理」よりは「共有」を前に出したらどうでしょうか ? 例えば「フリー漢字グリフ共有サイト」みたいに…。このシステムの売りは「登録できる、ヤッター」でもなく「管理できる、ヤッター」でもなくて、最終的に「共有できる、ヤッター」でしょうし。— sayunu 2013年1月14日(月) 17:52
- ご意見ありがとうございます。これ、人によって若干違うでしょうね。私は「自由」という文言を是非入れたかったのですが、どう入れるか悩み、やめました。文言の決定は私の責任だったので、私の考え不足ということになります。もしもっと良い文言がありましたら、kamiyoさんにお願いして文字だけ差し替えていただこうかと思っています。--kamichi 2013年1月14日(月) 17:59
- ええ、自由（フリー）という表現は是非欲しいです。少なくとも私が考える限り、自分の作るデータを権利放棄してまでこのウィキに預ける事は、本人にとって利益にならない慈善行為ぢゃないですか。このサイトに載っているデータをどこの誰でも手軽に自由に無料で使える様にという目的の為に「登録」も「管理」もやっているんですよね ? データを登録する人よりも、データの恩恵を受ける人の方が多くなってくれないとしょうがない訣で…。
…あ、いや、そうか、このシステム上で独自の漢字字形データを「管理」できるのが売りの一つなんでしょうか。その意図は気付かなかったです、すいません。— sayunu 2013年1月14日(月) 18:48
- ロゴを確定して、１００万レコード、３０万グリフ達成記念にロゴを印刷したマグカップを作ろうと考えています。ということで、このキャッチフレーズを詰めなければいけないのですが（笑）、「漢字字形自由共有サイト」「漢字字形自由共有網頁」「漢字字形自由共有ウェブ」「漢字字形自由共有Web」「漢字自由共有網頁」「文字自由共有網頁」では意味不明ですかね… --kamichi 2013年1月22日(火) 17:14
- うーん、その中で選ぶとしたら、一番奇異な感じがしないのは「漢字字形自由共有サイト」でしょうかねえ。「網頁」を使うとしたら、「サイト」ってルビでも振りましょうか。— sayunu 2013年2月2日(土) 18:24
- ありがとうございます。特に他にコメントもないので「漢字字形自由共有サイト」にしたいと思います。--kamichi 2013年2月10日(日) 21:47
- ロゴを更新しました。kamiyo様、ありがとうございます。--kamichi 2013年2月11日(月) 16:04
白紙化の抑制について
異論も多いと思いますが、実運用で気になったので、明確にできればと思います。重複しているグリフの白紙化をどうするか、という問題はこれまでにも出てきました。これまでは意味のある重複は白紙化せず、「-itaiji-###, -var-###」に多く見られるただの重複については、白紙化を否定せず、ということでした。グリフウィキ上ではこの方針で構わないと思うのですが、実際にWebでグリフ画像を引用している場合に白紙化されてしまうと非常に面倒です。ですので、今後は「間違い等ではない限り、重複グリフを白紙化しない」という方針に転換したいと思います。同時進行で命名ガイドラインから命名ルールへの移行も想定しているため、それほど混乱は起きないと思います（結局「itaiji, var」あたりで番号を自由につけられる関係上、重複が発生しやすい。そのうち無法地帯になる可能性もある。他の命名を行ったグリフについては「itaiji, var」を作成しない、というルールも必要か）。コメントありましたらお願いします。--kamichi 2013年1月1日(火) 15:43
- とりあえず、それでよいと思います。— sayunu 2013年1月12日(土) 01:33
- 異体字グリフ「-itaiji-###」「-var-###」についての白紙化しない件、了解しました。
ちなみに、過去に白紙化されてしまったものに関しては、如何致しましょうか。もし、白紙化を今後行わないと言う方針に決定した場合、過去に白紙化されたものに関しましても異体字連番の欠落状態を解消する為、白紙化異体字グリフを復活させた方がいいのでは…と思いました。
特に異体字作成の際、表示されている異体字番号の次の番号でグリフ作成しようとしたら、以前に白紙化されていた(例えば「uxxxx-itaiji-001」「uxxxx-itaiji-002」が表示されており、「uxxxx-itaiji-003」を作成しようとしたら、実は「-003」は以前に白紙化されていた)と言う事に幾度か遭遇しましたので、少々気になっておりました。--kamiyo 2013年1月12日(土) 11:05
- 「間違い」には，varとitaijiの使い分けミスも含まれるのでしょうか? やはりUnicodeで包摂されるかどうかはきちんと運用されるほうがよいと思うので… なお，私はitaijiで表現されているグリフをIDS表現に直すことがありますが，その場合でも元のitaijiはエイリアスとして残すようにしています。--spinda-kkmr 2013年1月12日(土) 11:08
- 難しいところです。個人的には「間違いによる白紙化の是非」は「間違いの種類」ではなく「間違ってから戻すまでの時間」によると思います。つまり、気がつかずに放置してしまった間違いを長い時間が経ってから白紙化するのは望ましくない、という意味です。システム上「削除」を「0:0:0:0」で判定しているので難しいのですが、白紙化するのではなく
u342c-02@3のようなやり方もあるかなとは思います。ということで登録時に間違えて、というものはすぐに直せるので白紙化許容とし、時間が経ってしまったものはまずはノートで議論、ある程度問題となるケースの種類がしぼられてきたら再度ルール検討、でいかがでしょうか。あと、白紙化したものを連番で間違えて復活してしまう件はシステム的に補助できないものかと考えます。--kamichi 2013年1月22日(火) 17:21
- 改めて考えましたが、画像が外部から参照された場合については白紙化直前のバージョンを返すという事は出来ないんでしょうか。ウエブ上で参照できる個別のリソースとしては URL が変らないのが望ましいですけど、データベース全体としては常に最も整理された最新の状態であってほしいですよね。
これまでの私の暗黙の方針では、「-02」「-07」などの部品グリフは自立グリフと違って部品専用だから、外部から参照される事などは考えずに、内部的な部品としての使い易さだけを重視して整理・改名していました。どうなんでしょう。— sayunu 2013年2月2日(土) 18:17
- sayunuさんの意見に賛成です。本来varを使うべきものにitaijiが使われている例が存在するので，そのようなグリフはきちんとvarに移動したうえで白紙化するのが望ましいと考えております。白紙化されたグリフは白紙化直前のバージョンを出すようにすれば，データベースとしての正しさとグリフの安定性を両立させることができます。あるいは，「管理者または他の利用者の判断により白紙化されることがあります。確実にグリフを指定したい場合はバージョンを指定してください。」と注意書きを載せれば，とりあえずは大丈夫だとは思います。--spinda-kkmr 2013年2月2日(土) 18:54
古琴減字譜(GEOG-QIN)の命名規則について
古琴減字譜「geog-qin」のグリフと、減字譜を先日から少々調べていたのですが、現状追加出来ていないグリフが有るものの、現在のグリフ名の付け方の場合ですと、追加が困難であり、改番をした方が良さそうに見受けられました。
そこで「geog-qin-#####」から「qin-#####」へ移行する際、グループ:kamiyo_temp@2の様なグリフ命名規則に変更すると、追加が容易になるかと思われますので、命名変更の提案をさせて頂きたいと思います。如何でしょうか？--kamiyo 2012年12月16日(日) 01:24
- 賛成です。ですが、もともとの作成者の方がこのドキュメントを見ているかどうかが気になります（仕方ないですね）。あと、現状のグリフについている関連字というのは妥当なのでしょうか？--kamichi 2012年12月29日(土) 23:47
- 関連字についてですが、現状は呼称が漢字1字の記号は、
(「蠲:
geog-qin-0160」→関連字「蠲」、「剔:
geog-qin-0030」→関連字「剔」 など)、
その呼称を関連字として割り当てられており、呼称が漢字2字以上の記号は
(「撥剌:
geog-qin-2016」→関連字「撥」、「滾拂:
geog-qin-0580→関連字「滾」、「挑四弦:
geog-qin-0014」→関連字「挑」、「大指当十二:
geog-qin-1112」→関連字「大」 など)
呼称1文字目を関連字として割り当てられおり、「関連字」としては妥当かと思います。但し問題は、記号によって(特に「大」「中」「名」など)80個近くが同じ関連字に割り当てられており、(減字譜以外)他の漢字(国字、字喃等含む)異体字グリフを探す事が少々困難になっておりますで、減字譜(geog-qin)に関しては関連字を外して、グループ:古琴減字譜(又はこのグループの派生グループ)にグリフを貼付する事で、これ等を解消すると言うのも良いかと思われます。--kamiyo 2012年12月30日(日) 13:40
- 次はこのグリフ群の新命名への移行に着手したいと思います。--kamichi 2013年2月11日(月) 13:42
- (done)新命名での旧命名へのエイリアスをはる(グループ:kamiyo_tempに沿って。一部新たに追加されたグリフも対象）
- (done)エイリアスの向きを逆転
- 引用部品名の更新
- 白紙化（geog_にコピーするか要検討。いらないのでは？）
- 関連字についてはメタ情報に記述し、関連字自体を削除したいと考えます。２、３個の記述で良いと思います。呼称、組み合わせの文字群、などでしょうか。--kamichi 2013年2月11日(月) 14:11
- Hello! Sorry that I'm not familiar with Japanese and not certain if this is the correct way to join in the discussion. I was tied up and have put down the creation of qin tablature for a while. Thank you very much for Kamiyo's suggestion. I have to admit that my project is a evolving one and could have a better rule. I would like to join in this discussion with a view to creating a set of open source qin tablature characters. --Daniel(利用者:geog) 2013.3.11-0357GMT+8
KS X 1001規格票例示字形(k0-####)のコード位置番号表記について
現在，KS X 1001規格票例示字形“k0-####”のコード位置番号は，区点番号で表記されています。
しかし，CHISE character descriptionやchise_linkmap，およびUnicodeの規格票では，KS X 1001のコード位置はGL領域の番号で表記されているようです。“k0-####”も，“j78-####”や“j90-####”のように，GL領域の番号で表現したほうがよいのではないでしょうか。
以上，--spinda-kkmr 2012年7月27日(金) 19:34
- ちょっと話が飛んでいるかもしれませんが、私は、k0-####は必要ないと思います。韓国の規格は文字が重なる場合がないからです。u####-kで十分だと思います。
- できるだけ重複グリフを避けたほうが良いと思っています。--johotogoshinentai 2012年7月29日(日) 12:05
- 2つの議論を分けて考えたとして、個人的には「k0-####」が「u####-k」で完全に代替できるなら、韓国ソースについては「u####-k」に一本化するということで構わないと考えます。現時点で、「完全」には代替できない、という情報をお持ちの方はいらっしゃいますでしょうか？また、重複グリフについては意見が分かれそうなので、ここでは取り上げないものとしてみます。--kamichi 2012年8月19日(日) 12:51
- 以前，johotogoshinentaiさんが指摘したことですが，KS X 1001の規格票の草冠は3画草冠
u8279-03なのに，ISO/IEC 10646のKソースは草冠がほぼ全て4画草冠
ufa5e-03になっています。したがって，KS X 1001の字形とISO/IEC 10646のKソースは異なると思います。--spinda-kkmr 2012年8月21日(火) 19:22
- もとの話題に戻しますが、区点表記とGL表記とどちらがいいでしょうか。統一するということでGL表記に移行することに賛成です。ある程度たくさんあるので機械的に移行することになると思います。--kamichi 2012年12月4日(火) 08:49
- この件ですが、GL表記に移行します。機械的に行う（autoglyph-botによる、新規登録と白紙化）予定です。--kamichi 2013年1月1日(火) 16:21
- 移行が完了しました。--kamichi 2013年2月11日(月) 11:59
匿名利用者の若干の非匿名化について
以前、匿名利用者はアクセス元IPアドレスを表示していましたが、これをやめて「匿名利用者」以上の情報を出さないようにしました。これに関して、スパム投稿の前後の匿名利用者の投稿が真面目なものかそうでないものかの判断が難しく（管理者以外の一般ユーザーは）混乱すると思います。そこで、そのIPアドレスが昨日までに投稿の実績があるか／ないかで、新規匿名利用者、ベテラン匿名利用者と、２つに分別して表示するようにするのはどうか（新規はスパム率が高いのでより注意して投稿を見守るという目安になる）と思いますが、いかがでしょうか。なお、これはポリシーの大きな変更なので強い賛同がない場合は実施しません。また「GlyphWiki:」ページは匿名利用者は投稿できませんのでそのことも踏まえて結論をつけたいと思います。ご意見よろしくお願いします。--kamichi 2012年5月15日(火) 20:31
- 賛成です。新規匿名利用者については，“-var”，“-itaiji-”による異体字の作成に制限を設け，根拠を示しておらず，他の利用者も根拠を確認できない場合は，信頼性が無いと判断して白紙化する，というのはどうでしょうか。匿名利用者による異体字は，信頼性が低いと考えます。--spinda-kkmr 2012年5月19日(土) 11:47
- これは別のものかもしれませんが、UCSグリフを匿名利用者が編集できないように制限するのはいかがでしょうか。UCSグリフは引用度が高く、荒らされると大変不便になります。 --johotogoshinentai 2012年5月21日(月) 09:41
- 今朝は匿名利用者によって
u9759が
u975c-ue0102のエイリアスになってしまって、u9759をエイリアス先としていたエイリアスグリフは全部u975c-ue0102のエイリアスになってしまいました。(今は私がすべて直しておきました。) このような場合ではエイリアス関係も複雑になってしまいます。UCSグリフを匿名利用者が編集できないように制限する必要があると思います。 --johotogoshinentai 2012年5月23日(水) 11:49
- 難しいですね。２つコメントがあります。（１）あまり複雑な制限のかけ方は混乱すると思うので、わかりやすい制限を。（２）匿名者への制限はカジュアルないたずらには対応可能だが、本気を出されたら登録ユーザーに移って同じことをされるだけなので、根本的な解決にはならないかもしれないこと。現実に長期にわたっての匿名スパムユーザーが実在しています。
- 匿名の人はsandboxおよびguest-001～100の編集のみに閉じるという制限も検討の1つかと思います。既存データへの編集協力はユーザーになってもらい、一方でちょっとグリフが必要というニーズにも対応できるかと思います。あとは、ユーザー認証をするけれどもユーザー名を出さないで編集する、という半匿名という概念があっても良いのかもしれません。--kamichi 2012年5月24日(木) 08:04
- 悩ましいところですが、匿名利用者が投稿した場合は、強制（自動）的にsandboxに登録する、というのも１つのやり方かと思います。要旨に真っ当な記述があれば登録ユーザーが適切な命名にコピーする、というものです。--kamichi 2013年2月18日(月) 08:35
GやTやVソースの字形を忠実に再現することに関して（再考か否か）
現在、以下のデザインはデザイン差としてグリフウィキでは認めないとしています。個人的に見つけ次第強めに排除しているつもりです。
- Tデザインの口右下
- 不可：横棒が飛び出る
- ガイドライン：普通に右下角を使う
ですが、戸籍統一文字や登記文字を見ていて、迷っています。この方針に関して意見のある方は教えてください。なお、私が拒絶する理由はたとえばTデザインの口を許容すると、あらゆる「口」を含む漢字が単純2倍になってしまう、と感じるからです。--kamichi 2012年3月29日(木) 21:19
- 私の案としては以下のとおりです。
- Gソース，Tソース等の字形は，上記のガイドライン通り一定のルールのもとで再現する。
- 戸籍統一文字，住基ネット統一文字，登記統一文字(以降，行政系文字コードとする)は可能な限り忠実に再現する。ただし，戸籍統一文字は必ずしもデザインが整ってはいないので，見た目を良くする程度の差異は許容する。
- 行政系文字コードを正確に再現すべきと考える理由としては，行政系文字コードには包摂・統合の概念が無く1つのコードに対しただ1つの字形が存在するためです。
- また，大規模文字セットであるGTコードについても，GT書体は若干クセのある字形ですので，グリフウィキでどう扱うかを考えるべきだと思います。たとえば，GTコードでの「好」の字(gt-07641)は
sandbox@996のようになっており，
u597dとは女偏の形が異なっております。しかしGT書体は画数を明確にするために恣意的に通常の明朝体とは字形を変えてある場合もあり，必ずしも厳密に再現すべきかどうか判断に迷うところです。
gt-12636と
u5f71のように，接触・非接触の違いの場合は再現すべきと考えますが，女偏のように部首全体の字形が異なる場合は，デザイン差としても構わないと思います。ただし，GTコード自体には包摂の概念はありません。
- なお，GT書体の一覧は，こちらのサイト
で公開されています。
- 以上，--spinda-kkmr 2012年3月31日(土) 12:36
- 追記。GTコード系のフォントではJIS第1・第2水準の文字に対しUnicodeの配置通りのフォントが作成されています(他の文字はシフトJIS領域に対し別の字を割り当てている)が，たとえばsandbox@996(gt-07641)はu597dに割り当てられています。--spinda-kkmr 2012年3月31日(土) 12:44
- GT書体の字形について分かりやすくまとめますと，「部首全体の字形が異なる場合はデザイン差とみなす」，「その他の字形の違いはなるべく再現する」ということです。--spinda-kkmr 2012年4月7日(土) 19:24
- GT書体は確かに難しいですね。ですが、住基や戸籍などの例も踏まえると忠実に再現したいという要求に対しては否定できないかと考えます。ある程度共通理解が取れるようであれば「デザイン差」のルール化で対処するということでいかがでしょうか。
- 話が飛んで恐縮ですが、Tソースの「口」の形状を許容する方向で考えています。ただし、KAGEシステムの思想として右下角の縦棒と横棒の末端がデータ上接続していないというのは許容できませんので、T型右下という形状を追加してから、と考えています。--kamichi 2012年4月24日(火) 08:35
仮想J字形が戸籍統一文字のエイリアスとして作成されている件について
匿名利用者の方が“u####-jv”“u2####-jv”のグリフを“koseki-#####0”のエイリアスとして作成してしまっています。私はこれは望ましくない(“koseki-#####0”と“u####-jv”が同じグリフなら，後者を実体にすべき)と考えますが，意見をお願いいたします。--spinda-kkmr 2012年1月23日(月) 20:57
追記。上記の結果，同じコード位置の“u####”と“u####-jv”が別のグリフとして存在してしまっているものがあります。私はこれも望ましいことではないと考えます。意見をお願いします。--spinda-kkmr 2012年1月23日(月) 21:01
- 理想的には、「エイリアスと被エイリアスは上下関係なし」であり、でも「UCS符号位置がベースの方がしっくり」きます。あと、字形が安定している方がベースの方が管理しやすい（そういう意味ではkoseki-の方が安定しているか？）と思います。本来はエイリアスと被エイリアスを入れ替える機能を早く作るべきなのですが、手間取っています。建前上、矛盾する上記2つの理想が、ルールと考えることに同意いただけるようでしたら明文化してもいいと思います。--kamichi 2012年1月23日(月) 21:35
- UCSとJVの件についても、JV計画が宙ぶらりんになっていて申し訳ありません。早く無印UCSの編集をストップしてJVに移行したいのですが…--kamichi 2012年1月23日(月) 21:35
- グリフウィキではUCSのコード位置で関連字や異体字を管理しているので，“u####-jv”や“u####-var-###”“u####-itaiji-###”が実体で“koseki-#####0”や“juki-####”がエイリアスのほうが分かりやすいというのが私が上記の意見を書いた主な理由です。特に住基ネット統一文字(juki-####)は一般人は容易に閲覧できないので実体になっていると部品として利用するときに分かりにくくなります。
- なお，エイリアスと実体の入れ替え機能は，是非とも早期に実現していただきたいです。
KAGE の肉付けについて（特に縦画起筆）
- ここで話すべきか分かりませんが、ほかの場所も無いので…。以前から気になっているのですが、縦画起筆（開放形状）の右側に飛び出るウロコはもっと大きくしてはどうでしょうか。二倍か三倍ぐらいに。私の持っている主な明朝体を比べた画像を用意しました。
- 明朝体エレメント比較
- 字形デザインの差異も興味深いですが、個々のエレメントに注目して見比べてみると色々と思う所が有るでしょう。特に花園明朝は縦画起筆のウロコが非常に弱々しい事が分ります。遠目には存在に気付かないくらい。これを大きくした方がいいと考える理由は次の通りです。
- ほかの明朝体で組まれた文章中で、足りない字だけ花園明朝を使う様な場合、エレメントが似ていた方が溶け込み易い。
- 縦画の接続・開放まで作り分けているグリフウィキにおいて、その違いが縮小した画像でも見分け易い。
- ウロコを付ける以上、ちゃんとした大きさの方がカッコいい。
- グリフの編集中、「拡大しているのだ」という事を思い出し易い（実寸の積もりでデザインしてしまわない）。
- 肉付け処理の改変が恐らく比較的容易。
- 大した副作用が予想されない。
- 御検討願います。— sayunu 2011年6月10日(金) 14:37
- ありがとうございます。検討します。もともとは、これ以上縦画起筆ウロコを大きくすることは直線ポリゴンでは変だ、ということで躊躇していました。試行して調整したいと思います。--kamichi 2011年6月21日(火) 09:04
GlyphWikiにおけるIDS記述ルールについて
IDS記述ルールについて、現状は次のようになっています。
- 文字要素は無印UCSおよび命名ガイドラインの「その他の文字コード、字典番号」のみとし、地域・変化変形・IVSは使えない
- 同名IDSの異なる字形を区別するためには「-itaiji-###」を使う
これを次のように変更したいと思います。
- 文字要素はUCSグリフおよび命名ガイドラインの「その他の文字コード、字典番号」のみとする。UCSグリフは地域指定およびIVSを使うことができる
- 変化変形、「-itaiji-###」、「-var-###」を利用できる。これらはすべて全体に対する修飾となり、したがって必ず末尾に位置する
一応運用はこの通り開始するとし、異論や提案があればその都度検討とします。--kamichi 2011年2月28日(月) 09:29
- 再検討していいでしょうか？まず大前提として全体にかかる記述である「var,itaiji」および「偏化変形」は使えないものとします。次に使える候補としてIVS、地域指定、CDP、CDP以外のその他の接尾辞によるグリフ、です。困るのは区切りが機械的に判別できない記述は望ましくないということです。--kamichi 2012年12月4日(火) 08:56
命名するときのローマ字表記について
グリフウィキでは、普通にはヘボン式ローマ字を使っていますけど、たまに訓令式や日本式ローマ字も見えます。
なので、命名ガイドラインに、「グリフに名前を付けるときには、特別な場合ではなければ、必ずヘボン式ローマ字を使うべきだ」という事項を追加すればいいと思います。この人はヘボン式を使ったり、あの人は訓令式を使ったりして混乱が生えればダメだと思います。
訓令式や日本式は発音にも合わず、事実上よく使われていません。(誰が「ti」を「チ」と読みますか。tiが「チ」なら、「ティ」は?) 訓令式や日本式は日本語の文法や音韻を教えるときにはいいかもしれませんけど、グリフウィキはそんな場所ではないので、訓令式や日本式を使う理由は全然ないと思います。--johotogoshinentai 2010年12月30日(木) 02:27
- いくつかコメントがありますが、結論から言うと、複数の方々の共通の認識が確立される前に「削除」や「移動」するのはちょっと問題があります。
- まず、今回johotogoshinentaiさんが更新されたkikko関係のグリフは正式なグリフとして管理をしているものではありません。1つの参考として「命名ガイドライン」に載っていないものは私的なグリフと考えてください。つまり、その命名で使いたい人がいる、ということで、その命名を尊重してください。
- ２つめに、確かにヘボン式ローマ字が事実上の標準ですが、一部の方々や組織ではヘボン式以外のローマ字を使っています。これは一種の文化ですので、尊重する必要があります。
- 日本語は良い意味でも悪い意味でも正書法が定義されていない言語だと私は認識しています。
- ３つめ、あまり関係ないですが、私は文字を打つ時は「ち」を「ti」で打ちます。「てぃ」は「thi」です。これはIMEに私が合わせていることになりますが、このことによりそれほど違和感は感じません。もちろん「ち」をローマ字で書くときは「chi」です。
ということで今回の件、移動してしまったグリフについては、もともとの作成者のご意向に委ねたいと思います。基本的にグリフウィキは「登録した人のニーズに合わせる」ポリシーですので他の方が強制的に変更するというのは望ましくありません。ご理解をよろしくお願いします。(下に続く)--以上はkamichi 2010年12月30日(木) 12:21
４つめ
本来はこの話とは切り離して考えるべきですが、このように私的なグリフの命名を勝手気ままに認めると、ユーザーが増えた時に混乱すると思います。その意味でjohotogoshinentaiさんのご指摘は正しいと思います。グリフウィキの設計をするときはとにかく「自由」を前面に考えていたのでこのような「ルール無し」となりました。現状では命名ガイドラインに沿っていないグリフは少ないので、ルールを変更するのであれば今がチャンスかなとは思います。私が考えているルールは次のようなものです。
- 命名ガイドラインに載っていない命名は認めない
- ユーザー占有グリフ（kamichi_****）として作る分はルール無し
- まとまった集合については、命名ガイドラインへの追加申請を認める。申請時にはその集合の概要を説明する必要がある--以上kamichi 2010年12月30日(木) 12:22
- 自由な命名ができなくなってしまうと
tokyo23city-04-shinjukuや
fukuoka-ward-02-hakataが使えなくなるので困ります。私は今後も少しずつ組み文字を作成しようと思っているのですが，組み文字を“kumimoji-u####-u####-u####”のまま扱うのは非常に厄介なのでエイリアス名を付けています。占有グリフにしないのは，他の方が利用できるようにと考えてのことです。もし自由命名が禁止された場合，組み文字の管理が厄介になりそうですね。組み文字はグリフウィキの本来の目的ではないので，やむを得ないのかもしれませんが… --spinda-kkmr 2010年12月30日(木) 18:54
- 追記。もし自由命名が禁止された場合，
ouichizaのように，どの文字コードでもコード化されていない文字はどのように扱うのでしょうか? --spinda-kkmr 2010年12月30日(木) 19:10
- ご意見ありがとうございます。おそらく、「グリフ」の自由命名に制限ができる代わりに、集合を冠した自由命名（定義）で対処することになると思います。できれば接頭辞に限定したいところではありますが、たとえば「tokyo23city-」は東京23区向けの命名、といった感じです。大きな制限をかけるというよりも、必ず何かの集合の一部にしてもらうというやり方を考えています。ouichizaはいろいろ考えられますが「画数の多い漢字」など考えられると思います。これらの集合は命名ガイドラインというよりも「集合リスト」というグループページに記述していく感じです。以上いかがでしょうか。--kamichi 2010年12月30日(木) 19:55
- つまり，「無秩序に命名することは禁止するが，各自で一定の接頭辞を作ってそれを使う事は許容する」ということでしょうか? --spinda-kkmr 2010年12月30日(木) 20:31
- はい、「無秩序に命名することは禁止する」、「各自で一定の接頭辞を作り、その意味を記述する。問題があれば事後審議」というのが大枠です。--kamichi 2010年12月30日(木) 21:47
- ただし、今先にやるべきことがいろいろあるので、すぐに試行（施行）というわけではありません。3月末までの間にこれも含めて進めたいと考えます。この制限自体の是非も含めてご意見お願いします。--kamichi 2010年12月30日(木) 21:47
- 少し議題とずれますが、僕が前から気に成つてた事に、「先に命名したもん勝ち」と言ふものが有ります。此僕の所謂命名の先取性と自由命名性との組合せから考へられる主な弊害は、例へば、tokyo23city-04-shinjukuと云ふ符号は、既に「新宿」が左、右の順に並んでゐるので、
- 【一】「新宿」を縦に並べたい人がゐても、別の命名を考へねばならない。
- と云ふ者が有るかと思ひますが、此の点に就て皆さんは何う考へて御出ででせうか。――lizard 2010年12月30日(木) 23:11
- ある意味「厚かましさ」に依存しますが、グリフウィキは「先取」とは言い切れないと思います。つまり後から登録しなおしたもの勝ち、ということです。また、バージョン番号を併記することで共存も可能と考えます。結局本件は突き詰めると問題の対象が「グリフ名」から「接尾語」に移るだけではあります。ただ、ある種の集合に属する、というメタ情報的な要素が1つ増えるだけでも運用しやすいのではないかと思います。みなさんいかがお考えでしょうか。--kamichi 2010年12月30日(木) 23:37
- まづローマ字について、私は日本式に似た規則を普段使っていて、チは「ti」です。（ちなみにティは「tĕi」です。）ローマ字は「表音記号」ではないし、johotogoshinentai さんはラテン文字の言語を英語しか知らないんぢゃないですか ? 言語学の論文などでは日本式の様な表記（音韻表記）を取る事が多いですから、それに近接した学術的文脈に在るグリフウィキでそれを用いるのも無理は無いです。
- 全く自由な命名は私も問題が有ると思っていました。実際、ガイドラインに沿わない命名のグリフが匿名利用者によって一個や二個作られても、意図が不明というのも有って削除されていたし。定義された接頭辞が必ず付いて、名前空間が限られる様になると扱い易いでしょう。
- 接頭辞を定義する際に或る程度は慎重さが必要だろうと思います。その下位の命名規則も決めるべきでしょう。「tokyo23city-」だったら、縦書きも横書きもこの下位に置けると定義した上で、例えば縦書きは「tokyo23city-04-shinjuku-ttb」とするとか。（「ttb」は「top to bottom」の略で、「ltr」や「rtl」と共に CSS なんかで使われる表現です。）
- そもそもその地名の組文字を何に使う為に作ってるのか不明なのであまり踏み込めませんが、地名の組文字を表す上位の接頭辞を定義したらどうです ? ついでながら、東京 23 区なら「city」より「ward」では ? — sayunu 2010年12月31日(金) 17:51
- tokyo23city-04-shinjukuやfukuoka-ward-02-hakata等を作成した本人からの提案ですが，
自治体名・区名の組み文字のエイリアス名を“autonomy-#####-xxx…”とするのはどうでしょうか(実体グリフは必ず“kumimoji-…”を用いる)。#####にはJIS X 0402で定められる5桁の市町村コード，xxx…には自治体名・区名をローマ字で入れる，というのはどうでしょうか? 例えば“autonomy-13104-shinjuku”，“autonomy-40132-hakata”などとなります。これで複数の接頭辞を1つにまとめられると思います。縦書き・横書きについては，横書きをデフォルトとし，縦書きは末尾に“-vert”を付ける，などが考えられます。
また，極端な意見かもしれませんが，組み文字は面倒でも“kumimoji-…”を使った名称でのみ管理する，という方法もあるかもしれません。組み文字はグリフウィキの本来の目的ではないと私も考えているので，これも1つの案として検討する必要があるかもしれません。- なお，私が東京特別区に“ward”ではなく“city”を用いたのは，東京特別区自身が「区」の訳語として“city”を用いているためです。
- 組み文字とは関係ありませんが，自由命名はouichiza等の，文字コードを割り当てられていない文字に限る，というのはどうでしょうか。
- 以上，--spinda-kkmr 2010年12月31日(金) 19:13
- 取り消し線で抹消した部分の提案を撤回いたします。申し訳ありません。
- 私が作成したグリフのせいで皆様に迷惑をかけているようなので，“tokyo23city-…”をはじめとする区名組み文字のエイリアス名は，2011年2月末をメドにすべて削除(白紙化)します。今後は“kumimoji-…”を直接扱います。
- 以上，--spinda-kkmr 2011年1月1日(土) 19:16
- 政令組文字グリフについてですが、全く迷惑でありませんので白紙化については再考をお願いします。この件はやや私が性急に過ぎた感がありますので、もう少しじっくり考える、また、あまり縛りをかけずに少しずつルールを決めていくという感じで進めたいと思います。--kamichi 2011年1月1日(土) 20:01
- これまでの議論に出たように、縦に並べるか横に並べるか、それ以外か、などの情報はあるといいと思います。おそらくフォントの文化からして基本的には横なので、縦の場合にvertに相当する情報を名前に入れるのが妥当と思います。横は冗長なので情報なしでいいのではないでしょうか。あと長くなるので組文字のIDS化は私は好ましくないと思っています。--kamichi 2011年1月1日(土) 20:01
- 了解しました。白紙化については再考いたします。もう少し議論が深まるのを待とうと思います。--spinda-kkmr 2011年1月1日(土) 20:12
既存グリフの字体の変更について（匿名ユーザー・登録ユーザー）
- 今般、既存グリフの字体の変更が多々行われ、字体に関する議論および移行が進んでいない中で、もったいない状況にあると思います。登録ユーザーの場合は利用者-会話ページで呼びかけることができますが、匿名の場合、リバートした際のサマリーに書くのがせいぜいです。（つづく）
- かといってシステム側で制限するのは本意ではありません。しかしいくらか制限を設けるべきなのかもしれません。この議論はすでに提議されていて、私は「トラブルドリブン」と書きました。今がその段階のような気がします。（つづく）
- 原因となるUCS符号位置の抽象性を排除する作業を急ぐという考え方もあると思います。再度のお願いになりますが、皆様のご意見をいただきたく思います。（つづく）
- たとえば「匿名ユーザー、登録ユーザーに対する機能制限（機能削除）を設けるべきか」「UCS符号位置グリフの抽象性の排除に関して、すぐに実行できそうな対処法」あたりについてコメントがあればお書きください。--kamichi 2010年10月24日(日) 10:10
- エイリアスグリフのエイリアス対象のデータ更新時の扱いも議論すべきかもしれません。--kamichi 2010年10月24日(日) 10:20
- 「勿体無い」と云ふのは、小生も同感です。エイリアスの実体となつてゐるグリフを更新した際に、「以下のグリフで参照先となつてゐますが、同時に更新しますか」の様な文言と選択肢が出て、「○×は更新」「一括更新」をチェックすると選択した者が更新、「更新しない」を選択するとエイリアスは旧版を参照し続ける（或いは旧版の自動的な実体化が成される）と云ふのが有ると当面は便利であると存じます。或いは投稿前の画面に「字形を変更」と云ふチェックボックスを設け、エイリアス実体グリフの編輯を投稿する際に此にチェックすると、自動的にエイリアス先の更新はしない（或いは実体更新前版の自動実体化が成される）と云ふ機能が当面は便利であると存じます。―lizard 2010年10月24日(日) 13:25
- 匿名利用者に既存のグリフを大量に書き換えられてしまうのは違和感を感じます。UCS符号位置の字形の方針が固まるまでは，「部品グリフを別のグリフに置き換える」機能の匿名利用者に対する利用制限を設けることもやむを得ないと考えます。この機能は大量のグリフを一括で変更してしまうので，影響が大き過ぎます。--spinda-kkmr 2010年10月26日(火) 19:07
「縦払い」ストロークで３つの点が並ぶ現状について
縦払いストロークは、初めの３つの点が１直線に並ばないとポリゴンが切れる不具合があります。この解決方法として
（１）常に１直線になるように固定する（２点目のX座標は無視する）
（２）直線部分と曲線部分が切れないようにする（直線部分の末端に丸ポリゴンを置く）
の２つがあると思いますが、デザイン上（１）の１直線に「ならない」ケースは存在するでしょうか？するのであれば（２）にすべきですし、存在しないなら（１）にしたいと思います。--kamichi 2010年8月9日(月) 22:39
RSS
u8fb6-g10
u8fb6-10-var-001、
u3ac3-05-var-001
u3ac3-10、
u9580-05
u9580-10
u9580-10-var-001などの部品は、それぞれストレッチ機能を使用し完全統合しても良い様な気もします。
sandbox@1131
sandbox@1132(Bモード)と
sandbox@1133(Aモード)。１画目の位置などに注目
sandbox、GlyphWiki:サンドボックスに登録する方向で検討しています。--kamichi 2013年3月2日(土) 14:32
c1-442b）※将来的に改善対象
u65b0-var-001にしたい人がゐても、別の命名を考へねばならない。
tokyo23city-04-shinjuku-var-001や
sandbox@537を
u7259-t@1
u4e0e-t@2
u22c45-g
u533b-t@1
u4ea1