GlyphWiki logo
ナビゲーション
ヘルプ
検索

ツールボックス
他の言語
解説ノート編集履歴

GlyphWiki:井戸端-未解決

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

こちらはGlyphWiki:井戸端において、議論したけれども意見がまとまらずに時間がたってしまったもの、および、機能拡張などの方針を元に意見がまとまったが、実際にシステムの更新が達成できていないものなど、未解決のものが列挙されています。

このページに新たな意見を書きこまないでください。必要な場合は、別途GlyphWiki:井戸端にて、このページに前段階の議論があったことも注記しつつ、改めて提議してください。


古代文字の字形の基準について

最近,Unicode第1面の古代文字が多く登録されていますが,各利用者ごとの字形の解釈の差のため,Unicode規格票と離れた字形のグリフが登録されていることがあります。
そこで,解釈のばらつきを回避するために,以下の基準を提案いたします。

1.古代文字は,原則としてUnicode規格票に倣った字形とする。
2.ただし,ある文字グループについて,別の基準(典拠がはっきりしており,かつ,Unicodeコード位置と明確に対応できるものに限る)に従って作成することについて複数(3名以上)の利用者が合意した場合は,それに従う。

上記のとおりです。意見をお願いいたします。--spinda-kkmr 2015年5月23日(土) 12:36

  • 自分が現在作っている古ペルム文字のように、規格表が非常にガタガタで判別が難しい場合には、2の案を適用させるべきだと思います。地域差、書き癖により、明らかに別の字と捉えられるもの(ロシア、ブルガリア、セルビアのキリル文字の差とか)に関しては-var-bgのように区分したらいいのではないかと思います。

データのライセンスについて

クリエイティブ・コモンズのCC0が発表されました。これをグリフウィキのグリフデータおよびドキュメントデータに適用(ライセンスの変更)することはいかがでしょうか。いままでグリフウィキのデータに関するライセンスの問い合わせを受けたことは無かったと思いますが、より明確になるかと思います。デメリットがあるかどうか、現時点で思いつきません。--kamichi 2015年5月8日(金) 08:09

  • 賛成です。今までのライセンスと実質的にできることが変わるわけではないので、独自ライセンスより望ましいと思います。--emk 2015年9月1日(火) 21:45

補正して欲しい字に関して

教育部異体字事典の様な楷書のソースから転写しようとしたけれど上手く再現できないといった場合のための「グループ:請補正字」のようなものはあるのですか?今の自分の場合はu7fb9-itaiji-002なのですが。 --yoshiciv

  • 現状では残念ながらありません。積極的に請うという意味ではグループを作成した方がよいと思います。それと、できれば署名の際、「〜〜〜」に加えてもう一つ「〜」を入力していただけると(つまり「〜」4つ)、投稿日時も自動的に入ります。--kamichi 2014年10月17日(金) 08:36

  • 一般の「問題のあるグリフ」の様なグループもよいと思います。u2ff0-u5200-u524a(⿰刀削、IDSは字形と違います)などの為に作るのはどうですか?--umbreon126 2014年10月20日(月) 10:38
    • 賛成です。また、問題のあるグリフ以外にも「翻訳を手伝ってほしいドキュメント」「作業中」などのタグをつけて、そのタグが付いている一覧を特別ページで出せるといいかなと思います。wikipediaがどのような方式かを知らないので、調べてみます。--kamichi 2014年10月20日(月) 10:53

IDS名称ミスのグリフについて

現在,u2ff1-u52d7-u65e5@3(⿱勗日,正しくはu2ff3-u8279-u7530-u65e5)のような誤ったIDSのグリフがいくつか存在するようです。これらは残しておく必要性が低いと思うので,白紙化したほうがよいと思います。--spinda-kkmr 2014年3月22日(土) 12:54

  • ツイッターで呼ばれたので来ました。
  • ①については白紙化すべきだと思います。白紙化を避けるのは、基本的に、一つのグリフに対して正しい命名が複数ある場合なので、間違った命名は対象にならない筈です。(長期間放置された間違いなのでサイト外から参照されている可能性があるとかいう問題は、「白紙化の抑制について」の議論で私が書いたようにシステム側で対応してほしい所です。)
    ②は余力があればやりましょうか。数が多くて面倒な時とかはdo-not-useを付けるだけでもいいですよね。元々do-not-useの付加は恒久的な状態ではなく、「いつか消すべきだし、今すぐにでも消したいけど、ほかの専有グリフに部品として引用されてるのでシステム上消させてくれない」という意味で使っていたので、グループの問題が解消した時点で誰かが消せばよい、という事で。— sayunu 2014年6月21日(土) 13:05

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

    • 亀レスで恐縮です。いまIDSグリフが大量に登録されていますが、そこで懸念しているのがUCSコードが抽象字形を指しているため、そのうちG風とJ風でバッティングしてしまうのではないかと思っています。この場合「IDS-var-###」になると思いますが、そう考えると挙げられた「戸籍統一文字等」の方が字形が安定しているのではないかと考えます。いかがでしょうか。--kamichi 2013年6月3日(月) 12:01
    • 私はJ字形を基本にIDS表現していたので,例えばu8fb6は2点之繞,ufa66は1点之繞というようにしていましたが,確かに他のソースのことを考えると(u8fb6-gは1点之繞)字形の衝突が起こりえますね… 最近大量に登録されているG風のIDSグリフについては私はよくわかりませんが,戸籍統一文字は文字情報基盤文字情報を経由してUnicodeに登録される可能性が高いので,無理にIDS表現にこだわる必要も無いかもしれませんね。--spinda-kkmr 2013年6月3日(月) 20:02

    • 私もIDSを実体とし、koseki-######などをエイリアス化する方向に賛成です。
    • IDSの無印を仮想J字形(または左下GTなどを使用しないJ字形に近い形状)にした上で、仮想J字形以外の字形と偏化変形を全て「IDS-var-###」に字形を割り当てるのも有りなのかとも思います。
      当方も中華字海、台湾教育部異体字字典、會保存遺産喃の字喃など、G,T,V字形に該当する物を多数作成しておりますが、文字によって字形に差異のあるものが多々見受けられます。
    • また、現状関連字はCJK統合漢字1字を割り当てることが可能ですが、関連字にIDS(3字以上)が使用できれば、さらに見やすくなる気もします。
    • 例えば、仮想J字形にu2ff1-u8002-u2ffa-u200ca-u53ea(壽・寿の異体字の一つ)を作成し、(現在の関連字:寿) u2ff1-u8002-u2ffa-u200ca-u53ea-var-001(zihai-117106) (zihai-...をエイリアスとする)、(現在の関連字:壽) u2ff1-u8002-u2ffa-u200ca-u53ea-var-002(twedu-a00836-069) (twedu-...をエイリアスとする)をそれぞれ関連字に「⿱耂⿺𠃊只」を割り当てて、異体字関連グリフに「壽(台湾教育)」「寿(中華字海)」を割り当てる。--kamiyo 2013年6月10日(月) 15: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-05u5e7f-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

  • (インデント戻る)だからそもそもuf99au9023には「差」がないんでしょう!韓国では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

UCSの地域+偏化変形グリフについて

vnpf-60838u7fdf-v02ufa1e-v03という引用をvnpf-60838u7fdf-02-var-002ufa1e-03-var-003と変更しました。これは、「-jv」の設置により「地域ソースは規格表で規定されているものに限る」という方針を偏化変形にも適用したためです。u7fdfufa1eにはVソースはないので「地域+偏化変形」グリフは登録できないと思います。しかし皆さんは今までは仮想地域字形として使われてきたかもしれません。

本来「偏化変形+地域」グリフの場合、規格表でその字形が規定されていません。また地域字形にあたるものを地域指定ではなく「-var-###」に持ってくると、「-var-###」が日本では使わないものが並んで濁ってしまうことも考えられます。仮想地域字形を規定するのは面倒ですし、どちらの方針にするか悩みます。

以上ご意見ありますでしょうか?--kamichi 2013年1月20日(日) 16:25

  • 部品グリフの例示ソース指定って、その欄で見受けられる部品の形状ではなくて、親字の特徴を引き継いだ部品を表すんですね。ソース指定と地域指定を別に用意するとしたら…しかし V 欄がベトナム字形の代表として妥当とも限らないし、或る字形を「ベトナムで通用している字形である」と認定するのは我々には中々難しいですね。
  • 連番で var をガンガン作っていくとしたら、ガンガン作ってもゴッチャにならないユーザーインターフェイスが欲しいものです。— sayunu 2013年2月2日(土) 19:06

白紙化の抑制について

異論も多いと思いますが、実運用で気になったので、明確にできればと思います。重複しているグリフの白紙化をどうするか、という問題はこれまでにも出てきました。これまでは意味のある重複は白紙化せず、「-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

「白紙化の抑制」はこの議論にて事実上の規定事項になったと考えられますが,最近は「作成時点ではUnicodeに無かったが,現在はあるIDSグリフ」がUnicode命名を実体グリフにしたうえで(IDSを)白紙化されています。Unicodeグリフを実体にするのは当然としても,白紙化抑制の考えからすればIDSグリフはエイリアスグリフとして残しておくのが順当と考えられますが,皆様のご意見をお願いいたします。--spinda-kkmr 2019年2月16日(土) 10:44

  • 上記意見を書き込んだにも関わらず,IDSグリフの白紙化が進んでいるようです。確認と意見の書き込みをお願いします。特に管理人のkamichi様にはなるべく早期の意見表明をお願いいたします。--spinda-kkmr 2019年2月17日(日) 10:31
  • 反対です。そもそもIDS表記は文字コードに存在しない文字を表現するためのものなのでUnicodeに存在する文字をIDS表記にすることは望ましくないと思われます。(もっとも、互換漢字をIDS表記に使うことも望ましくないのですが。)--kesuuko 2019年2月18日(月) 21:21

  • 意見表明が遅くなり申し訳ありません。この件については、2つの対立する考え方があると思います。それで、白紙化抑制の方針を考えたときの一番の目的は、グリフウィキ上の登録グリフが整理されていない状態よりも、外部Web上でグリフを利用(引用)しているユーザーおよびページ閲覧者に対して、白紙化でグリフが真っ白になってしまう混乱を避けること、でした。現在、グリフウィキは大量のグリフが登録されていて、できれば無秩序状態を整理したいというのはコアユーザーの1つの意見だと思います。またIDSグリフは最も字形揺れが大きい(各UCSパーツごとに字形差が存在する)ので、もしそれが既存UCSグリフ等にマッピングできるのであれば積極的に移動させたいと思うことも理解できます。それで、以前sayunuさんの提案にあった、白紙化しても最終グリフが画像引用の場合表示される案を参考に「白紙化したグリフはページとしては白紙化される。画像を要求した場合は、グレーアウトした最終版グリフ画像が得られる」としてはどうかと思います。この場合、グリフを見たいというとりあえずの要求は維持できると思います。内部処理で1つ問題があるので、少し時間をかけて実現できるか検討したいと思いますが、よって今後は「グリフ白紙化を抑制しない」という方針変更も併せて提案いたします。以上いかがでしょうか。割と大きな方針変更なので少し広く意見を求めます。--kamichi 2019年2月21日(木) 12:00
    • 「Unicodeに収録されたIDSについては白紙化対象としてもよい」が現在のGlyphWikiの方針であるということで認識しました。今後はそれに従います。
    • なお,白紙化グリフについて外部から画像の要求があった場合は白紙で無い最も新しい版が得られる機能については,なるべく早くの実装をお願いいたします。現時点では「確実に字形を指定したい場合はバージョン指定をする」ことを周知すればよいと思います。
    • 以上,--spinda-kkmr 2019年2月22日(金) 21:28

古琴減字譜(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_にコピーするか要検討。いらないのでは?)

  • 関連字についてはメタ情報に記述し、関連字自体を削除したいと考えます。2、3個の記述で良いと思います。呼称、組み合わせの文字群、などでしょうか。--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

GやTやVソースの字形を忠実に再現することに関して(再考か否か)

現在、以下のデザインはデザイン差としてグリフウィキでは認めないとしています。個人的に見つけ次第強めに排除しているつもりです。

  • 折れのカーブ
    • 不可:u533b-t@1
    • ガイドライン:普通に「折れ」を使う(u4ea1)

  • Tデザインの口右下
    • 不可:横棒が飛び出る
    • ガイドライン:普通に右下角を使う

  • Gデザイン「入」の入り
    • ガイドライン:「細入」を使う(c1-442b)※将来的に改善対象

ですが、戸籍統一文字や登記文字を見ていて、迷っています。この方針に関して意見のある方は教えてください。なお、私が拒絶する理由はたとえばTデザインの口を許容すると、あらゆる「口」を含む漢字が単純2倍になってしまう、と感じるからです。--kamichi 2012年3月29日(木) 21:19

  • 私の案としては以下のとおりです。
    • Gソース,Tソース等の字形は,上記のガイドライン通り一定のルールのもとで再現する。
    • 戸籍統一文字,住基ネット統一文字,登記統一文字(以降,行政系文字コードとする)は可能な限り忠実に再現する。ただし,戸籍統一文字は必ずしもデザインが整ってはいないので,見た目を良くする程度の差異は許容する。
  • 行政系文字コードを正確に再現すべきと考える理由としては,行政系文字コードには包摂・統合の概念が無く1つのコードに対しただ1つの字形が存在するためです。
  • また,大規模文字セットであるGTコードについても,GT書体は若干クセのある字形ですので,グリフウィキでどう扱うかを考えるべきだと思います。たとえば,GTコードでの「好」の字(gt-07641)はsandbox@996のようになっており,u597dとは女偏の形が異なっております。しかしGT書体は画数を明確にするために恣意的に通常の明朝体とは字形を変えてある場合もあり,必ずしも厳密に再現すべきかどうか判断に迷うところです。gt-12636u5f71のように,接触・非接触の違いの場合は再現すべきと考えますが,女偏のように部首全体の字形が異なる場合は,デザイン差としても構わないと思います。ただし,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
    • 3年間止まっていますが,いまchanhenryfaihangさんがTソースの「口」の形状を作成して,umbreon126さんに白紙化されるというやりとりをしています。いまも方向性が同じなら,T型右下の早期実現が望ましいです。他にもGlyphWiki:ソフトウェアへの要望に要望が出ています。 --ziyang 2015年4月8日(水) 22:02

  • had a try to imitate G source 捺 stroke with visible beginning: u5165-var-001 u516b-var-002. 細入り conforms neither of them, also these two are different. one might be named 半細入り(for G 入, 內, etc) and the other might be 開放半細入り(for G 八, 公, 分, etc). furthermore, observing existing japanese fonts, 捺 strokes other than 乀乁, for example J source u516c u5206, looks like 半細入り, not 細入り which is only for 點. hope that these will be added into KAGE. farter 2015年8月18日(火) 16:50

仮想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

命名するときのローマ字表記について

グリフウィキでは、普通にはヘボン式ローマ字を使っていますけど、たまに訓令式や日本式ローマ字も見えます。

なので、命名ガイドラインに、「グリフに名前を付けるときには、特別な場合ではなければ、必ずヘボン式ローマ字を使うべきだ」という事項を追加すればいいと思います。この人はヘボン式を使ったり、あの人は訓令式を使ったりして混乱が生えればダメだと思います。

訓令式や日本式は発音にも合わず、事実上よく使われていません。(誰が「ti」を「チ」と読みますか。tiが「チ」なら、「ティ」は?) 訓令式や日本式は日本語の文法や音韻を教えるときにはいいかもしれませんけど、グリフウィキはそんな場所ではないので、訓令式や日本式を使う理由は全然ないと思います。--johotogoshinentai 2010年12月30日(木) 02:27

  • いくつかコメントがありますが、結論から言うと、複数の方々の共通の認識が確立される前に「削除」や「移動」するのはちょっと問題があります。
    • まず、今回johotogoshinentaiさんが更新されたkikko関係のグリフは正式なグリフとして管理をしているものではありません。1つの参考として「命名ガイドライン」に載っていないものは私的なグリフと考えてください。つまり、その命名で使いたい人がいる、ということで、その命名を尊重してください。
    • 2つめに、確かにヘボン式ローマ字が事実上の標準ですが、一部の方々や組織ではヘボン式以外のローマ字を使っています。これは一種の文化ですので、尊重する必要があります。
      • 日本語は良い意味でも悪い意味でも正書法が定義されていない言語だと私は認識しています。
    • 3つめ、あまり関係ないですが、私は文字を打つ時は「ち」を「ti」で打ちます。「てぃ」は「thi」です。これはIMEに私が合わせていることになりますが、このことによりそれほど違和感は感じません。もちろん「ち」をローマ字で書くときは「chi」です。

ということで今回の件、移動してしまったグリフについては、もともとの作成者のご意向に委ねたいと思います。基本的にグリフウィキは「登録した人のニーズに合わせる」ポリシーですので他の方が強制的に変更するというのは望ましくありません。ご理解をよろしくお願いします。(下に続く)--以上はkamichi 2010年12月30日(木) 12:21

4つめ

本来はこの話とは切り離して考えるべきですが、このように私的なグリフの命名を勝手気ままに認めると、ユーザーが増えた時に混乱すると思います。その意味でjohotogoshinentaiさんのご指摘は正しいと思います。グリフウィキの設計をするときはとにかく「自由」を前面に考えていたのでこのような「ルール無し」となりました。現状では命名ガイドラインに沿っていないグリフは少ないので、ルールを変更するのであれば今がチャンスかなとは思います。私が考えているルールは次のようなものです。

  • 命名ガイドラインに載っていない命名は認めない
    • ユーザー占有グリフ(kamichi_****)として作る分はルール無し
  • まとまった集合については、命名ガイドラインへの追加申請を認める。申請時にはその集合の概要を説明する必要がある--以上kamichi 2010年12月30日(木) 12:22

    • 自由な命名ができなくなってしまうとtokyo23city-04-shinjukufukuoka-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と云ふ符号は、既に「新宿」が左、右の順に並んでゐるので、

    • 【一】「新宿」を縦に並べたい人がゐても、別の命名を考へねばならない。

    • 【二】「新」の字形をu65b0-var-001にしたい人がゐても、別の命名を考へねばならない。

    • 【三】tokyo23city-04-shinjukuで「文京」を組んだり、sandbox@537taitoと命名したりする事も出来るし、誰かに然うされた場合、誰も其符号は嬲られないので、変であると思つても直されず、残続ける。

  • と云ふ者が有るかと思ひますが、此の点に就て皆さんは何う考へて御出ででせうか。――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-shinjukufukuoka-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

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

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

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

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