GlyphWiki logo
导航
帮助
搜索

工具箱
其他语言
文章讨论编辑历史

GlyphWiki:井戸端-保存2012年まで

字形维基(GlyphWiki), 自由的字形数据库

目录

以下、保存用です。編集はご遠慮ください。

2009年から2012年までの分を保存しています。それ以降についてはGlyphWiki:井戸端-保存をご覧ください。


グリフウィキの今後の命名ポリシーについて

グリフウィキはグリフに自由な名前を付けることを謳っており、ただし一部の命名についてはガイドラインを設け、制限を付けています。

将来的にCHISEプロジェクトのCHISE-DBとの連携を考えていますが、1つの問題としてこの自由命名があります。

前にも同様のことを書きましたが、将来的には命名について、完全にルール化する部分とユーザー占有グリフ(自由命名)、の2グループに分け、一般グリフの自由命名は廃止しようかと考えています。これは別で議論している匿名ユーザー制限ともかかわってきます。

あるいはプレフィクス付き(たとえばanonym-とか?)の条件付きで自由命名を存続させても良いと思います。

CHISE-DBとグリフウィキとの連携に関して、明後日の土曜日に関連学会発表 がありますのでお知らせします。私も参加します。

  • この件については、「命名ガイドライン」から「命名ルール」への移行ということですでに準備を進めています。議論としては閉じます。--kamichi 2012年12月4日(火) 08:51

2012年8月17日以降のグリフウィキの動作について

2012年8月17日,遅くとも21時頃からグリフウィキの閲覧が重くなっています。特にグリフ画像の読み込みに時間がかかります。他にサイトは全く問題なく閲覧できるのでグリフウィキ側の問題だと思います。原因の調査をお願いいたします。--spinda-kkmr 2012年8月18日(土) 20:42

  • ご指摘ありがとうございます。17日の日中から同様の状況であると認識していますが、グリフウィキのサーバ自体は問題がなく、設置場所のネットワークの問題と思われます。来週、基幹ネットワークのメンテナンスが行われるということなので、それ以降も状況が変わらないようであれば調査を依頼したいと思います。--kamichi 2012年8月18日(土) 22:41

  • 昨日(2012年8月20日)には復旧したようです。--spinda-kkmr 2012年8月21日(火) 19:04

匿名利用者の【臨時】機能制限について

この2日ほど大量のSPAM投稿が発生しています。その一部が排除できずに登録されています。近日、管理者が出張のためSPAM投稿に対応できない可能性があります。このため臨時措置として匿名利用者の投稿を一切受け付けない方向で制限する予定です。 --kamichi 2012年7月26日(木) 22:51

  • 特に実施せずこの話を閉じます。--kamichi 2012年8月19日(日) 12:47

入管外字コードについて

入管外字コードとして使われている“nyukan-####”を命名ガイドラインに追加することを提案いたします。--spinda-kkmr 2012年7月26日(木) 20:41

  • 私の見地では、「編集をするには、必ずしも許可を受ける必要はない。だから一応大胆に編集してみよう」という主義です。編集が必要だと思うなら、編集すればいいと思います。もちろん、この「編集」には内容の追加も含まれます。編集して問題があるなら、その時直せば・戻せばいいでしょう。それがウィキシステムの長所だと思います。
  • ちなみに、別にyasuokaさんもnyukan-####を作成許可をkamichiさんから受けてから作成しているわけでもないでしょうし。 --johotogoshinentai 2012年7月27日(金) 12:23
  • そうですね。なお、運営者として現在第三者に作業を依頼しているのはzihai-のグリフ登録のみです。--kamichi 2012年7月27日(金) 13:39

    • 命名ガイドラインに“nyukan-####”を追加しました。命名ガイドラインは重要度の高いページだと考えたので,追加する前に管理人のkamichi氏および他のユーザーの意見を聞いておきたいと考えたため,ここで提案いたしました。
    • なお,入管外字コードは文字情報基盤文字情報一覧表 に掲載があるので,公的文字コードに準ずるものと考えてよさそうです。
    • 以上,--spinda-kkmr 2012年7月27日(金) 19:03

Unicode実装済みのu(#)####-itaiji-###の白紙化提案

GlyphWikiに登録されているu(#)####-itaiji-###の中で、Unicodeに実装済みのものなら白紙化するのはどうでしょうか? (例:u6dbc-itaiji-001は、u9fccと同じなので白紙化する) --johotogoshinentai 2012年7月24日(火) 16:39

u9fccがあるのにu6dbc-itaiji-001を保存するのは、ただの「グリフ数増やし」だと思います。 --johotogoshinentai 2012年7月28日(土) 17:55

  • 強い賛成ではないですが、白紙化は問題ないと思います。ただ関連づけの情報を追記してほしいと思います。--kamichi 2012年11月4日(日) 20:35

  • 「白紙化の抑制について」の通り、白紙化は抑制の方向で考えています。--kamichi 2013年1月1日(火) 15:46

匿名利用者の若干の非匿名化について

以前、匿名利用者はアクセス元IPアドレスを表示していましたが、これをやめて「匿名利用者」以上の情報を出さないようにしました。これに関して、スパム投稿の前後の匿名利用者の投稿が真面目なものかそうでないものかの判断が難しく(管理者以外の一般ユーザーは)混乱すると思います。そこで、そのIPアドレスが昨日までに投稿の実績があるか/ないかで、新規匿名利用者、ベテラン匿名利用者と、2つに分別して表示するようにするのはどうか(新規はスパム率が高いのでより注意して投稿を見守るという目安になる)と思いますが、いかがでしょうか。なお、これはポリシーの大きな変更なので強い賛同がない場合は実施しません。また「GlyphWiki:」ページは匿名利用者は投稿できませんのでそのことも踏まえて結論をつけたいと思います。ご意見よろしくお願いします。--kamichi 2012年5月15日(火) 20:31

  • 賛成です。新規匿名利用者については,“-var”,“-itaiji-”による異体字の作成に制限を設け,根拠を示しておらず,他の利用者も根拠を確認できない場合は,信頼性が無いと判断して白紙化する,というのはどうでしょうか。匿名利用者による異体字は,信頼性が低いと考えます。--spinda-kkmr 2012年5月19日(土) 11:47

  • これは別のものかもしれませんが、UCSグリフを匿名利用者が編集できないように制限するのはいかがでしょうか。UCSグリフは引用度が高く、荒らされると大変不便になります。 --johotogoshinentai 2012年5月21日(月) 09:41
    • 今朝は匿名利用者によってu9759u975c-ue0102のエイリアスになってしまって、u9759をエイリアス先としていたエイリアスグリフは全部u975c-ue0102のエイリアスになってしまいました。(今は私がすべて直しておきました。) このような場合ではエイリアス関係も複雑になってしまいます。UCSグリフを匿名利用者が編集できないように制限する必要があると思います。 --johotogoshinentai 2012年5月23日(水) 11:49

    • 難しいですね。2つコメントがあります。(1)あまり複雑な制限のかけ方は混乱すると思うので、わかりやすい制限を。(2)匿名者への制限はカジュアルないたずらには対応可能だが、本気を出されたら登録ユーザーに移って同じことをされるだけなので、根本的な解決にはならないかもしれないこと。現実に長期にわたっての匿名スパムユーザーが実在しています。

  • 匿名の人はsandboxおよびguest-001~100の編集のみに閉じるという制限も検討の1つかと思います。既存データへの編集協力はユーザーになってもらい、一方でちょっとグリフが必要というニーズにも対応できるかと思います。あとは、ユーザー認証をするけれどもユーザー名を出さないで編集する、という半匿名という概念があっても良いのかもしれません。--kamichi 2012年5月24日(木) 08:04

  • 悩ましいところですが、匿名利用者が投稿した場合は、強制(自動)的にsandboxに登録する、というのも1つのやり方かと思います。要旨に真っ当な記述があれば登録ユーザーが適切な命名にコピーする、というものです。--kamichi 2013年2月18日(月) 08:35
    • 賛成です。やや厳しいですが,やむを得ないと思います。--spinda-kkmr 2013年2月22日(金) 20:23
    • 正直あまりやりたくない(登録者spamユーザーが増える可能性が高い)のですが、匿名利用者の投稿は全てsandboxGlyphWiki:サンドボックスに登録する方向で検討しています。--kamichi 2013年3月2日(土) 14:32

  • 本日(2015/01/07)朝,かなり大規模な荒らしが発生しました。匿名利用者への制限を厳しくするほうがよいと考えます。
    • (1)グループページの新規作成は1日3ページまで,編集は(新規作成と合わせて)1日10ページまで
    • (2)グリフの新規作成は1日30グリフまで,編集は(新規作成と合わせて)1日100グリフまで
  • やや厳しいですが,この程度の規制は行わないと荒らしは無くならないと思います。
  • あるいは,上記のkamichiさんの提案通り,sandbox以外の登録は匿名利用者には認めないというのも方法としてはあると思いますが,そうすると「少しだけ」グリフウィキを利用したい人までいちいちアカウントを取らなければならなくなるので,利便性がやや損なわれてしまうと思います。
  • 以上,--spinda-kkmr 2015年1月7日(水) 18:29

  • 本件、そろそろ結論を出してもいいとは思っているのですが、その前提として、実態がどうなっているかをみなさんに把握してもらった上でないと無意味と思います。というのはすでにいくつかの予防策により日々投稿されるスパムデータは9割がた(直感)弾いているからです。かといって、スパマー相手に手の内を見せたくはないと考えます。それも踏まえてちょっと情報を整理して提示しますのでお待ちください。でもあくまで感覚的なものですが、スパマーは3、4名程度に限られていると思います。現状で、それほど悪質とは思っていません。すぐ復旧できる仕組みの新設で乗り切れるほうがいいかなとも思います。--kamichi 2015年1月7日(水) 23:50

  • 議論を抜かす形になり恐縮ですが、当座の対処として、グループページのみ匿名希望者に対しては字表:sandboxのみ編集可とする方向で考えます。なお、他言語対応をふまえ、種別が違うことを明示する意味でカタカナを使っていたGlyphWiki:サンドボックスからサンドボックスページとしての位置付けを移行します。以上の対応を検討中です。--kamichi 2015年1月8日(木) 08:49

toki-00######とj90-####の廃止の提案

以降の提案をしたいと思います。

  • toki-00######を認めず、koseki-######のみを認める
  • j90-####を認めず、jx1-2000-####のみを認める

toki-00######はkoseki-######とまったく同じですので、必要ないと思います。toki-00######の作成を許可するのは、ただの「グリフ数増やし」だと思います。

同じく、j90-####はjx1-2000-####の完全なsubsetですので、必要ないと思います。j90-####の作成を許可するのは、ただの「グリフ数増やし」だと思います。(以前、私はjx1-2000-####の廃止を提案したことがあるのですが、jx1-2000-4f60jx1-2004-4f60のため、jx1-2000-####は廃止できません。)

以上です。--johotogoshinentai 2012年3月30日(金) 12:01

  • 確かに“toki-00#####0”と“koseki-#####0”は同じですが,たとえばkoseki-000010toki-00000010では前者は戸籍統一文字,後者は登記統一文字であり,「視点」が異なります。実際に存在する文字コードのグリフに対し制限をするのは好ましくないと思います。--spinda-kkmr 2012年3月30日(金) 18:41

  • よくわからないけどリダイレクトとかってできないの?--mandarin 2012年4月29日(日) 06:05

  • 積極的な重複グリフの作成、および、積極的な重複グリフの削除(白紙化)はいずれにも賛成しません。意味の違いがあるので、分離してグリフを登録したいというニーズがあるのでしたらそれを尊重したいと思います。重複グリフを登録するときは極力、要約欄に意図を記述した上で登録してほしいと思います。--kamichi 2012年11月4日(日) 20:35

    • 私はグリフウィキは字形のデータベースであると同時に文字コード情報のデータベースでもあると考えています。したがって,1つのグリフに対し様々な命名でエイリアス名がつけられるのは構わないと思います。
    • ただ,登記統一文字の“toki-00#####0”については,戸籍統一文字と重複しますので,現状では積極的な作成は不要と考えます。“koseki-#####0”が完全に埋まった時点で,bot等を用いて一気に作成してしまえばよいと考えます。
    • 以上,--spinda-kkmr 2012年11月5日(月) 20:16

    • 賛成です。少しずれますが、トップページでのグリフ数の表示に、全グリフの数だけでなく、ユニークグリフ数も合わせて提示するといいのかなと考えます。「水増し」と思われるのは、そうではない、という意味で。--kamichi 2012年11月10日(土) 21:30

    • ユニーク(実体)グリフ数の表示に賛成です。総グリフ数,エイリアスグリフ数は字表:文字種別グリフ数詳細で分かるので,総グリフ数からエイリアスグリフ数を引けば実体グリフ数が分かると思います。--spinda-kkmr 2012年11月11日(日) 11:58

  • 現状維持とし、トップページのグリフ数の項は今後エイリアスをひいた純グリフ数を併記する形にして、議論を閉じます。--kamichi 2012年12月4日(火) 08:53

私(johotogoshinentai)の作った誤字についてお詫び

Ext Bの中の多数のグリフは私の作ったものですが、誤字がかなりあるようですね。誤字が修正されるのを見ると、「自分はいったい何を考えててそんな誤字を作ったんだ」という、後悔のような気分になります。誤字を作ったのは本当に申し訳ありません。修正どうもありがとうございます。

追伸:誤字はExt Bだけではなく、ほかの領域にもあると思います(それは私の作ったものではありませんが)。ですので、Ext Bだけではなく、ほかの領域もチェックする必要もあると思います。--johotogoshinentai 2012年3月20日(火) 13:05

  • うっかりミスというのは誰でもやってしまうものなので、誤字もある程度は仕方のないものだと思います。もちろんミスを防止できれば言うことはありませんが、誤字を発見して修正する作業の方が重要ではないでしょうか。過去にも JIS X 0213:2004 完成時や拡張C完成時など、花園明朝のリリースに合わせてグリフをチェックしていましたが、そのような網羅的なチェックが一度は必要だと感じます(ちなみに、私は1週間ほど前から拡張Bのチェックをしています)。正しいグリフが誤字になるということはあまり起こりえないので、チェックして一度誤字を潰してしまえばある程度の品質は保てるでしょう。--mashabow 2012年3月20日(火) 17:24

  • 今までのjohotogoshinentaiさんの実績を鑑みれば全く問題と思っていませんが、チェックは必要ですね。字形チェックについては研究費を投入しても良いと思っています。話題が少し変わりますが、そろそろUCSグリフについて、状態フラグ(字形のチェックを済ませたか)が必要か、という話題がありました。またグリフの更新時に「デザインの修正」なのか「字形の修正なのか」といった情報を強制的に指定させた方が良い、という話もあります。--kamichi 2012年3月20日(火) 18:34

SPAM投稿について(2012-02-19)

まだ判断しかねていますが、昨年末からのSPAM投稿は次の2種に分かれるようです。

  • (1)ぷらら経由:意味不明な投稿
  • (2)OpenProxy経由:f**k投稿

1も2も実はこのところ継続的に投稿がなされていますが、システム側で対処しているので実際には投稿されない状況となっています。

2については、対処方法を用意し効果的に防げています。

1は普通のIPアドレスなのでシステム側では対処できませんが、昨年末からのものについてはずっと同じIPアドレスでしたので、リストに登録してはじいていました。今日別のIPアドレスに変わり、私の方で気が付いていませんでした。先ほどIPアドレスを追加したので、はじくようになっています。その後現在も投稿しようと継続中です。ということで、なかなか根本的な対処の難しい問題と思います。

なお、特に初心者がSPAM投稿と紛らわしい投稿を行いますので、johotogoshinentaiさんがおっしゃるように、しばらく見守るというのが正しい対処方法と思いますが、今日の投稿は昨年末からの意味不明投稿者と同じと判断していますので、SPAM投稿者と断定しています。

ということで、まだこの問題は続くと思いますが、白旗は上げません。使いにくくならないように、どうにかする方法を考えたいと思っています。コメントやアドバイスがありましたら是非お願いします。--kamichi 2012年2月19日(日) 19:55

さまざまな文字コードと字典、そしてその例示字形の重要性を説明するページの必要性について

今、グリフウィキでは文字コード(JIS、戸籍、住基、登記など)や字典(大漢和、康煕字典、中華字海など)について説明するページと、その例示字形の重要性を説明するページがないようです。説明がないのは、初心者がグリフウィキに入門するのを難しくさせていると思います。

たとえば、私も最初のころは日本の文字コードのことと例示字形のことについて知識がほとんどなかったので、勝手に字形を変更してしまったこともあります。(これについてはお詫びしたいと思います。)

文字コードと字典のことを簡単に説明するページとエ例示字形の重要性について説明するページがあったら、初心者の投稿にもっと役に立つと思います。 --johotogoshinentai 2012年1月14日(土) 03:47

  • ご意見ありがとうございます。おっしゃる通りですね。グリフウィキとその周辺のトピックでドキュメントをまとめられたらと思います。どうやってモチベーションを高めましょうかね…。--kamichi 2012年1月14日(土) 21:15

CBETA外字の命名ガイドラインの改定について

現在CBETA外字の命名は「cb#####」となっていますが、この集合だけ「-」を使っておらず、前置語と分かりにくくなっているため、「cb-#####」に変更したいと思います。ご意見がありましたら表明をお願いします。あまり影響はないと考えています。--kamichi 2012年1月11日(水) 13:01

  • 賛成です。そのほうが統一がとれて望ましいと思います。--spinda-kkmr 2012年1月24日(火) 20:51

  • 4か月たっても異見がありませんね。cb#####をcb-#####に移動してよろしいでしょうか。 --johotogoshinentai 2012年6月24日(日) 09:43
    • 良いと思います。--kamichi 2012年6月24日(日) 12:50
    • CNS11643の11面と衝突するのでは?--pyrite 2012年6月25日(月) 01:17
    • あ、そうですね。ご指摘ありがとうございます。では再提案ということで「cbeta-」はいかがでしょうか。--kamichi 2012年6月25日(月) 08:05
      • “cbeta-#####”に賛成します。--spinda-kkmr 2012年6月25日(月) 20:11
      • 確かに衝突しますね。私もcbeta-#####に賛成します。--johotogoshinentai 2012年6月26日(火) 01:47
      • 確定しましょう。ご指摘、ご意見ありがとうございました。--kamichi 2012年7月16日(月) 10:27

組み文字の一般グリフ名への不適合について

hanyo-denshiなど、いくつか組み文字が登録されていますが、文字列になるとメッセージ性を持ちやすいので入れるべきではないと考えます。具体的には、「kumimoji-」の前置語のないグリフ名には組み文字は入れない(命名ガイドラインにある文字コード系の組み文字を除く)というルールを考えていますが、いかがでしょうか。異論が出そうですが、まずは提案いたします。--kamichi 2012年1月10日(火) 07:54

  • 1つ補足します。「kumimoji-」以外に、1つページを作り、命名ガイドラインとは別に「前置語一覧」のようなページを作り、そこにこの前置語は組み文字です、と断っているものはOKということを追加します。具体的には区名組み文字などはこちらでカバーするということです。--kamichi 2012年1月10日(火) 08:02

  • 組み文字の命名ガイドラインの記述では「kumimoji-(IDS)」で、とありますが、長くなるので、限定しなくていいように思いなおしました。以下でどうでしょうか。--kamichi 2012年1月11日(水) 11:23
    • 「kumimoji-」に続けて「IDS記述」、「UCS符号位置の羅列(「-」区切り)」、「「-」を使わない自由文字列(前2つとの混同を避ける)」

なぜ花園明朝はメディア等に掲載されないのか

前々から不思議に思っているのですが、花園フォントはいわゆる「フリーフォント集(本・ムック)」や「フリーフォント一覧(Web)」にほとんど採用されません。こちらから積極的にお願いしたことはありませんが、そういうものなのでしょうか?文字品質がどうのこうのと言われると、何とも言えませんが、もし編集者側の方のコメントがあれば頂戴したいところです。--kamichi 2012年1月9日(月) 00:58

  • と文句を書いてしまいましたが、めでたくメディア「窓の杜」に掲載されました。パチパチ~。また別件で近刊のフォント集にも花園フォントを収録してくださるという連絡を受けています。--kamichi 2012年3月8日(木) 19:55

http://www.forest.impress.co.jp/docs/review/20120308_516781.html

最近のスパム投稿について

2011年後半から特にこの1か月ほどスパム投稿が増えています。意外なことに投稿元IPアドレスはほとんどが国外管理のもので、かつアメリカ大陸、ヨーロッパ大陸、アジア大陸、あちこちです。ホスティングやVPSのサービスからのようで、スクリプトか何かで機械的に狙われているのかもしれません。なお「凸」の異体字を作りたがるケースについては一人によるものと思われます。--kamichi 2012年1月7日(土) 15:59

  • 本当にバラバラなIPアドレスから来ますね。不思議です。--kamichi 2012年1月7日(土) 18:56

    • バラバラなIPは、たぶんproxyのことでしょう。あと、同じタイプの荒らしでも、それが1人によるものではないかもしれません。こんな状況かもしれませんよ。
      • 1人の誰かが荒らしを始める
      • ほかの人が荒らしを見て、面白そうだと思う
      • ほかの人も同じ荒らしを始める
      • たまには、この過程が繰り返され、荒らす人がもっと増える
    • johotogoshinentai 2012年1月7日(土) 19:07
    • ああ、proxyですか。それなら合点がいきますね。そうすると対処は無理ですね。--kamichi 2012年1月7日(土) 19:11
  • 海外からのspam投稿に関しては、niku.2ch.net などのRBLを使ってみるのもいいかもしれません(参考リンク: http://www.hart.co.jp/spam/tbrbl.html )。自分でもPukiWikiに組み込んで効果がありました。--fx 2012年1月8日(日) 01:44
    • 非常に参考になりました。さっそく実施しました。--kamichi 2012年1月8日(日) 12:07
    • ポチポチ効果が出ているようです。fxさんありがとうございます。--kamichi 2012年1月8日(日) 19:26

  • あと、せめてGlyphWiki:メインページGlyphWiki:MainPageは、匿名利用者が編集できないように保護するのはいかがですか。GlyphWikiに接続して初めて見えるページなので、荒らし率がほかのページより高いと思います。 --johotogoshinentai 2012年1月8日(日) 09:57
    • そうですね。「GlyphWiki:」ページは匿名利用者には編集を開放しなくてよいと思っています。また、登録ユーザーもメールアドレスを登録しているユーザーとそうでないユーザーとで権限を分けて考えてもいいと思います。ただ、私の不手際でもしクラックされてグリフウィキに登録しているメールアドレスが漏れたときのことを考えるとメールアドレスの登録を強制したくないところです。--kamichi 2012年1月8日(日) 12:07
    • ひとまず、匿名利用者が「GlyphWiki:」ページに投稿できないようにしました。基本的に必要ないと思います。要望系(井戸端含む)ページには影響が出てしまいますが。もう少し対象を絞ったほうが良いでしょうか。--kamichi 2012年1月9日(月) 13:09

  • 本日(2012年1月26日)に発生した荒らしを見て思ったのですが,登録されている利用者と同じ名前のグリフは完全に作成を禁止するか,その登録利用者のみが利用できるようにする(つまり現在の占有グリフ“(ユーザー名_###…)”と同じ扱いにする)かどちらかの対処をとるほうがよいと思います。--spinda-kkmr 2012年1月26日(木) 20:16
    • ご提案ありがとうございます。詳細は控えますが、そうすると1つ悪影響があるので、その制限は難しいかと思います。匿名利用者に対する制限に関して現在1つ新規に検討しているものがありますので、そちらで対処できないかと考えています。--kamichi 2012年1月26日(木) 23:09

「凸」の異体字の件ですが、今考えると、荒らし者(たち)はただ「自分の荒らしが削除記録に残されるのを喜んでいる」かもしれません。「凸」の異体字の荒らしを削除するとき、削除記録に記録しないのはいかがでしょうか。今日の変な組み文字(私はそれが見られなかったですが、編集内容の要約のIDSを組み合わせて、だいたいの形はわかりました)を作成した者と、「凸」の異体字の荒らし者とは同一かどうかはわかりませんが… --johotogoshinentai 2012年2月9日(木) 18:03

  • そうですね。SPAM投稿と判断したものは記録しないことにしましょう。--kamichi 2012年2月10日(金) 08:17

「タグ」機能の導入の提案

「タグ」機能の導入を提案します。グリフウィキでは、文字の検索が難しいので探したい文字やグリフを探せず、たまには重複グリフも登録されてしまうこともあります。文字やグリフに「タグ」を付ければ、グリフを探すのがもっとやすくなると思います。タグには文字・グリフのdescriptionや(日本語の)通称などが適当でしょう。

たとえば、

  • 汶(u6c76) に「さんずいに文」というタグを付けると、「さんずいに文」で検索すれば 汶(u6c76) のグリフが検索結果に出る
  • 燁(u71c1) に「火へんに華」というタグを付けると、「火へんに華」で検索すれば 燁(u71c1) のグリフが検索結果に出る
  • 髙(u9ad9) に「はしごだか」と「はしご高」というタグを付けると、「はしごだか」や「はしご高」で検索すれば 髙(u9ad9) のグリフが検索結果に出る
  • 𠮷(u20bb7) に「つちよし」と「つち吉」というタグを付けると、「つちよし」や「つち吉」で検索すれば 𠮷(u20bb7) のグリフが検索結果に出る

このようです。 --johotogoshinentai 2011年12月5日(月) 10:31

  • ご意見ありがとうございます。一つ思うのですが、これほど数が多くなると「探すことができる」よりも「探した時に取りこぼしがない」ほうが重要かと思います。すると「文」ではなくてやはり機械的な書き方がいいかなと思います。そうなるとおそらくIDSになると思います。ですが、関連字ではだめなのか、という気もします。関連字がつけられないグリフにIDSを充ててもらうというのはいかがでしょうか。--kamichi 2012年1月5日(木) 23:55

    • そういえば、確かにIDSを割り当てるのが役に立ちそうですね。IDSはu2ffxで始まるグリフなら自動付与ができそうですし。でも、IDSで表現できないグリフはどうしたらいいのでしょうか。(たとえば、私はひらがなの「ん」みたいな字も見た覚えがありますが、その字は「ん」とは関係ない字です。) --johotogoshinentai 2012年1月7日(土) 19:22
      • たとえば、その「ん」みたいな字ですが、言葉だったらどう表現するでしょうか?関連字より1つ関連の薄い「みたいな字」のタグがいいでしょうかね。自由記述ではなくいくつかのタグのバリエーションでまかなえると、検索漏れがなくなると思います。今のところ「関連字」、「IDS」、「みたいな字」あとは「(書籍)この本のこのページの何行目」、「(風景)この時点のこの場所でこの方角」とかですかね。--kamichi 2012年1月8日(日) 12:27
      • 気になったので、関連字のないレコード(エイリアス除く)をピックアップしてみましたが、優に1万を超えますね。きちんと考える必要があると再認識しました。--kamichi 2012年1月8日(日) 12:47

      • 「みたいな字」は関連字を知らないとき助かると思います。私が言った「ん」みたいな字はdkw-00117のようです。この字の関連字は「也」になっていますが、この字と「也」の関係を知らないのにこの字を探したいと、「みたいな字」が助かるでしょう。あと、書籍の情報ならdkwやzihaiの命名方法でいいでしょう(文字に固有番号が付けられているとその番号を(dkw)、そうではないとページ番号+順番(zihai))。風景の情報は、入力も探すのも難しくなるかもしれません。 --johotogoshinentai 2012年1月14日(土) 04:45

  • ということで実装しました。試行を開始します。--kamichi 2013年1月30日(水) 21:46

unc-xxxの廃止を提案します

今はExt Dがエンコードされているので、unc-xxxみたいな臨時名前が必要なくなっています。むしろunc-xxxには問題点があります。

unc-xxxの問題点

  • 関連字が正しく設定されていない
  • 臨時名前だったので、エンコードされると必要ない
  • unc-xxxが実体でu2bxxxがエイリアスになっていると、エディタ検索のときにunc-xxxとu2bxxxとの両者が出てしまう

  • 賛成します。最終的には白紙化が望ましいと思います。--kamichi 2011年11月17日(木) 21:10

提案

  • エイリアスになっているu2bxxxを実体化
  • unc-xxxを白紙化 (またはu2bxxxへのエイリアスに変更)

以上、--johotogoshinentai 2011年11月17日(木) 15:21

  • unc-xxxをすべてu2bxxxエイリアスに変更しました。白紙化しなかった理由は、unc-xxxがほかのグループで使われているからです。 --johotogoshinentai 2012年4月9日(月) 04:43

  • 「白紙化の抑制について」の通り、白紙化は抑制の方向で考えています。--kamichi 2013年1月1日(火) 15:46

命名記述の変更・統合の提案

jx1-2000-####、jx1-2004-####について

JIS X 0213:2000の字形は基本的にJIS X 0208(j90-####)の字形と同じなので、jx1-2000-####が別に必要なのかと思います。jx1-2004-####をjx1-####に変更し、jx1-2000-####はj90-####に統合するのはいかがですか。
  • jx1-2000-4f60jx1-2004-4f60が存在します。この文字はJIS X 0208になく,JIS X 0213:2000で追加された文字なので,j90-####では命名できません。--spinda-kkmr 2011年5月26日(木) 10:02

    • でも、JIS X 0213はJIS X 0208の拡張なので、事実上j90に統合してもいいんじゃないでしょうか。j90の意味を単純な「JIS X 0208:1990の例示字形」から「JIS X 0208:1990とJIS X 0213:2000の例示字形」に拡張しても問題はなさそうですが… --johotogoshinentai 2011年5月27日(金) 23:24

  • j90 の意味を拡大するのも有りだと思いますが、エイリアスを減らす事よりも、そもそも別名が幾らたくさん有っても邪魔にならない様なシステム(インターフェイス)にした方がいいのではないかと思います。と言うのは主に「最近更新したページ」にエイリアス自動更新がズラズラ並ぶ点についてですけど…。無印 UCS に実体グリフを置かないという方針を今後進めるならエイリアスはどんどん増える訳だし、今でも -g やら -k やら -v やらエイリアスをどんどん置いてっていいんだし。
  • (屢や棘なんて何が違うのか分かりませんがね。)— sayunu 2011年5月29日(日) 15:05

  • 「白紙化の抑制について」の通り、白紙化は抑制の方向で考えています。--kamichi 2013年1月1日(火) 15:46

Unicodeのmulti-column chartを参考することについて

Unicodeのmulti-column chartではエラーがよく見えるので、なるべく参考しないほうがましです。(今は思い出せませんが、エラーを多く見つけた記憶はあります。) ISOのsingle-column chartを参考したほうが望ましいです。 --johotogoshinentai 2011年4月4日(月) 17:17
  • ご指摘ありがとうございます。最終的にはISOの情報の方が確実ですが、現状でISOのmulti-columnが公開されていないので、とりあえず、という意味で考えています。--kamichi 2011年4月4日(月) 18:29

  • 議論を閉じます。--kamichi 2012年12月4日(火) 08:56

UCSのK欄について

韓国では、漢字の字形に関する標準が存在しません。UCSチャートのK欄字形はただの例示なので、韓国の標準字形を示すのではありません。たとえば、韓国では「令」はu4ee4u4ee4-gが混用されていて、「艹」はu8279ufa5eufa5dが混用されていて、「辶」はu8fb6ufa66u8fb6-tが混用されています。つまり、K欄の字形は特に意味がなく、参考用でも別に価値がありませんので、-kグリフを作る時にK欄の字形を必ず従うべきではありません。 --johotogoshinentai 2011年2月11日(金) 20:38

  • ありがとうございます。これはK欄に限らない話です。T欄やJ欄でも起こりえます。台湾はフォントによって字形に差が出ます。日本でもu4e45@3u4e45@4など、フォントによって揺れはあります。つまり、程度の差です。ですので、UCSの地域欄というのは「標準字形」を表すのではなく「地域文字コード(規格)の例示字形」を表しているにすぎません。それで、話を戻しますが、その結果、主観によってグリフウィキに登録される字形が揺れるのは望ましくありませんので、とりあえず「例示字形」を根拠として、それ以外は「-itaiji」「-var」にする、という方針を立てています。ですので、私としてはK欄はKS規格の例示字形に従うのが妥当かなと考えています。--kamichi 2011年2月11日(金) 21:30

  • 「とにかく例示字形に従えばいい」というのは、後ろ向きな態度と思うかもしれません。その反対に、たとえば自分のフォントを作るときに、自分のポリシーで字形を選択できる、というのはグリフウィキの利点だと思っていますが、現状では1字1字字形を指定するのは大変です。この煩雑さに対して、グループを記述するときなどに自分の嗜好を指定できるような機能があればよいと思っています。アイデアがありましたら教えてください。--kamichi 2011年2月11日(金) 21:35

    • 私もそのような機能があれば便利だと思います。例えば,之繞u8fb6/ufa66,示偏u793a-01/u793b-01,食偏u2967f-01/u98e0-01のいわゆる許容3部首について,JISに従うフォント,旧字(左)で揃えるフォント,新字(右)で揃えるフォント等を作成できると便利です。しかし現状では,例えば之繞は,JIS外の文字についてはu8fb6ufa66が混用されています。このような新字と旧字で異なる部品を持つ文字については,部品の方に何らかの情報を与えることで,一括して旧字もしくは新字で統一されたフォントを作成できるようになるのでは,と考えます。--spinda-kkmr 2011年2月12日(土) 10:44
    • 追記。許容3部首のほか,草冠u8279-k03/u8279-03や青u9751-02/u9752-02等も,上記のように統一できると便利だと思います。特に草冠はu8279-k03u8279-03が混在しているので,統一できると便利です。--spinda-kkmr 2011年2月12日(土) 10:54

  • 本件ですが、別でも話題になりましたが、UCSの「-k」はISOのKソースに従い、KS規格に沿うのは「k0-####」とします。以上で閉じます。--kamichi 2013年2月10日(日) 17:24

juki-####について

  • yasuoka氏が作成している“juki-####”ですが,これは住民基本台帳ネットワーク統一文字だと思われます。命名ガイドラインにて追認してもよいのではないでしょうか。--spinda-kkmr 2010年12月27日(月) 19:02
    • ご提案ありがとうございます。追加しました。--kamichi 2010年12月27日(月) 22:20

台湾教育部異體字字典グリフの命名について

最近,台湾教育部異體字字典 を典拠としたグリフが登録されていますが,現状では他の異体字と同じ“u####-itaiji-###”で登録されています。これでは典拠が分かりにくいので,台湾教育部異體字字典のための命名が必要と考えます。案としては,“twedu-######-###”(英字1字+数字5桁,枝番3桁)を提案いたします(用户-对话:kamichiを参考にしました)。--spinda-kkmr 2011年12月4日(日) 19:04

  • 追記。6桁-3桁の後にさらに数字がつく場合は,“twedu-######-###-#”とします。--spinda-kkmr 2011年12月4日(日) 19:30

  • 賛成です。ちょっと長いですが仕方ないですね。--kamichi 2011年12月4日(日) 22:39

匿名利用者の利用制限について

  • 最近,匿名利用者による無意味なグリフの乱立や登録利用者に対する誹謗中傷行為などが見られます。匿名利用者に対して利用制限を設けるべきだと思います。以下,試案です。

    • 1)匿名利用者による自由命名グリフ作成の禁止
      • 匿名利用者がでたらめなグリフ名を打ち込んでsandboxのように利用してしまう例が多発しています。相手が匿名では命名意図を確認できませんので,議論のしようがありません。そこで,匿名利用者による自由命名グリフ(命名ガイドラインに沿わないグリフ)を禁止して,作成した場合は内容の如何を問わず削除する,というのはどうでしょうか。
    • 2)匿名利用者による“利用者-会話”ページへの書き込み禁止
      • 匿名利用者による一方的な誹謗中傷が発生しています。相手が分からないのでこちらは最小限の反論を書き込むことしかできません。そこで,“利用者-会話”ページへの書き込みを登録利用者に制限し,誹謗中傷をできないようにするべきと考えます。

  • 便宜的に番号を振りました。
    • (1)ですが、私は若干考え方が違います。グリフウィキ全体のことを考えてくださるユーザー(現在のコアユーザー)は、おそらく命名規則を尊重し、またなるべく命名規則にのっとったグリフ「だけ」が存在することが望ましいとお考えになると思います。一方で自分の外字集合を管理したいとだけ思っているユーザーは命名規則に縛られない「abc001」のような自由命名をしたいと考えると思います。これをユーザーアカウント(たとえばabc)をとって「abc_001」といいうグリフにするように強制することも1つの考えですが、アカウント取得を強制するか否か、は慎重に考えたいと思います。現状で確かにsandbox的なグリフが散在していますが、掃除が必要とまではいっていないかなというのが私の認識です。
    • (2)は、たしかに定期的に発生しますね。運用者としては制限したい方向に意見が偏ってしまいますので、ほかの方のご意見も聞きたいところです。
  • 以上、kamichi 2011年11月3日(木) 11:48

  • 匿名利用者の利用については多少際限があった方がよいとおもいます。
    • ①すべての既存グリフまたは命名規則のある既存グリフの編集の禁止。
    • ②新規グリフについてはあるプレフィックスを必須とする。(ex. temp_ から始まらなければならない)
    • ③新規グループページの生成の禁止。
    • ④利用者ページは利用者による利用制限の設定(匿名利用者の更新の許可設定)
  • ①については今までのリバース作業をみているとできれば行ってほしいと思います。 -- tsuruki 2011年11月4日(金) 21:57

    • 私もtsuruki氏を支持します。利用者ページについては「本人のみ編集可」「登録利用者のみ編集可」「だれでも編集可」の3つから,“利用者-会話”ページについては「登録利用者のみ編集可」「だれでも編集可」の2つから,本人が選択できるようにすればよいと思います。--spinda-kkmr 2011年11月6日(日) 12:48

試験的措置の導入

  • 試験的な措置として、まず一括変更系の匿名利用者への利用制限を行います。「部品の一括変更」および「旧部品の一括変更」を対象とします。--kamichi 2011年12月30日(金) 18:33

利用者ページについて

  • 利用者ページは本人以外でも編集できてしまうようです。本人以外編集できないようにした方がいいと思うのですが。--spinda-kkmr 2011年8月6日(土) 15:29
    • ご指摘ありがとうございます。UI部分はWikipedia相当で設計しましたが、勘違いしていました。修正します。--kamichi 2011年8月7日(日) 10:49

Ext Eの字形について

Unicodeに追加が予定されているCJK統合漢字拡張E(字表:ExtE仮)のグリフ(extd-#####)については,仮想J字形で作成するという方向でよいのでしょうか。--spinda-kkmr 2011年5月31日(火) 20:26
    • はい、そのつもりでおります。といいますか、「-jv」に移行する前提です。ただ「extd-」については、地域ラベルをつけることを想定していないので、現状で若干問題があります。とりあえず埋めることを優先し、符号位置が決まったら、地域分化も含め移動することを考えています。--kamichi 2011年5月31日(火) 21:14

文字情報基盤 文字情報一覧表の利用について

http://ossipedia.ipa.go.jp/ipamjfont/moji_list.html にて,住基ネット統一文字コードや,登記統一文字番号などの貴重な資料が公開されているようですが,ライセンスがグリフウィキとは異なるようです。 こちらのページのデータを利用してjuki-####などのグリフを作成することは可能でしょうか。--spinda-kkmr 2011年5月27日(金) 12:43

  • この一覧表に編集著作物やデータベースの著作権があるのか自体怪しく見えます(並び順も汎用電子順で創作性のある部分は無さそうなので、ハローページなどのように著作権が無い気が)が、仮に著作権があったとしてもそれを構成する素材にはその著作権はかからないので法的な問題はないはずです。--匿名利用者 2011年5月27日(金) 20:40

  • グリフウィキで参照するのは字形の部分と、命名のための番号の2つと思いますが、問題ないと考えています。--kamichi 2011年5月31日(火) 21:14

2011/5/11の荒らしとみられる行為について

  • どうやら2系統の模様で、片方は荒らしではなく初心者の可能性があります

    • 昨日の18:43~18:47は、u725c-01u6728に自動変更されてしまっていました。fxさんと私、匿名さんがすべて戻しましたが、やはり最近荒らしが増えた気がします。今後、誰もグリフウィキに接続していないとき、誰かがそんな風に荒らしたら、大変になってしまいます。
    • 部品の自動置き換えを、せめて匿名利用者にはできないように設定するのはいかがでしょうか。自動置き換え機能では荒らすのが易く、それはグリフウィキが荒らしに弱いのを示しています。 --johotogoshinentai 2011年5月11日(水) 12:52
    • 他の方のご意見も頂きたいと思いますが、私も同意します。本当は登録・匿名で機能に差異はつけたくないのですが --kamichi 2011年5月11日(水) 12:55
    • あ、ちなみに昨日の自動変更を戻した匿名ユーザーは私(出先のパソコン)です。--kamichi 2011年5月11日(水) 12:56
  • お、懐かしい話ですね(GlyphWiki:井戸端-保存#i4)。最低限、部品の一括置換は登録利用者のみに制限するのがいいと思います。貢献であれ、荒らしであれ、多数の既存グリフに影響を与える操作だし、そこまで貢献したいという人なら利用者登録をするくらい大した障害ではないでしょう。匿名で実行できる利点が思い浮かびません。(旧部品の一括更新をどうするかは微妙ですが。)
  • ところで、井戸端でなく上地さんの会話ページでやっているのに違和感が。— sayunu 2011年5月20日(金) 00:15
    • すみません。確かにそうですね。--kamichi 2011年5月20日(金) 14:13
  • 私の案としましては,匿名利用者は,「部品の一括更新」「自由命名グリフの作成」この2つを制限するというのはどうでしょうか。最近,匿名利用者によるtsundereのような,明らかな「立て逃げ」行為が多く見られます。だからといって自由命名を完全に禁止すると窮屈になる(例えば,ouichizaを命名できなくなる)ので,自由命名は登録ユーザーに限るのがいいと思います。登録ユーザーであれば,他のユーザーが自由命名の意図をそのユーザーに確認することができます。--spinda-kkmr 2011年5月28日(土) 10:38
    • この項目は井戸端に移動したほうがいいと思います。--spinda-kkmr 2011年5月28日(土) 10:40

    • たとえ投稿が立て逃げでも、荒らしではないのなら別に問題ないと思います。グリフの生成を限るのはよくないと思います。 --johotogoshinentai 2011年5月28日(土) 11:22

  • この事項については、「(旧)部品の一括更新」については匿名利用者の利用が制限となり、「組み文字」については命名ガイドラインの適用ということになりました。また公開プロキシの利用者の投稿も制限となりますので、これ以上の匿名利用者への制限はひとまず行わないということで結論付けたいと思います。またいったん井戸端に移動します。--kamichi 2012年1月11日(水) 12:49

登記統一文字番号について

  • “toki-########”は,登記統一文字番号として利用されていますが,命名ガイドラインに無いようです。命名ガイドラインに追加したほうがよいと思います。--spinda-kkmr 2011年6月21日(火) 12:20
    • ありがとうございます。追加します。--kamichi 2011年8月7日(日) 10:50

kumimoji-u2ff#-、u2ff#-について (取り消し)

この2つは統合が必要だと思います。「u2ff#-」そのものが「組み文字」の意味を含めているので、kumimoji-u2ff#-をu2ff#-に統合したほうがましだと思います。実際、kumimoji-u2ff#-のほうよりu2ff#-のほうが多いです。

私の提案は以上です。 --johotogoshinentai 2011年4月24日(日) 16:53

  • kumimoji-というのは組み文字のためのprefixで、数文字を組み合わせた記号であることを意味していて、漢字の構造を表すIDSのu2ff#-と統合するわけにはいかないでしょう。(私自身は組み文字はGlyphWikiの対応すべき字から外れていて、実装するにしてもkumimoji-u2ff#という表記はふさわしくないと考えています。こういった組み文字は本来横組みと縦組みで組み方が変わるはずで、IDSの表記を転用するのも奇妙です。たとえばu337fに名付けるならkumimoji-kabushikigaisha-horiのような表記の方がマシでしょう。)--mandel59 2011年4月24日(日) 17:25

    • あぁ、確かにkumimoji-は、そんなにも使えますね。では、kumimoji-そのものは統合しなく、kumimoji-u2ff#-だけをu2ff#-に変えるのがましでしょうね。 --johotogoshinentai 2011年4月25日(月) 00:50

    • sayunuさんのコメントは当日確認しましたが、返事するのを忘れていました。この提案は取り消します。 --johotogoshinentai 2011年5月27日(金) 23:24

kk03さんへのご助言要請

確かにkk03さんは多数のグリフを登録していますが、グリフの質が何か悪そうな気がします。私がそれをたまに直しているのですが、直すことにも限りがありそうかも、と気がしてきました。

よければ、誰かがkk03さんにデザインの助言をくださってほしいです。私も助言をあげたいですが、私は日本語がうまくないので、やはり助言は難しいです。すみませんが、お任せいたします。 --johotogoshinentai 2011年4月22日(金) 22:17

  • といいますか、今残っている字が難しい字が多いので、仕方がないと思います。別の字を優先的にやっていただくよう、考えます。多分Ext.Eがいいと思います。ご指摘ありがとうございます。--kamichi 2011年4月22日(金) 23:27

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

ドキュメントページのライセンスについて

  • 本来グリフウィキのライセンスは「ライセンスなし」相当で、これはドキュメントページもそうです。しかし、これは結構不便で、他のデータをグリフウィキ上で再現することができません。(続く)
  • そこで、ドキュメントページについては、ライセンスタグを導入して、そのタグを張っておくと別のライセンスが適用されていることを明示するような表示をさせたいと思います。--(続く)
  • とりあえずGPLとCCでしょうかね。たとえばLicense:GPLみたいな感じを想定しています。--kamichi 2010年12月28日(火) 11:53

既存グリフの字体の変更について(匿名ユーザー・登録ユーザー)

  • 今般、既存グリフの字体の変更が多々行われ、字体に関する議論および移行が進んでいない中で、もったいない状況にあると思います。登録ユーザーの場合は利用者-会話ページで呼びかけることができますが、匿名の場合、リバートした際のサマリーに書くのがせいぜいです。(つづく)
  • かといってシステム側で制限するのは本意ではありません。しかしいくらか制限を設けるべきなのかもしれません。この議論はすでに提議されていて、私は「トラブルドリブン」と書きました。今がその段階のような気がします。(つづく)
  • 原因となる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

グリフウィキに字形が登録されることの社会的影響について(戯言)

予想されたことですが、面白いケースを発見しました。『絶対読めない漢字』(向笠修司著、幻冬舎コミックス発行、2010年)にamanohasidateが掲載されているのですが、出典未詳とし、「この漢字はWEB上のフリーデータベースの中に、国字のカテゴリとして掲載されていた」とあります。(明示してくれれば宣伝になったよかったのですが)おそらく、これはグリフウィキを指しているものと思います。

amanohasidateの字形自体は過去にWeb上にいくつか見受けられます。いずれも出典にはたどり着けません。また上記書籍は形声字の声符に意味を見出していたり、内容は厳密でない印象を受けますので、あくまで読み物の類に入ると思いますが、それでもグリフウィキのデータが出版物に引用されたという意味では、複雑な心持です。以上感想でした。--kamichi 2010年9月10日(金) 11:46

  • 追記:そもそもこの本を購入したのは、前に問題となった「ちくわ」が掲載されているからでした。他にも今昔文字鏡を出典とする文字がいくつか載っている、ある意味危険な本です。--kamichi 2010年9月10日(金) 11:50

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

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

(1)指定なしの場合に地域優先順位をつける

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

(2)指定なしを「J欄」または「仮想J字形」とする

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

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

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

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

(3)地域指定なしを捨てる、あるいは抽象化する

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

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

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

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

ということで

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

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

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

    • 1つ誤解を生んでいました。「仮想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デザイン」を適用するのは行き過ぎではないでしょうか。そうすると「簡体字としてしか使われない文字」の定義が問題になりますが,例えば,
  • u7e9f-01 (糸) u8ba0-01 (言) u9485-01 (金) u9963-01 (食) 等のように簡体字の偏をもつ文字は,文字全体としても簡体字としたほうが自然ではないでしょうか。「日本デザインの文字」というグリフウィキの方針と異なってしまいますが,このほうが利便性は高まると思います。--spinda-kkmr 2010年8月13日(金) 19:11

    • ご意見ありがとうございます。たしかに明らかに簡体字と思われるものまでJデザインにすべきかという問題があります。それでこの「明らか」というのが結構曲者で、たとえばu57b4は、一見簡体字のように見えますが、正式な簡体字のルールでは簡体字になりません。このような判別不能なものがままあります。ですので1つの考え方としてまずは「類推適用可能な偏旁簡化部品」が用いられている(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
    • その程度(左下カドのデザインの違い)であれば私は構いませんが、u7eebu590c-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

今後の方針

Jソースの追加

  • 最終的には「UCS符号位置グリフ」を廃止し、すべてそれぞれのソース符号をつけることにします。現状と差が出るのは「-j」が増えるのみです。
  • 「-j」が指すものは、ISO/IEC 10646規格にJソースが提出されているものは「Jソースそのもの」となり、それ以外は「仮想Jソース」となります。
  • 「仮想Jソース」はAnnex.S(今後整理される予定)の範囲内で仮想的なJ字形(端的にいえば表外漢字字体)に直したものを指します。諸橋『大漢和』辞典にソースがある場合、それにならってもよいと考えていましたが辞典特有の「4画草冠」などで統一性が取れないため、諸橋・字典体は仮想Jソースには適合しないと考えます。1つの典拠として別の名前を付けてください(諸橋『大漢和』は「dkw-」が用意されています)。
  • 「仮想Jソース」については混乱が予想されますので、議論のつどガイドラインを修正していきたいと考えます。

UCSグリフの扱い

  • いったんすべて「-j」に機械的に移します。ですので現状ではまだ「-j」は作らないでください
  • 今後UCS符号位置グリフのページを開いた場合、特別ページとして各ソースへのリンクページにします。UCS符号位置グリフは予約として編集できないようにします。
  • UCS符号位置グリフのグリフ画像についてはソース別優先度をつけて提示するようにします(あるいは存在するものすべてを並べて提示する案もあり)。

G,TデザインとKAGEエンジンとの整合性について

  • Gソース、Tソースに見られる特徴的なデザイン部分については以下にならってください。これ以外は修正の対象とします。

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

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

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

ここまで kamichi 2010年9月11日(土) 11:17

再検討に入りたいと思います

  • 以下のように方針を変更したいと思います。
    • 仮想J字形は定義しない
    • 地域ソースは規格票(準ずるもの含む)のみとし、ほかは番号(-###)のみとする
    • 「-itaiji」「-var」も番号に移行する
    • 部品も同様に地域ソース化に移行する
  • この趣旨は、UCS符号位置グリフが抽象的な字体概念であり主観では統一が無理なこと、および仮想J字形が実質的にUCS符号位置グリフを継承し、問題が解決しないこと、異体と異形も同様に統一解釈が難しいこと、を解決するものです。--kamichi 2010年10月18日(月) 08:46

  • 上記方針に基づく変更手順
    • 無印UCSの新規作成および既存編集を停止
    • 無印から地域ソース、異体字・異形字から番号への移行を簡単にする機能付与
    • 適宜自動化(まだアイデアなし)
    • 現状では余裕がないのでスケジュールは未定
  • 以上は --kamichi 2010年10月23日(土) 00:00

    • 最近、匿名で仮想J字形に一括更新している人がいるための苦肉の策の対応だと思われますが、折角仮想J字形をどうするかを検討(というほど進んでませんが)していたのに「定義しない」とは残念です。(続く)
    • で、質問があるのですが、(1)「仮想J字形は定義しない」というのは、「仮想J字形は個人的な解釈でどう作成・変更しても良い」という意味なのか、「仮想J字形を作るのはやめましょう」という意味なのか、それとも別の意味があるのか教えてください。(仮想J字形反対派としては「やめましょう」であってほしい)
    • (2)「番号に移行する」のは即時でいいのですか。それとも移行時期が決まっているのですか。(異体字や部品のバリアントを作りたい時に迷うので)
    • (3)これらは非漢字グリフに対しても同様ですか。(非漢字グリフを作りたい時に-jを付けるのが面倒くさいというのがある)
    • 以上 daekyo でした。-- 2010年10月23日(土) 00:37

    • コメントありがとうございます。本来仮想J字形を推進しようとしたのは「慣れている日本字形でExt.B等を使いたい」というメリットを考えていましたが、現状ではそのことが「Ext.Bの未定義部分を早く埋めたい」という意図と逆に作用している(エネルギーがある意味浪費されている)と考えます。一種のアドバルーン的な感覚で「再検討」を掲げてみました。おっしゃる通り「苦肉の策」で、まだ悩んでいます。研究費の都合上、未定義部分を早急に埋めなければならない、という方針と反作用しない形の解決を模索しています。
    • 以下回答です。
      • (1)地域ソースに対する仮想字形は認めないことを考えます。つまり仮想J字形は存在しないことになります。仮想字形はすべて番号・別の命名グリフに移ってもらいます。
      • (2)部品についてどうするか迷っています。符号位置グリフは(1)で解決するとして、部品グリフでも同じような字形競合が起きると思います。煩雑になりますが無印部品(u####-##)を廃止しすべて番号(u####-##-###)に移行するのが妥当でしょうか?
      • この再検討もまだ議論したわけではないですし、私も迷っています。作業量もたいへん多いので(特にUCS符号位置グリフを地域ソースに振り分ける部分をどうするか。いったんすべて番号に移して地域ソースにエイリアスを張る?)スケジュールはまだ未定です。
      • (3)非漢字グリフは対象外と考えます。
    • 以上は --kamichi 2010年10月23日(土) 08:45
      • (1)、(3)はわかりました。では、Jソースの存在する無印UCSグリフまで意図的に「いわゆる旧字体」部品を使用して書き換えている匿名さんを何とかしてください。kamichiさんの考えに沿っていませんし、リバートするのがだんだん嫌になってきました。
      • (2)についてなのですが、移行時期が決まるまでは「var」や「itaiji」で新規登録しても構わないということですね。あと、番号制というのは地域ソースや地域偏化変形(u####-g##とか)もエイリアスにするということなのですか? そこまではやり過ぎな気もしますが、その方が統一感が出るのかもしれませんね。
    • 以上 daekyo でした。--2010年10月24日(日) 00:26

    • 最近暇が無いので井戸端会議を放置してましたが、10 月 23 日に上地さんが提示した様な方向性で基本的によい様に思います。
    • 「仮想 J デザイン」に私は違和感が有って、それというのは、「規格票 J 欄のデザイン」と「日本式デザイン」は本来別の概念なのにゴッチャになるからです。ほかの欄も同様です。規格票 J 欄は日本式デザインの一例ではありますが、日本式デザインの正式な代表ではありません。「規格票 J 欄に従う」となると、例えばボクニョウ(攵)の三画目の頭が字に依って接続だったり解放だったりすればそれを厳密になぞる事になりますが、それは決して日本式デザインの反映ではありません(この例について実際に規格票がどうなってるかは見てません)。
    • それなので、「-j」が曖昧な「仮想 J」ではなく、実際の規格票デザインを指すと明確に定義されるのは好ましいです。どの規格に拠るのかはっきりしておきたい所ですが、「ISO/IEC 10646 の最新版」でいいでしょうか。
    • 仮想日本式デザインにも需要が有るでしょうから、それは別の命名で登録すればいいでしょう。日本式デザインのフォントを作るなら、ボクニョウの三画目なんて規格票がどうあれむしろ統一されていた方がいいです。
    • しかし、「itaiji」の廃止には賛成しません。itaiji は現在の定義では「その UCS 符号位置には統合されないが、ほかに置き場が無いので間借りしておいた字形」を表す筈です。一方「var」は「Annex S に従ってその符号位置に統合される字形」。現在の命名方針で行けば、例えば「u4e00-」で始まる名前のグリフは(itaiji を除き)全てその符号位置に表現される字形な訳で、それと異質な itaiji を混ぜてしまうのは好ましく思いません。両者の区別について「統一解釈が難しい」との事ですが、どんな点が難しいでしょうか ? 少なくとも私はそれを判断できない事例に直面した事が無いんですが。
    • 余談ですが、そうした例外的な itaiji が符号位置の名前空間の下位に置かれている現状自体あまりすっきりしていないので、「itaiji-u4e00-001」みたいな接頭辞とか…。これが適切か分かりませんが。
    • 部品用グリフの命名はどうしたらいいんでしょう。「部品用字形」なんて物が規格票に載っている訳ではないので、現在の「-g」は「G 欄でよく見掛けるデザイン」でしかなく、G 欄の全てのイトヘンがその形である保証は無いし、全部番号にしてしまうのが一番単純かも知れません。でも、取り敢えず部品については蓋をして現状維持がいいかも知れません。
    • 部品を表すのは二桁の番号、異字形を表すのは三桁の番号というのも紛らわしい感じはしますね…。
    • 以上 — sayunu 2010年10月23日(土) 19:35

    • 私が「仮想J字形」を支持したのは,1つのフォントにまとめた時にGソースやTソースが交ざってしまうと,例えば,掛算冠u4ea0-03や麻垂u5e7f-05,草冠u8279-03,之繞u8fb6u4ea0-tu5e7f-gu8279-t03u8fb6-tが交ざってしまい,フォントとしてデザインの統一がとれないと考えたからです。
    • 「規格表のJソース」と「仮想J字形」を区別する必要はあると考えます。仮想J字形専用の接尾コードを新設するというのが最も現実的でしょう。
    • 「-var-」「-itaiji-」は維持したほうが良いと考えます。部品が2桁,異体字が3桁というのは紛らわしいです。また,ISO/IEC 10646で包摂されるかということも区別が必要と考えます。
    • Jソースの無いUCS符号位置グリフに登録する字形については,非常に難しい問題です。規格表を優先するか,デザインの統一を優先するかで変わると思います。個人的には,デザインの統一という観点から,「仮想J字形」を支持していましたが,他の方の意見も待とうと思います。
    • 以上,--spinda-kkmr 2010年10月26日(火) 19:59

(再)途中経過

なかなか本腰を入れてグリフウィキに手を入れる時間が取れていません。さらに追加でご意見をいただきましてありがとうございます。

現在Ext.Bを中心としたグリフ追加登録が活発ですので(ありがとうございます)、ソース分離の件については、さらにもう少し延期したいと思います。仮想Jの是非については、まだ迷っています。もし残す場合は少なくともJソースとは分離して別のラベルを振ることになると考えます。「仮想J」という名称についても議論が必要かもしれません。また、ソース分離後の花園フォントについては提案にもあるようにソースごとの優先度を設定して拾っていくことになります。--以上kamichi 2010年11月15日(月) 10:05

  • 「仮想J字形」が定義されなくなってから1か月が経ちましたが,之繞にTソースの字形が使われるなど(例・u285cf@1,u28512@1),デザインの不統一が出始めています。草冠も,u8279-k03が使われているものが多く見られます。之繞や草冠など,最小限のガイドラインは,やはり必要ではないでしょうか。--spinda-kkmr 2010年11月18日(木) 19:53

今さらですが

汎用電子にあるグリフについては汎用電子のものを採用しませんか? 平成明朝体なのでJISのデザインとの不整合は発生しませんし、日本で見慣れたデザインに統一されますし、拡張Bのかなりの部分をカバーしますし、恣意が入り込む余地もありません。

グリフが複数あるものについてどれを選択するかの問題は残りますが、他国の字形よりはマシでしょう。--emk 2011年1月11日(火) 08:33

  • ご提案ありがとうございます。現在近いことを考えています。ただ、汎用電子についてもソースによってはそのままUCS-jvに使うのをためらうケースもありますので、多少抽象化というか汎用電子をもとに「-jv」を定義する形を考えています。もう少し手元で練ろうとしている状況です。--kamichi 2011年1月11日(火) 08:59

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

  • グリフウィキに登録されているグリフをストローク種別の指定で検索するテストページを作成しました。ストロークを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

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

派生:筆順について

  • ここにぶら下げていいのかわかりませんが、筆画検索に関係あると思ったのでここに書きます。(続く)
  • ふと疑問に思ったのですが、(1)筆順は日本、台湾、中国本土によって違うものがあるんですが(有名なものは「必」)、その場合は-j/t/gで別グリフを作る必要があるのでしょうか。(2)部品を使うと筆順が狂う場合(例えば「囗」国構え)は態々分解しなければいけないのでしょうか。(それでは部品の意味が無くなってしまいそうですが) --daekyo 2010年9月9日(木) 18:39
    • まず、(2)国構えなどの件ですが、私はIDSを想定したものがよいと考えます。つまり、国構えなどの嵌め込みは、書き順は内側が先であってもKAGEデータは外が先、内が後が望ましいです。言い換えると厳密な筆順は必要ないと思います。あるいは筆順は別のメタ情報で書くべきと思います。(続く)
    • (1)については悩ましいところです。個人的にはあまりこだわってほしくないところです。こちらもメタ情報で地域ごと、流派ごとの書き順を記述できると思います。(続く)
    • メタ情報で書き順と記述するとして、ツールとして筆画を区別する方法(筆順と結びつける方法)が簡単であればいいのですが、現状ではよいアイデアはないですね。色分け(あるいは単色グラデーション)などでしょうか。KAGEのウィークポイントである「口」が4画になってしまう点も、このメタ情報で3画にまとめられると思います。--以上kamichi 2010年9月9日(木) 19:08

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

明朝体外グリフの削除について

グリフウィキで利用している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

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

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

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

保安のこと

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

寅虎明朝について

  • 今年も寅虎明朝を作成するのでしょうか?まだ結構空きがあるようですが。--uchi 2009年12月29日(火) 20:19
    • すみません、もともとは年賀用を謳っていますので12月頭に公開すべきものでしたが、忙しくて手が回りませんでした。1つ言い訳するならば、丑牛明朝のときは花園明朝には国内JIS規格以外の文字は含まれていなかったので意味があったのですが、現在は理屈としては寅虎明朝のグリフはすべて花園明朝に入ることになるのであまり意味が無いかと思います。--kamichi 2009年12月29日(火) 21:15
    • 色々漁っていた時に目に入ったので、まあ「井戸端」なのでいいかなと思い書き込んでみました。寅虎明朝フォントのリリースよりグリフ埋めの方が重要かとは思います。もう少し前にコメントすればグリフが埋まっていたかなと思いました。--uchi 2009年12月29日(火) 22:49
    • そうですね。まあ、どちらかというとBMPが全部埋まる方がありがたかったですし、あと今uchiさんに重点的にやっていただいているIVDの方が重要だと思います。今助けを求めているリストのようなものがあるといいのかもしれません。--kamichi 2009年12月30日(水) 11:12
    • 実は、単なる二番煎じではつまらないと思って、トラトラをやめて漢字カレンダーを考えていました。部首別に部首内画数1画から31画までの漢字を用意してずらずら並べる…というものです。そうすると用意すべきグリフ数がやや多くなりすぎて止まってしまいました。--kamichi 2009年12月30日(水) 11:12
    • あと、これも一発ネタですが、いま流行の(?)美人時計ならぬ漢字時計を考えていました。さすがに59画まで用意するのは無理があるので、ひとひねり必要ですが。--kamichi 2009年12月30日(水) 11:12

  • みなさまに作っていただいたので、早速公開しました。今考えれば「乕」も含めておけばよかったと思いますが、それはさておき、ご協力ありがとうございました。なお、含まれるグリフにはKAGEエンジンの縦幅調整機能が中途半端になっていましたので、手元でグリフを再生成したものでフォント化しました。ですのでグリフウィキ上で公開されているフォントファイルとは異なります。--kamichi 2010年1月1日(金) 15:37

康煕字典の字形、CNS漢字のグリフ名について

  • 康煕字典の字形を登録したいと考えています。グリフ名をkx-######という形で、Unihanに載っている番号(頭四桁がページ数、下二桁がページ内の位置)と同じにしたいと考えていますが、いかがでしょうか?また、CNS 11643の一面はc1-####というグリフ名になっていますが、12面〜15面についてはc12-####のようにするのでしょうか?--mandel59 2009年12月28日(月) 18:57
    • 康煕字典グリフの命名についてはそれでお願いします。中華書局発行の普及本が対象ですよね。--kamichi 2009年12月28日(月) 20:18
    • あとCNS 11643ですが、基本的に1-7面と15面しかないと思います。それで15面は16進数でcf-xxxxとすることを想定しています。--kamichi 2009年12月28日(月) 20:18

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

  • ついに着手しました。現状ではまだチューンアップが不完全かも知れません。不具合やご意見ありましたらお知らせください。
  • 現状では垂直の「縦線、折れの縦線、縦左はらい」について、他の垂直の縦線とある程度接近している場合に細くしていきます。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 2009年12月30日(水) 19:14
  • tomomo_mysandbox@27で試しましたが、折れ、乙線、縦払いの上に縦線を重ねると少々おかしくなります。
  • これは、始点と制御点が同じX座標で、且つ重ねる縦線の始点と制御点のX座標が同じであると起きるようです。 tomomo_mysandbox@28のように、折れ線の始点と制御点をずらしたときや、重ねる縦線の始点と終点をずらしたときや、複曲線では起きないようです。--tomomo 2009年12月30日(水) 20:12
    • すみません、先の修正で間違えました。再修正しました。調整終了後に全グリフを再生成するので、おかしくなった分はそのままでお願いします。--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

関連字表示の改良について

  • たたき台として、以下を作ってみました。
    • http://glyphwiki.org/springGraph.swf
    • 背景を動かすと全体を動かせます
    • グリフを動かすこともできます
    • スライダはグリフの大きさとバネの強さを変化させます
    • テキスト入力欄は「u(2)####」あるいは文字そのものを入力し、「Go」をクリックします
    • 「<」「>」は隣の符号位置を表示します
    • 各グリフはその符号位置を関連字と登録しているデータがまとめて表示されます(現在はデータを更新しても変化しません)
    • 各グリフにマウスカーソルをあてるとポップアップで符号位置が表示されます
    • グリフをダブルクリックするとそのページに飛びます

  • 機能面ではあまりこれ以上の改良は望めません。関連付けのメタ情報の表示程度になると思います。
  • 現時点では関連付けデータがすべて用意されていないので時々迷子になる字がありますが、そのうち直ります。また、関連字の構成手順を直していないので「エイリアスだけど関連字がある」グリフが2回出現するバグが残っています。
  • 最終的にはグリフページの関連字表示をこれに切り替えたいと思います。これによりグリフページそのもののページ表示時間が短縮(flashに任せることで、いわゆるレイジーローディングになるため)されます。
  • コメント等ありましたらお願いします。--kamichi 2009年12月13日(日) 19:04

  • おもしろい表示方法だと思います。しかし、ノートパソコンをつかっているのですが、処理が重くCPU使用率が100%近くなるので少し使いづらいです。あと「艸」を入力すると、「艹」のグループと繋がらないで表示されて、離れていってしまいました。--mandel59 2009年12月13日(日) 23:33
    • ありがとうございます。関連付けデータがすべて反映できていないので早急に用意します。私のPCはノートでもC2Dの2.5GHzなので気にならないのですが、たとえばAtomでは無理かもしれません。ということでデフォルトでグリフページにばねグラフを出すのはやめることにしました。いろいろな環境でどうなるか試してみます。--kamichi 2009年12月13日(日) 23:46
    • 本日C2Dの1.2GHz(vista)で試しました。ややカクカクしますがそストレスがたまるほどではない印象を持ちました。--kamichi 2009年12月14日(月) 23:16

  • 2つほど希望を入れさせてください。1つ目は初期表示として「ばねグラフ」形式で直接接続しているグリフをリスト表示してほしい。2つ目は「ばねグラフ」表示から元の画面に戻るボタンがほしい(自分自身をダブルクリックすれば良いだけですが)。出来れば良いな程度の希望ですがよろしくお願いします。「ばねグラフ」は眺めているだけで遊べますし、動かしても面白いですね。--uchi 2009年12月14日(月) 19:15
    • ありがとうございます。1つ目はつまり、今注目している見出し符合位置と直接異体字関係にある符号位置はグリフページに従来のテーブルで表示する、ということでしょうか。確かにそうですね。「直接リンク」と「すべて(ホップ数の少ない順)」で出すように従来表示を変更したいと思います。2つ目も了解しました。--kamichi 2009年12月14日(月) 23:15

  • 面白い表示ですね。
    • 1) いつまでもジリジリ動いてて落ち着かないなあと感じました。初期状態で力の釣り合う位置に落ち着かせてから表示されれば良いんですが。
    • 2) 初期状態が乱数の様で、同じ文字で二度表示すると並び方が変わってしまうのは不便です。
    • 3) スライダーはグリフの大きさとバネの強さを変える(再配置が起こる)ということですが、単純に全体が拡大・縮小される様には出来ないんでしょうか。
    • 4) あと正直、何段階も辿って行った遙か遠くの文字までブワワーっと最初に表示されて、どんな利点が有るのかよく分かりません。「何親等まで表示」などと指定できればいいんでしょうか。そしてほかの符号位置をクリックで選択すると、そこを中心に再表示される(遠くなった符号位置は消え、近くなった符号位置が追加される)とか。
    • 5) ポインターをかざした時に符号位置だけでなくグリフ名も分かると好ましいです。符号位置が常にグリフのすぐ上に小さく表示されたら、見た目が煩くなるでしょうか。
    • 6) グリフページで、関連字を全て表示するのと、引用された他のグリフを全て表示するのは区別した方がいいのではないでしょうか。AJAX にする手もあると思いますが…。
  • sayunu 2009年12月29日(火) 13:12
    • ありがとうございます。本音としては、まず「表示ライブラリを使ってみたい」が先なので、これが完成系とは言えないレベルです。それで、このライブラリはカスタマイズできる部分が少なく、それ以上は直接ソースをいじる必要があるので改良は困難かと思います。興味の赴くままに継続していじってみるつもりではおります。--kamichi 2009年12月30日(水) 11:29
    • それと関連字については、本腰を入れて関係名称の付与の追加を行います。いま少しずつ準備しています。当面は http://fonts.jp/ts0008/ 型の表示にしようかと思います。--kamichi 2009年12月30日(水) 11:29

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

(2009年9月25日(金) 10:48; kamichi (会話) による @130版の追記分)

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

  • 偏化変形命名グリフの設置には2つの目的があります
    • 部品化に伴いデザインの変更が必要なグリフの登録
    • 将来の自動生成で利用

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

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

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

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

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

関連字の改良について

関連字はグリフウィキにおいてグリフに対する自由な命名および、その対極にある検索性を担保するために重要な要素だと認識しています。現状ではその関連付けはフラット(メタな情報なし)に数珠繋ぎになっており、字によっては無意味に広がって検索性やサイトの利便性を下げている問題がある一方で、さらに関連付けすべき組み合わせが継続して見つかっています。今後このまま拡大していくのではなく、改良が求められると思いますが、その方向性についてコメントがありましたらご教示願います。例えば以下のようなアイデアもあると思います。--kamichi 2009年7月8日(水) 17:41

  • グリフウィキとは別に(最も広義の)異体字Wikiを作り、そこに丸投げ。自由な関連付けやメタ情報を設定できる(もしくはグリフウィキ内にそのような仕組み)
  • (現状では視認性にやや問題が残っていますが)IPSJ-TS0008 のようなグラフ表現で距離と方向、関係をなんとなく提示し、データ拡大を続ける

    • 関連付けられたグリフ相互の「距離」を判定することができるのなら、関連字・異体字欄の配列を「距離」の近い順にソートしてやれば使いやすくなるかと思います。
    • 直接関係ないかもしれませんが、各ユーザー占有グリフに不適当な関連字が設定された場合、外部からそれを編集できず閉口することがあります。占有グリフには関連字を設定できないようにしてはどうでしょうか。--y-iijima 2009年7月8日(水) 19:25
    • ご意見ありがとうございます。占有グリフの関連字情報は占有ユーザの画面にのみ表示する、という変更でよいかと思います。占有グリフの見晴らしが悪くなりますが現状では占有グリフがそれほど活用されていないので、また状況が変わったら再検討すればよいと思います。--kamichi 2009年7月12日(日) 11:27
      • 関連字はグリフウィキのグリフ群の同定に重要な要素で、これを見せないという方針変更はやや躊躇します。ユーザーカスタマイズで見える・見えないを切り替えられるようにしたいと思います。--kamichi 2009年9月25日(金) 11:11

    • 関連字・異体字欄には未作成グリフが表示されませんが、異体字データがある場合は未作成でも赤リンクを表示してもらったほうが検索の手がかりになって便利だと思うのですがどうでしょうか。 --y-iijima 2009年7月13日(月) 13:14
      • 当初の記憶がありませんが、なにかの理由があって隠していました。問題点の洗い出しも含め、表示するように変更します。--kamichi 2009年7月15日(水) 12:20

関連字について

過去の議論を踏まえ、次のような変更を行いたいと思います。

  • u####やその派生、異体字の関連字はu####固定とする
  • エイリアスにも任意の関連字を指定できるようにする
  • 過去のエイリアスについては一旦実体グリフの関連字を埋める

cookieのIPアドレス不一致によるセッション無効化の解除について

現在、ログインした時のIPアドレスと別のIPアドレスからグリフウィキにアクセスするとログインが解除されます。私もそうですが複数の場所からアクセスするユーザーにとっては不便です。同一IPアドレスの制限を解除したいと思いますがコメントがありましたらお知らせ願います。--kamichi 2010年6月30日(水) 14:35

  • 特にコメントがありませんので「解除する(別IPアドレスからのアクセスでもログインが維持される)」ということで決定します。--kamichi 2010年8月1日(日) 15:01
  • 解除しました。--kamichi 2010年8月2日(月) 10:47

検索機能で「編集内容の要約」を対象とするか

個人的には検索できるとよいと思います。反対がなければ対象に含めるよう変更したいと思います。ご意見ありましたらお知らせください。--kamichi 2010年4月26日(月) 21:46

  • よいと思います。— sayunu 2010年4月27日(火) 23:46
    • ご意見ありがとうございます。たとえばコメントを「新規作成」で検索したりすると結果の量が膨大になってしまうので適当な件数で切りたいのですが、残りの結果を見られるようにする(ページ切り替え)機能は実装が面倒なので躊躇します。--kamichi 2010年4月28日(水) 10:17
  • 機能追加し、ページ切り替えに対応しました。--kamichi 2010年8月2日(月) 10:47

質問

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

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

ベータ版から正式版へ

  • 現在開発スケジュールを定めずにずるずるとベータ版のまま運用しています。機能拡充はいまだ途中ですが、終わりが見えている状況でもありません。実質的にはベータ版であることに意味が無いと判断しました。そこで近日中に正式版に昇格(厳密には「ベータ版ではなくなる」の意)し、ただし今後も機能拡充を行う方針を考えています。ご意見がありましたらお知らせください。--kamichi 2010年2月11日(木) 22:49

    • 閉じました。--kamichi 2010年8月1日(日) 14:54

Firefox 4

Firefox 4からcmap format 14サブテーブルの情報に基づいたIVSのグリフ置換に対応する予定です。現時点のnightly build では、まだWindowsとSnow Leopardのみサポートで、Snow Leopard上の動作は一部バグっています。Windowsは7だけではなく、XPまでサポートしています。

対応にあたって作成した自動テストのテストケースに、GlyphWikiで生成したフォントを使わせていただいています。OSSに組み込むにもまったく問題のない緩いライセンスであるためたいへん助かっています。ありがとうございます。--emk 2010年6月2日(水) 21:36

  • おお、楽しみです。私もnightly試してみます。ところでIVSについての一般的理解(というよりも周知)はいかがでしょうか。AJ1集合との関係も含め結構ややこしいと思います。そもそもExt.A,B,(C)も怪しいところですが。--kamichi 2010年6月2日(水) 21:45

「sXXX-XXX」について

現在ebagさんが登録しているグリフ「sXXX-XXX」(印学欠字データベース?)の命名方法ってGlyphWiki的にアリなんでしょうか。気になったので。--daekyo 2010年7月6日(火) 02:09

とくに現状では命名ガイドラインに書いていなければ、あるいは命名ガイドラインと混同しなければ、ダメではありません。もっとも、一般的すぎて他者と混交する可能性はあります。あと検索がしにくい問題もあります。--kamichi 2010年7月6日(火) 07:28

ありがとうございます。今のところ特に問題は無く、何か不都合が起きたらその都度対処するということですね。--daekyo 2010年7月6日(火) 17:33

メタ情報の付与

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

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

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

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

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

「-07」の位置づけについて

(「UCS部品の命名方法について」より独立)

もともと「-07」は、UCSグリフ(u####)からデザイン上独立したいときに、特に位置を定めない遊撃的な部品用グリフの位置づけでした。

このため「口」を筆頭に、UCSグリフと縦横比以外は変化しないものについては当初は「-07」で独立することは想定していませんでした。

現状では、「-07」は部品グリフの位置づけで UCSグリフ → -07 → -02等 といった構造的な使われ方が一部なされています。

問題点としては、「-07」を積極的に利用することで構造関係が明確になるという利点と、部品エディタ等で混乱する、グリフ数が増えるというマイナス点もあります。

そこで「-07」の位置づけについて議論ができればと思います。

  • コメント 必要がなければ-07をわざわざ用意する必要は無いと思います。--kamichi 2009年4月14日(火) 10:58

  • 同意します。個人的には、-07自体を廃止していく方向性でもいいような気がします。理由としては、
    • 既存の-07は baseparts 由来のものが多く、u#### の方が字形が整っている場合がよくある
    • -07と u#### の両方の利用を認める場合(現在の状況)、どちらを利用するかでバラけてしまって不便
    • -07の位置づけが曖昧
  • などといったところです。--mashabow 2009年8月5日(水) 00:42

  • 「-07」の設置については、2つ由来があると思います。(1)元にした字形のデザイン特徴に由来して独立字と部品形のデザイン差が大きいbasepartsの代替として(2)個人的ない件ですが、四角形ではない形状の字(ひし形、三角形、逆三角)は独立字に対して部品形が四角形に近づくのではないかと仮定しています。このため「-07」が必要と考えました。
  • ですので「-07」廃止は無理なのではないかと思います。ただしこの考え方は大分昔なので、最近は統一デザインの方で独立時も四角形に近づけると設定すれば不要になるのかもしれないとも思っています。
  • いずれにしてもひきつづきご意見募集中です。--kamichi 2009年8月5日(水) 09:30

  • すでにu5807-07-var-001のような「07のvar」が出現しており、これは今後も出てくることが予想されますから、07全部を廃止するのはおそらく難しく、他に分類しづらい部品の逃げ場として07を残す必要があるのだと思います。ただし、大部分の07は不要だというのは私も同意見です。--y-iijima 2009年8月5日(水) 11:46

  • / sayunu / 大半の -07 は廃止して、基本的に無印グリフを部品として使うことにしていいと思います。全廃はせずとも、特に必要な物に限るのが良いでしょう。別のグリフで引用されれば無印であっても明らかに部品なわけで、部品であることを名前で区別する必要は多分ありません。字表:偏化変形部品一覧で既存の -07 を一通り見ましたが、やはり ほとんど次のような物ばかりです。
    • 単なる無印のエイリアス
    • 無印との字形差に意義を見出せない
    • -02 など別の命名の方がふさわしい
    • 無印の itaiji とするのがふさわしい
  • y-iijima さんが指摘なさっている u5807-07-var-001 も、u5807-itaiji-001 として問題無いのでは。あるいは u5807-02-var-001 とする方が良いでしょうか。これが baseparts-parts-kin2 を置き換える物だとすると、その用例は全て -02 の位置なので。
  • 「-07」が必要な場合として考えられるのは、
    • 部品としては少し筆画が変わる(典型的には右払いが止めになる)
    • 無印では でこぼこした形になる字を矩形に近付けてデザインする
    • 無印をそのまま縮小すると筆画が衝突するのでそれを回避してデザインする
  • といった場合でしょうか。でも そう考えると -06 と条件が相当近いので、-06 の使用範囲を広げて -07 の用途もカバーしてしまうのはどうでしょうか? — sayunu 2009年8月5日(水) 15:02

  • 私の少ない経験上では -07 だけでなく -04, -06~-15は不要と思います。-04, -06はそこに位置するからといって少しつぶれたりするだけで原型を大きく変えるものではありません。 -07を使用しない方向であれば他の接尾コードも積極的に使用する必要はないとした方がよいと思います。(ちなみに私はこれまではなるべく「-01,-02」「-03,-04」といった組み合わせや、部品として使用する際は一旦 -07 としてエイリアス化して使用するようにしていました。そのように使用することが推奨されていると解釈したので。)horaiwataru 2009年8月5日(水) 22:26

  • mashabow です。最初の意見を書いたときには、kamichi さんが挙げた(2)の点を全く考えていませんでした。確かにそういう場合もありますね。また現在の肉付け方法の性質上、普通のグリフを小さく縮小して使った場合は元のグリフほど綺麗にはなりません(4文字からなる kumimoji- などを見ると分かるかと思いますが)。そこで、-07を《このような場合に対応するための部品用グリフ》と位置づけるのはどうでしょう? 元の-07と混乱するので接尾コードを新設しても良いかもしれませんが。この場合、-07のデザインサイズは利用されるサイズ(50%*50%など)にしておけばいいでしょう。……とすると、sayunu さんのご意見の後半部分とだいぶ近くなります。-06と上の-07とは統合できるかもしれません。
  • -04は汎用的なデザインすることが難しい(冠とのバランスに大きく左右されるので)とは感じていますが、私は-04が不要だとは思いません。無印が使えるのであれば新たに-04を作る必要はないと思いますが、脚用に調整された-04は有用だと考えます。--mashabow 2009年8月6日(木) 00:20

  • -04, -10の中には有用なものもありそうですね。基本的に接尾コード付は積極的に使用するのではなく、そちらのほうがバランスを取りやすい際に使用するということでよいのではないでしょうか。-01, -03は積極的に使用した方がよいような気がしますが。horaiwataru 2009年8月6日(木) 22:47

9欄指定について(サンドボックスから移動しました)

unicode規格票GlyphWikiRadical Stroke indexHanzi G sourcesHanzi T sourcesKanji J sourcesHanja K sourcesChuNom V sourcesHanzi H sourceHanja KP sourcesUnicode U sourcesUnicode M source
u3459-pu34599.7 G3-3135(u3459-g) T4-2839(u3459-t) ???(u3459-j) ???(u3459-k) ???(u3459-v) ???(u3459-h) KP1-3582(u3459-kp) ???(u3459-u) ???(u3459-m)

  • unicode規格票(規格ではないのでUnicode標準の方が正式でしょうか)の「-p」というのがありますが「-p」はKPソースを想定しています。ですのでHanja KP sourcesのところが「-kp」ではなくて「-p」になるのだと思います。ともあれ、これいつかsandboxから独立させたいですね。--kamichi 2009年6月13日(土) 10:03

Unicode標準GlyphWikiRadical Stroke indexHanzi G sourcesHanzi T sourcesKanji J sourcesHanja K sourcesChuNom V sourcesHanzi H sourceHanja KP sourcesUnicode U sourcesUnicode M source
u3459-su34599.7 G3-3135(u3459-g) T4-2839(u3459-t) ???(u3459-j) ???(u3459-k) ???(u3459-v) ???(u3459-h) KP1-3582(u3459-p) ???(u3459-u) ???(u3459-m)

  • 接尾コードを変更してみました。現在の命名ガイドラインとは以下の内容が違うと思われますが、案として作成してあります。
    • -s Unicode標準(現在規定なし? -u ?)
    • -u Unicode U sources
    • -j Kanji J sources

対象はhttp://www.itscj.ipsj.or.jp/sc2/open/02n4079/ にある CJKU_SR.txt 内の 74617文字です。全文字文分作成済みで、ファイルサイズは約6.5Mあります。上記は接尾コード確認のため、ソースの無い部分に文字を入れています。 --tsuruki 2009年6月13日(土) 12:14

  • ありがとうございます。実はUnicode標準掲載字形を「-u」としていて、そのうちにISOでのUソースが「-u」に切り替わっていて、ごっちゃになっています。分ける必要はありますでしょうか?また、1字に限定せずに2次にしましょうか?以下を想定しています。--kamichi 2009年6月13日(土) 13:04
    • Unicode標準 -us
    • Uソース -u
    • 今の-p -kp

    • Unicode 標準の接尾コードは迷いますね。シンガポールの漢字が入る可能性も一応あったはずなので(うろ覚え)、-s はシンガポールのために空けておいた方が良いかもしれません。(Ext. A には Singapore Characters なるソースから入った文字がありますが、GS となっているのでこれらはGソース扱いのようです)--mashabow 2009年6月13日(土) 13:15
    • あと Ext. E(元の Ext. D)には ML(マレーシア)もあったかと思います。2字も可にして良いのではないでしょうか。--mashabow 2009年6月13日(土) 13:15
      • プログラムの方で影響があるかどうかのチェックからはじめたいと思います。--kamichi 2009年6月16日(火) 08:14

  • あと、Kanji J sourcesを無印と独立させる意図についてお考えをお知らせください。確かに-jが必要なケースがありますが、すべてのjソースありのコードポイントに必要でしょうか。(まだきちんと考えていませんでした)--kamichi 2009年6月13日(土) 13:04

    • 現在の無印は
      • jソース(X0213>X0212>adobeの順に優先)
      • Unicode標準掲載字形がそのまま許容できる文字
      • Unicode標準掲載字形を手本にjスタイル化した架空(言い過ぎかもしれませんが)の文字
      • の集合であると考えています。そのため、無印の文字だけ並べてもどの文字がjソースなのか分かりません。無印の文字のjソース起因の文字定義はjx1-2004-xxxx⇒uXXXX-j⇒uXXXXの順であるのが理想かなとおもいます。JISとunicodeをつなぐために-jが必要だと思っています。--tsuruki 2009年6月13日(土) 18:13

    • なるほど。突き詰めると「デフォルトはJ」というポリシーそのものへの問題提起になりますね。ところで「-j」はどれを指すのでしょうか。0212と0213を区別する必要もある気がします。そうなるとCHISEの体系に相当近くなってきますね。--kamichi 2009年6月16日(火) 08:14

議論整理

ということで、以下のようになるでしょうか。ちょっと複雑すぎますか?

接尾コード意味
gG欄・ソース
h香港ソース
mマカオソース
ml(my?)マレーシアソース(新設)
sgシンガポールソース(新設)
tT欄・ソース
jJ欄・ソース(新設)
jaJIS X 0213の字形が反映される前のJ欄(Ext.AのJAソース)
jsJIS X 0213の字形が反映される前のJ欄(補助漢字)
kK欄・ソース
kpKP欄・ソース(現在はp)
vV欄・ソース
usThe Unicode Standard の字形(現在はu)
uユニコードソース

  • 補助漢字の u####-js は必要でしょうか? 既に jsp-#### があるので、不要な気がします。Ext.AのJAソースについても、u####-ja ではなく ja-#### にしてはどうでしょう。 --mashabow 2009年7月12日(日) 22:02

  • もともとの「(UCS)-j」グリフの受け皿という意味合いで、過去のUCS規格におけるJ字形という意味では必要かと思いました。結局エイリアスになると思います。数は限定されますよね。--kamichi 2009年7月12日(日) 22:17

異体字とは

命名ガイドラインに沿って uxxxx-itaiji-999 の名前で数十文字作成してみました。 今回作成対象とした文字は、
  • 市販の人名外字フォントの文字(もちろんトレースはしていません)
  • 法務省の誤字俗字・正字一覧

です。

  • 問題1
  • 大半の文字については漢和辞典に載っている「異体字」ではなく、誤用・誤字・俗字・旧字であると思われる

  • 問題2
  • 法務省のほうは「活字」ではなく「手書き文字」のため、解釈の仕方しだいで「嘘字」になってしまうのではないか

  • 問題3
  • 「鉄」の異体字として作成した以下の2文字(u9244-itaiji-001u9244-itaiji-002)はどちらもunicodeに定義されている文字だったためエイリアスとして作成したが、ただ文字のエントリーを増やしているだけではないか

異体字とは「uxxxx」の文字のことをあらわす異なる字体の文字と考えて今回のように作成を継続していってもよいでしょうか?--tsuruki 2009年5月9日(土) 17:37

  • 問題1:「誤用」は解釈が難しいですが、それ以外はグリフウィキの-itaijiの範疇に入ると思います。問題2:嘘字かどうかの判断は主観によります。グリフウィキはいかなる主観も受け入れることを方針としているので、それは構わないと思います。問題3:エイリアスが増えること自体は問題ないと思います。おそらく「関連字」に似た仕組みで異体字を関連付けるメタ情報を設定できるといいのだと思いますが、現状ではないため、命名に異体字情報をつける、という今のやり方で仕方がないと思います。現在は異体字関係をIPSJ TS-0008+αに閉じていますが、これを自由に編集できるといいでしょうか。このあたりも議論ができると良いと思います。--kamichi 2009年5月10日(日) 10:13
  • 一つ疑問に思ったのですが、たとえば「鉄」の関連グリフの異体字欄にu9243が並ぶようになるのであればu9244-itaiji-001のエイリアス設置はいらない、とお考えになるでしょうか?。話は飛びますが異体字欄もどういう関連付けか、という情報がほしいですね… --kamichi 2009年5月10日(日) 10:19
  • コメントありがとうございます。現在エイリアスで文字を作成した場合関連字の設定が行えません。その結果u9435を例にするとu9421のエイリアスで作成したu9435-itaiji-006は異体字欄にあるu9421の右側に「(=u9435-itaiji-006)」として表示されますが、グリフ名にある親字としてあるu9435の関連字の右には並びません。(エイリアスではなく1ドットずらしたu9435-itaiji-006dのようにここにも表示して欲ししい。)
  • 具体的には uxxxx-itaiji-999 として作成した文字のうちエイリアスの場合は
    • 関連字はグリフ名の uxxxx とし、uxxxx の関連字の右側に表示する
    • エイリアス(uyyyy)として使用している文字の右側には現在と同様(=uxxxx-itaiji-999)に表示する

とすることで、関連字欄を見ることでこの文字として作成されている異体字の一覧がもれなく参照できる様になると思います。--tsuruki 2009年5月10日(日) 15:45

  • エイリアスにも関連字を追加可能になりましたので閉じます。現状では-itaijiは頭のUCS符号位置に関連字を縛らないようにしています。--kamichi 2009年9月7日(月) 08:17

グリフウィキで扱うデータの種類とページ接頭辞について

現在グリフウィキは5種類のデータを扱います。

  • 1.グリフ(接頭辞なし)
  • 2.公式ドキュメント(GlyphWiki:)
  • 3.グループ(Group:)
  • 4.利用者(User:)
  • 5.各種ノート(Talk:)

当初、ドキュメントについては操作方法などの公式ドキュメント、各ユーザーページ、およびノートのみを想定していました。現状では一般ドキュメントも投稿されており、これを公式ドキュメントにするかグループにするか迷います。公式ドキュメントはあくまで公式なものを原則としたいので、グループの利用を推奨し、「__no_font__」の記述によりフォント生成の非表示に対応しましたが、矛盾している気もします。以下のような対応が考えられますが、いかがでしょうか。

  • A.任意のドキュメント(Document:)の新設
  • B.グループの名称変更
  • C.現状どおり

ただ、ドキュメントの投稿を許容するとライセンス違反の投稿や悪意のある投稿を受け付けやすくなることも確かです。--kamichi 2009年6月2日(火) 20:01

  • コミュニティドキュメントという位置付けになるのであれば、"Community:"の新設が良いと思います。--匿名利用者 2009年6月2日(火) 21:12
    • (異論が多いと思いますが)個人的にはwiki上にコミュニティを形成すると「他者・新参者排除の流れ」「熟成の後の意見相違による分裂」などの方向に行ってしまうと思っています。その観点からメーリングリストの設置も躊躇しました。あくまで資料的なドキュメントの投稿を主たるターゲットとしたいと思います。反論を含めてご意見お待ちしております。--kamichi 2009年6月22日(月) 09:53

  • 閉じます --kamichi 2009年9月7日(月) 08:07

UCS部品の命名方法について

(讨论:u4e59-01より移動)

UCSの偏化変形部品については、u####-{01~11,15}という記述を行うとしてきましたが、いくつか問題点があります

  • 問題1 05(はめ込み外側)と06(はめ込み内側)を混同しやすいこと
  • 問題2 「たれ」「にょう」「囲い」などを「はめ込み外側(05)」1つで流用しているためu4e59-05u4e59-15のようなケースで困ること(現状は緊急避難的に-15を新設)
  • 問題3 はめ込みで内側の複雑さに応じてバリエーションが必要なこと(現状はu6c14-05u6c14-10のように-10,-11を新設)。さらに異字形のバリエーションも必要か
  • 問題4 どれを使うべきかのドキュメントが足りないこと
  • 問題5 偏化変形部品の保存の仕方が複数考えられること

問題1

  • 提案1 数字ではなく文字で表す方法があります。部品をあらわす1文字[p]+位置を表す1文字[l(eft),r(ight),u(p),b(ottom),o(utside),i(nside)]。例:u####-01 → u####-pl、 u####-05 → u####-po

  • 提案2 IDSの漢字構成記述文字(u2ff#)と関連があればわかりやすいように思います。「u2ff#の下1桁+表記順」というのではどうでしょうか。現在の-01と-02はそのまま-01と-02、-03と-04は-11と-12、-05は-41と-51と-61と-71と-81と-91と-a1、など。
    • なるほど。現在の-06(例:u6728-06)はどうしましょう?右が閉じられたら変化する、というのは-42,-52,-62,-92すべてを定義する必要が出てきます。--kamichi 2009年4月14日(火) 11:05

    • 現在の-06は「はめ込みの内側」だけでなく「高さの低い偏」としても使う(使える)ので難しいですね。内側は外側ほどのバリエーションがないはずなので、とりあえず-06すべてを-42で置き換えておき、-52以降は特別に必要のある時だけ使う、というあたりでしょうか? --y-iijima 2009年4月14日(火) 11:34

    • おっしゃるように、厳密にどのはめ込み向け、というものでは無いのが悩みどころです。「右ハライ」が「右トメ」になる以外の変化が無いのであれば「右トメ変形」という新たな番号にすることも考えられますが。これは、現在の-07のようなどこでもOKの扱いも含めて考える必要があると思います。--kamichi 2009年4月15日(水) 14:57

    • ひとまず現状維持ということで閉じます --kamichi 2009年9月7日(月) 08:07

問題2

  • コメント1 できれば字形機械生成向けに、「たれ」「にょう」「囲い」を判別できるといいと思います

  • 閉じます --kamichi 2009年9月7日(月) 08:07

問題3

  • 提案1 部品の名前を例えば u####-##-variation-## (u####-itaiji-### のように)としてしまうのはどうでしょうか。上記の「囲い」も -variation-## で区別すれば良いかと思います(「たれ」か「にょう」か、というのはグリフの形を見れば分かるでしょう)。“-variation-” では少し長ったらしいので、何か別の文字列にした方が良いかもしれませんが

  • 提案2 u####-##v##、u####-##var##、u####-##-var-##、u####-##-##、なども考えられます

  • 現在のところ、「u####-##-var-###」とすることにします。数字は3桁でお願いします。--kamichi 2009年8月4日(火) 09:27

問題4

  • 閉じます --kamichi 2009年9月7日(月) 08:07

問題5

  • 保存の仕方がいくつか考えられると思います。人偏の例:horaiwataru_rei01horaiwataru_rei02horaiwataru_rei03
  • うまく説明できませんが、例1は偏だから左寄りにする、例2は偏としての形を留めたまま中央に持っていく、例3は偏をあたかもひとつの独立した漢字のように扱い枠内の領域に広げて描く、という感じでしょうか。 個人的には例3のようにするのがグリフ群全体を最終的に体系的なものにするためにはよいと思いますが、編集の容易さを重視すると例1や例2のようにするのもいいのかなと思います。--horaiwataru(用户:horaiwararu)
  • 部品用グリフは以前、例3のように枠いっぱいに作ることになっていました。現在は例1のように、部品が使われる位置に置くという方針に変更されています(参照:用户-对话:kamichi)。例1のメリットとしては、以下のようなものがあると思います。
    • 枠いっぱいに広げなくてもよいため、部品の作成・調整が容易
    • どの位置で使われる(べき)部品なのかが一目で分かる
    • 枠に対して小さいため、利用する際に大きさ(偏旁なら横方向、冠脚なら縦方向)の微調整がしやすい
  • 現状ではまだ例3と例1が入り混じっているためにややこしくなっていますが、方針通り例1のように作っていけばよいのではないでしょうか。また例2のように中央に置かれているグリフ(u5fc4 など)もありますが、これは規格票に倣ったものです。この場合も u5fc4-01 のように、部品用グリフを別に用意しておけば良いかと思います。--mashabow 2009年7月5日(日) 09:01

-参照先にあった下記の目安ですが、パーセンテージを変更されることを希望します。

* 01:基準枠の左半分(50%程度⇒30%程度)とする * 02:基準枠の右半分(50%程度⇒70%程度)とする * 03:基準枠の上半分(50%程度⇒30%程度)とする * 04:基準枠の下半分(50%程度⇒70%程度)とする

-理由は、偏や冠が50%を占めるケースはほとんどなく、同じく参照先の ”「50%程度」とは目安であり、もっとも活用されやすい大きさが望ましい。” と初期値の時点でで既に矛盾しているからです。 horaiwataru 2009年7月5日(日) 14:41

    • 目安の数値についてですが、書き手の意図としては「極端にならないように、かつ、明示しない」という意味で50%程度、と書きました。50という数字を出してしまったのが誤解を生んでいると思います。部品によって全く異なってくるので数値を提示したくないというのが私の意見です。多少譲歩して現状で登録されている2部品比率の平均を出すというのでもいいのですが、なにか良い代替案はないでしょうか。--kamichi 2009年7月8日(水) 17:50
    • パーセンテージはどのように決めても例外が多すぎるので書かないほうがいいと思います。「おおむね基準枠の左半分に収まる程度とする」くらいで良いのではないでしょうか。--y-iijima 2009年7月8日(水) 18:43
    • ご意見ありがとうございます。議論が分散しているのでまとめないといけませんね。取り急ぎ50%→半分の変更を行いました。 --kamichi 2009年7月12日(日) 11:19

    • 閉じます。--kamichi 2009年9月7日(月) 08:07

広範囲への告知手段の確保について

(ソフトウェアへの要望より移動しました)

  • 利用者や興味のある人が増えるので、報告・質問・イベントの知らせ・議論などのため、メーリングリストがあればいいかもしれません。jeroen 20:23, 20 March 2009
    • 先日の食話会を開催するときに、プッシュ型の広報手段があればいいな、と私も思いました。ただ、メーリングリスト上で議論などをすると、今度はWebの閲覧者が情報を得られなくなってしまうので、そうならないようにルールを徹底するか、qwikWebのような融合型にするなどの工夫が必要かと思います。--kamichi 2009年3月20日(金) 20:36
      • ウィキ検索と結合すれば、ウェブ上で読めるリストアーカイブは十分ではありませんか?jeroen 2009年3月20日(金) 21:02
      • これはつまり、新設したMLに投稿されたメールをすべてグリフウィキ(でなくてもいいですが、Web)上で見られるようにすればいい、と言うことでしょうか?--kamichi 2009年3月20日(金) 21:10
  • 直接Googleなどで検索できなくてもいいですが、どこかで検索できると便利だと思います。もちろん、そういう状況を登録する前にMLの利用者に知らせることが必要だと思います。jeroen 2009年4月6日(月) 20:31
    • いくつか手段がありそうなので、まとめた方がいいですね。--kamichi 2009年4月7日(火) 00:43
      • あともう一つ、MLにすると匿名ができなくなってしまうことと(もちろん意見を表明するのに匿名でよいのか、という話もありますが)、他者に自分のメールアドレスがわかってしまうのも躊躇するかもしれません。今のグリフウィキはコアなメンバーが多いのであまり問題にならないとは思いますが、過去の経験として、私は自分の知らない人が含まれている(かもしれない)メーリングリストに投稿するのが非常に苦痛です。ですので、議論ではなく告知の目的にMLを用意するのは賛成です。議論が始まったら積極的にウィキ上に移動していただくようなルールがほしいと思います。--kamichi 2009年3月20日(金) 21:10
  • 確かに、kamichiさんが述べたアプローチは賢明だと思います。しかし、MLは告知だけにすれば、一般の議論とかはどうすればいいでしょうか?余計かもしれませんが、「バグ報告」やこのページなどと同じように、「グリフウィキ議論」というBBS気味のページはいかがでしょうか?(ウィキペディアの「井戸端」のようなページと考えています)
  • jeroen 2009年4月6日(月) 20:31
    • 「井戸端」の存在を忘れていました。それもいい方法ですね。--kamichi 2009年4月7日(火) 00:43
      • あとはウォッチリストのような機能、文章ページへの投稿はその文章を希望者にメールするとか?があればそれでもおおむね解決するでしょうか?--kamichi
      • 私は今RSSソフトの中でフィルターを使っています。簡単なルールでグリフウィキのRSSフィードを「ノート」や「一般ページ」や「字」などというカテゴリーに分別していますが、そういうカテゴリーをそれぞれのRSSフィードにしたほうがより簡単かもしれません。jeroen 2009年4月6日(月) 20:31
  • RSSフィードの工夫も良いと思います。--kamichi 2009年4月7日(火) 00:43
    • RSSフィードを「グリフ」と「ドキュメント」に分けました。表現方法の工夫についてはさらに検討の余地があると思います。--匿名利用者 2009年4月17日(金) 23:08
  • ということでいくつかの改良と議論をまとめる段階になったと思います。どこかに移動しなければ。--kamichi 2009年4月7日(火) 00:43

  • 現状の認識では以下のようにしたいと思います。--kamichi 2009年6月17日(水) 15:43
    • 井戸端を作成し、議論はここで行う(完了)
    • 告知目的のみのMLを作成する
      • このMLの管理についてあまり手間をかけたくないのでどうするか思案中

botの開放について

用户-对话:kamichiより移動)

現状ではbotは許可していなく、運営者kamichiのみが、自動生成の試験やデータの修正にbot(もどき)を利用していますが、特にコアなメンバー向けにbotを開放してもいいのではないかと考えます。

開放の具体的な内容は以下の利用を認めることです。

  • グリフデータを取得できるAPI(もどき)の提供
  • 任意のグリフデータから字形画像を得るAPIの提供
  • データ登録のAPIの提供

問題点としては、現状では運営者がbotを利用するときは、先に別のテストベッド上でチェックを行っていますが、そのテストが行えない分、失敗する可能性が高くなることと、失敗した際の修正(復旧)を現状では運営者が行う必要があることです。

つきましては、(1)botを開放する必要があるかどうか、(2)開放の内容について、(3)想定される他の問題点や、上記問題点に対する方策、についてご意見があれば伺いたいと思います。

コメント

ボットの必要性は高いと思います。 個人的にはボットは事前許可制にすること、ソース公開を前提として問題の指摘やアイデアの提案ができるようにすることが重要だと思います。--匿名利用者 2009年3月13日(金) 10:24

  • ご意見ありがとうございます。これも踏まえ、当面は応相談ですが、少し内容を書き換えました。--kamichi 2009年7月12日(日) 17:30

UCSを埋め尽くした花園フォントの公開について

GlyphWiki:井戸端-保存「公開フォントの次バージョンについて」の仕切りなおし)

想定ではURO(20902)が埋まった記念としての公開を考えています。まだ先になりますが、(1)従来の花園フォントと分けるべきなのか、および(2)名称についてもう一度議論をお願いします。

(1)通常の用途にはすでにIPAフォントがありますので、JIS国内規格収録にこだわらずに、コードポイントを表示するために他にフォントが無いときの最後の切り札的な位置づけで、花園フォントそのものを拡張することを提案します。

(2)仮に分離して公開するとするならば、「64k」や「65530(6)」は一般にはなじみが薄いので、他の名称がいいと思います。やはり「大花園」とかいかがでしょうか。(以上 kamichi 2009年6月22日(月) 10:21)

  • 特にコメントが出ませんでしたので、「月1回程度、その時点での全UCSを収録したフォントを花園フォントとして公開する」としたいと思います。特にJIS規格3種など、これまである程度の規範性を確保してきた集合にノイズが入る可能性が否定できません。最終決定はもう少し先ということで引き続きご意見お待ちしております。--kamichi 2009年7月8日(水) 17:45

GlyphWiki:URO未作成文字を作成しました。

  • ありがとうございます。小分けにするとなんかやる気が出てきますね。--kamichi 2009年7月11日(土) 10:28

  • 閉じます。--kamichi 2009年7月12日(日) 11:22

Wiki記述の拡充について

  • 当初の想定ではグリフウィキ内でのwiki記述によるドキュメント投稿はあまり想定していなく、外部ページから漢字グリフ画像をリンクで呼び出すことを考えていたので、wiki記述の機能は単純なものとなっています(Perl言語ベースなのでYukiwikiのwikiエンジンを利用しています)。このところ良質なドキュメントが蓄積されてきていますので、できればwikiとしての機能も上げるべきなのかと思います。
  • 現状で特にご要望はいただいていないと思いますが、wiki記述についてエンジンを変更する(個人的にはPukiWikiの利用者なので、あれぐらい便利だと望ましいですが…)、このような機能が必要といったご要望があればお知らせください。ただしSPAM防止の観点から外部画像ファイルのインライン展開は考えておりません。--kamichi 2009年6月22日(月) 09:26

  • 特にコメントがありませんので閉じます。--kamichi 2009年7月12日(日) 11:20

公開フォントの次バージョンについて

足踏みしていますが、もうすぐ補助漢字の実装が終わります。ついにIPAフォントの新ライセンスによる公開がありましたので、グリフウィキとしても何か打ち上げられれば良いと目論見ます。

  • 案1 UCSに埋まるものをすべて埋めた4万字フォント
    • サイズが無用に大きくなるのでヒンティング無しを想定しています
    • 花園とは別?それとも花園を「埋まるだけ埋める」路線に?
  • 案2 無理やりゴシックの2本立て
    • 細丸ゴシックが無難かもしれません(要するにスケルトン)

以上いかがでしょうか。--kamichi 2009年4月23日(木) 15:19

  • 案1のUCSすべてを別立てに1票。 --uchi 2009年4月23日(木) 16:22
  • uchiさんに同じく、「A. 従来の花園明朝+補助漢字増加分(+部首?)、B. UCS全部入り」のAB2本立てが利用しやすいかと思います。--mashabow 2009年4月23日(木) 23:36

    • 別立て分の名前は「大花園」「後花園」「超花園」…?--kamichi 2009年4月24日(金) 05:47
    • 命名については、まじめに考えると、「花園83」を公開していますので、それに習って「花園40000」ですかね。40000グリフあったかな…。--kamichi 2009年4月24日(金) 12:47
    • グループ:UCS全漢字のフォントで40236グリフのようです。しかしグリフ数は増えるので「花園40000」はいまいちのような気がします。「花園拡張」とかはどうですか?--uchi 2009年4月24日(金) 13:34
    • グループ:UCS全漢字はPUAが含まれるので、それは入れないとすると4万を切るぐらいと思います。「花園40000」はいまいちですか…。いや量が多いというのがすぐわかっていいかなと…(半分冗談、半分本気)。
    • PUA抜きで20040グリフでした。どうせだったらTrueTypeのmaxを目指し、「花園65530」当たりは如何ですか?--uchi 2009年4月25日(土) 09:11
    • TrueTypeのmaxは賛成です。「Hanazono64k」を提案します。--tsuruki 2009年4月25日(土) 10:33
  • ゴシックも少し気になります。見本はありませんか?--mashabow 2009年4月23日(木) 23:36
    • これからGW(グリフウィキではなくゴールデンウィーク)に作ります…。イメージとしては、現在グリフエディタでゴシックに切り替えたものについて、箱の角の足をきちんと引っ込める、「払い」などの細く終わるストロークを短くする、「ハネ」を直す、太さ調整をしないのであらかじめもう少し細くする、角を丸くしてゴミが出ないようにする、ワ冠を検出したら変更する、「点」の曲線を少し抑える、などのアイデアがあります。グリフウィキ明朝データからゴシック体を上手に生成するエンジンコンテスト、なんてやったら面白いですね。--kamichi 2009年4月24日(金) 05:47
    • GWに少しさわってみました。ソースを読むのに時間がかかってしまい、いろいろな補正を盛り込む時間はありませんでしたが…KAGE/engineを勝手に改造した丸ゴシック試作エンジン --y-iijima 2009年5月6日(水) 12:08
    • ありがとうございます。ソースはあまり可読性はよくありません…。楽しみにしています。--kamichi 2009年5月6日(水) 12:24
    • URO全漢字(現時点で19141グリフ)を収録した丸ゴシックのフォント試作品がようやくできました。JavaScriptではファイルアクセスがなかなかうまくいかず、結局一部はPerlでCGIを書きながらの作業になり、異常終了やエラーとの戦いでしたが、何とかメドが立った感じがします。FontForgeについてはまったくの初心者で何もわかりません。ほとんどデフォルトのままで使っており、お気づきの点がありましたらアドバイスいただければ幸いです。花園丸ゴシック(仮称)フォント試作品 --y-iijima 2009年5月29日(金) 16:50
      • いいですね!というかUROはあと千数百なんですよね。サンプルの文章が似ていることもあり、「漢楽街」を思い出してしまいました。当時とても衝撃を受け、KAGEシステムも影響を受けています。--kamichi 2009年5月29日(金) 23:38
  • ゴシック体は手動での調節が必要なバランスの問題(者や学など)があるので時期尚早な気がします。太明朝や丸明朝などの明朝体派生はどうでしょうか。--匿名利用者 2009年4月24日(金) 06:21
    • どちらにしてもまず作って議論のたたき台が必要と判断しました。ゴシックについては今回の公式な公開案からははずし、別立てでサンプルをアップすることにします。場合によってはグリフウィキにゴシックデータを派生できるようにしたいですが、その前にある程度エンジンが固まらないとデータが無駄になってしまいますよね。--kamichi 2009年4月24日(金) 12:47
    • 明朝の派生書体については、私はポリシーとして実装しないつもりです。現在の明朝体の肉付けエンジンは汚いながらもソースを公開していますし、他の方の実装もありますので、どなたかにお任せしたいと思います。現在のKAGE字形記述にはまだ改良の余地がありますが、将来的には漢字字形骨格記述の標準フォーマットになり、自由に肉付けエンジンを作れるといいと思っています。--kamichi 2009年4月24日(金) 12:47
      • 現在の骨格構文の仕様の公開、もしくは肉付けエンジン(kage/js)のオープンソース化はしないのでしょうか?--匿名利用者 2009年4月24日(金) 14:20
      • エンジンはkage/engineという名称で、すでにソースを公開(http://fonts.jp/engine/ )しています。ドキュメントは…、過去の発表論文等に分散していて、まとまったものが無いので、早く作ります。--kamichi 2009年4月24日(金) 15:27

「花園明朝はバランスがもう少し良くなれば…」というような意見をちらほら目にするので、「デザインの改良は GlyphWiki 上で常に行われており、誰でも参加できる/参加してほしい」「花園明朝にはバージョンアップの際に反映されている」というような記述を readme に加えてはいかがでしょう? --mashabow 2009年4月26日(日) 23:55

  • ご意見ありがとうございます。おっしゃるとおりです。加筆してみました。ちょっと硬いでしょうか?--kamichi 2009年4月29日(水) 08:34
    • いいんじゃないでしょうか? ただひとつ、「また常にグリフウィキ上においてデータの追加やデザインの修正が行われており」「収録グリフのデザイン修正が必要だと思われましたら」「デザインの修正や上記文字集合以外に対する修正も多数行われていますが」の「デザインの修正」ですが、「デザインの調整」もしくは「デザインの改良」にしてはいかがでしょう? その方が、規格票字体/字形に合わせる変更=「修正」と区別ができて良いかと思います。--mashabow 2009年4月29日(水) 12:30
      • さらにコメントありがとうございます。ご提案に沿って修正しました。--kamichi 2009年4月29日(水) 22:09

  • FontForgeのバージョンを上げたところ、ヒンティングのエンジンが変更されたのか、Windowsのラスタライズ時にポリゴンが変に壊れる現象が生じています。FreeTypeやMacOSXでは特におきないようです。解決してからの公開にしたいと思っています。--kamichi 2009年4月29日(水) 22:09
  • 解決を先送りして今回はヒント情報なしで公開します。--kamichi 2009年5月1日(金) 22:07
    • Windows VistaではデフォルトでClearType有効ですしシステムフォントがClearType前提のフォント(メイリオ)なので厳しいですね…。--emk 2009年5月2日(土) 10:16
      • .otf出力だとヒントなしでもClearTypeで問題ないので、なぜPDF出力ができないかがわかるといいのですが、現状では調べが足りていません。--kamichi 2009年5月2日(土) 10:26
      • とりあえず.otfも参考として公開しました。--kamichi 2009年5月2日(土) 10:57

花園フォントの配布ページに「補助漢字(JIS X 0212:1995)の収録漢字に対応しました!」とありますが、1995ではなく1990だと思います。--mashabow 2009年5月1日(金) 21:09

  • ご指摘感謝。修正しました。特に意味は無いんですが良く間違えます。--kamichi 2009年5月1日(金) 22:07

最近のサーバ負荷上昇について

このところ、時々サーバの負荷が高い状態が頻繁に起こっています。この原因はSQLのプロセスが浮いたまま終わらない(クエリの詳細はこれから調べます)ためですが、遠因としてひっきりなしにGoogleBotがアクセスすることが考えられます。robots.txtを解除してデメリットはあったがメリットはあったのか?と疑問に思うことがありますが皆様いかがお考えでしょうか。個人的にはグリフウィキの個々のページが検索で引っかかってもあまり有益ではない気がします。もちろん広報という意味では大いに意味があるのかもしれません。--kamichi 2009年5月18日(月) 22:47

話しがそれますが、今日30名程度にいっせいにグリフウィキにアクセスしてもらったところ、なかなかリクエストが返ってきませんでした。現状はスケーラビリティ云々以前かもしれません。--kamichi 2009年5月18日(月) 22:47

  • Special:Mustrenew (旧部品引用グリフ)のページが重いのと、編集のページが検索に引っかかるのは何とかした方が良いと思います。個々のページに関しては検索で引っかかって欲しいと思います。--匿名利用者 2009年5月19日(火) 00:31

  • DBの構造を変えたのでグリフウィキそのものの負荷は減ったはずです。現在はグリフ再生成中で負荷が上がっています。あと、Googleだけでなく各種クローラが頻繁にやってくるようになりました。改善してなんとか乗り切りたいと思います。

  • だいぶ負荷が落ち着いてきたので、今日20名程度で実習を行いましたが、壊滅的でした。マシンの増強以前にさらに負荷軽減の策を考える必要がありそうです。--kamichi 2009年6月12日(金) 10:16
    • 部品エディタの検索時のSQLが旧構造向けのままであったのが原因でした。修正したのでもう一度機会を設けて複数同時アクセスに耐えられるか試したいと思います。--kamichi 2009年6月13日(土) 10:19
    • とりあえず落ち着いたと判断します。--kamichi 2009年6月22日(月) 09:27

(以下、用户-对话:kamichiからの移動)

高負荷の問題ですが、動的なページをできるだけ静的なページにするのが基本だと思います。Ajaxを使うのも手です。また、Last-Modified/If-Modified-Since/403 Not Modifiedをうまく使うと良いと思います。それと、cgiを使っているのであればmod_*を使うように変えた方が良いです。あと、現在Sitemapsは使っているのでしょうか。使っていないのであれば使った方が良いと思います。また、etchからlennyへ更新するのはどうでしょうか。--匿名利用者 2009年6月5日(金) 01:07

ご提案ありがとうございます。始めて知ることばかりでした。それで、根本的に2つ勘違いをしていたので、まずはそちらから変更しました。(1)GoogleBotにはrobots.txtのDisallowにアスタリスクが使える、(2)データベースに適切なインデックスを設定すると効果がある。この2つで無駄なbotのアクセスを抑えることと、動的ページ生成で最もネックになっていた非存在ページの赤リンク化が大幅に改善されました。あと、現在のサーバで移行するか、新マシンを早く調達するか迷っていますがlennyに移行したいと考えています。またご指導いただければ幸いです--kamichi 2009年6月7日(日) 00:57

エディタ部品について

エディタ部品を偏旁に使われる漢字に入れ換えてはいかがですか。現在登録されている部品は、実際にグリフを作る際にはあまり使われないように思います。--mandel59 2009年5月5日(火) 13:56

  • コメントありがとうございます。誰からも反応がなかったのでそのままになっていました。4つのパネルは字表:エディタ部品1字表:エディタ部品2字表:エディタ部品3字表:エディタ部品4で編集できます。最終的には自分のユーザーページに自分専用の部品群を書いておくとそれがデフォルトで表示されるようにするつもりでしたが、ほとんど誰にも使われていないようで、熱が冷めて手付かずになっています。--kamichi 2009年5月5日(火) 15:04

FontForgeの出力するフォントについて

(1)前からそうだったわけでは無いと思いますが(未確認)、FontForgeの自動Instructionを使って生成したフォントが、ClearTypeで表示時に斜めストロークのポリゴンが一部の拡大率でおかしくなります。場合によってはストロークがよそに飛んでいったり他のストロークと結合してしまうので問題と考えます。

(2)ヒンティングを全くつけずにフォントを生成すると、ClearTypeでの表示時に横ストロークが消えてしまいます。これも問題と考えます。

(3).ttfではなく.otfで出力すると、ヒントあり・なしいずれも表示は全く問題が無いのですが、pdfに出力できなくなります。

(4)LinuxなどのFreeTypeやMacOSXではエンジンが違うため、これらの問題が生じません。

様々なパターンで試した結果、納得のいく答えが出ていません。過程をすべて記録していないのであいまいな情報になってしまいますが、とりあえず現状ではフォント生成に問題が生じているという状況です。5/1公開の花園フォントについては(2)で我慢します。--kamichi 2009年5月1日(金) 18:23

せっかくなので、OpenType形式で出力したフォントファイルも公開しました。PDF出力に関してなにか情報がありましたらお知らせ願います。現状ではAcrobatおよびPrimoPDFでは出力ができません。Office 2007 SP2のPDF出力は可能ですが画像になります。--kamichi 2009年5月2日(土) 10:57

  • fontforge-mingw_2009_03_05で花園明朝2009年5月1日版を読み込んで、全選択→自動ヒント→ヒント命令の自動生成→ttfで出力をやってみましたが、どこが壊れてるのかよくわかりませんでした。壊れているのが確認できる文字とポイント数を教えていただけませんか?
  • PostScriptアウトラインのOpenTypeフォントは、Windows上では何かと制限があるので(IEでレジストリを直接編集しないとフォントに指定できないとか)、できればTrueTypeアウトラインのフォントについても問題解決してほしいです。--emk 2009年5月3日(日) 00:26
    • 現在の字表:花園フォントのフォントが問題のフォントです。私の環境では http://fonts.jp/glyphwiki/error.png のように表示されます。FontForgeのソースは20090408版です。確認したところClearTypeがoffでも同じでした。また20090224版のCygwin版で生成したものはほぼ問題ないこともわかりました。やはり20090408版でAutoInstrにいくつか変更があったのが原因のようです。ただ、曲線を直線ポリゴンで扱っていることがヒンティングに悪影響を及ぼしている可能性が高いので根本的にはKAGE/engineの曲線部分の改良が必要そうです。取り急ぎの対処としてFontForgeのバージョンを戻してみようと思います。--kamichi 2009年5月3日(日) 08:55

  • ということで、FontForgeのバージョンを20090224に戻しました。ヒンティングはFontForgeの自動ヒント、および自動Instr生成によって付与しています。この状態でも一部のグリフについてはInstructionに問題があるのか、「桑」や「修」が少し乱れます。最終的には現在作業中の曲線アウトラインの2次ベジェ対応で解決するものと思われます。--kamichi 2009年5月6日(水) 15:35
    • 以前からそうだったような気もしますが、サンプルPDFを Adobe Reader で見ると(画像 )ちょっと崩れますね。Windows 自体での表示は(桑や修を除いて)良い感じです。--mashabow 2009年5月6日(水) 18:41
    • 画像アップありがとうございます。WindowsのClearTypeだけでなくAdobeの表示、freetypeの表示、MacOSXと、バリエーションが多くて大変です。ヒンティングをつけるとAdobeReaderが崩れるのがいやですね。--kamichi 2009年5月6日(水) 19:38

  • いままで自動ヒンティングをオフにしていなかったのが原因でした。横棒についてだけ手動で(=KAGEデータから計算して)ヒントをつけるようにしました。現状では結果良好です。--kamichi 2009年5月29日(金) 23:38

robots.txtの撤去について

これまでグリフウィキではrobots.txtを設置してGoogle等の検索botを排除してきました。これは特にドキュメントページの内容をキャッシュされたくないこと、および、spambot排除のためです。しかしグリフウィキを広く活用していただくためには、検索エンジンに引っかかることが必須と思われます。そこで、robots.txtを撤去したいと思います。

ドキュメントページの内容をキャッシュされたくない、という意図はあきらめて放棄するとして、spambotの排除はある程度予防する必要があります(Wikipediaと異なり利用者が少ないので除去作業が追いつかないと思われます)。

そこで1つの案として、ドキュメントページはログインユーザーのみ編集可能とする。ただし投稿時に匿名投稿の是非を選択できるように変更する、という方法を提案します。つまり、ログインした上で匿名投稿ができると言うものです。当然のことながらWebサーバのログを調べれば、その匿名投稿は投稿ユーザーと結びつけることが可能です。ですので運用者に対しては厳密には非匿名ですが、運用者はそのような行為を行わないという信頼関係で考えていただきたいと思います。

またグリフページについてはKAGE記述のチェックを厳密に行うことでゴミ投稿を排除することで、ログインしなくとも投稿可能のままとしたいと思います。--kamichi 2009年4月9日(木) 00:19

しかしながら、現状よりも不便になる、本当の匿名ユーザーを部分的に排除する、と言う意味では上記の案は大きな後退です。もっと良い方法があれば提案してください。--kamichi 2009年4月9日(木) 00:25

  • 匿名な投稿をする前に、キャプチャを解かないと投稿できないようにすれば、いかがでしょうか?すると、スパムがほとんど入られないと思います。しかし、それで匿名使用が少し不便になります。jeroen 2009年4月9日(木) 02:46
    • 不便さを少しでも抑えるために、CAPTCHAを出すのはURL入りの匿名投稿をする前とアカウント作成時だけにするのがいいのでは(これはWikipediaと同じです)。--emk 2009年4月9日(木) 07:38

  • 対応している検索エンジン限定ですが、content="noarchive"属性を付けたmeta要素を入れることで内容のキャッシュのみを拒否できます。Googleは対応していますが、Wayback Machineはrobots.txtにしか対応していないそうです。
  • ドキュメントページはWikiによる自動生成ですからすべてのドキュメントページに入れるのも容易なはずです。放棄する前に検討されてはいかがでしょうか。--emk 2009年4月9日(木) 07:23

    • コメントありがとうございました。方向として(1)外部リンクを含むドキュメントの匿名投稿時にキャプチャを要求するようにする(2)robots.txtをはずす、としたいと思います。--kamichi 2009年4月14日(火) 10:36

    • (1)ですが外部リンクを含むドキュメントの匿名投稿はできない、に変更したいと思います。実施したうえで異論が多いようでしたらキャプチャ投稿可で再検討したいと思います。--kamichi 2009年4月15日(水) 14:57

    • 追記ですがcontent="noarchive"属性も入れます。使っている側としては不便ですがトラブルを最小限に抑える可能性を確保するということで。emkさん、ご教示ありがとうございます。--kamichi 2009年4月15日(水) 15:53

    • 変更しました。動作に問題が無いと判断したらrobots.txtをはずします。--kamichi 2009年4月15日(水) 16:05

    • 思ったんですが、投稿されてから1週間経つまではドキュメントにcontent="noarchive"を入れるようにすれば、1週間の間に問題がある場合だけadmin削除すればよい、と考えました。いかがでしょうか。--kamichi 2009年4月15日(水) 18:37

    • robots.txtをはずしたのですが、検索結果が変わらないですね。もしかして、と思いAllowにしたrobots.txtに変えてみました。--kamichi 2009年4月19日(日) 20:51

    • Googleについては/wiki以下についても検索結果に引用されるようになりました。--kamichi 2009年4月29日(水) 22:06