GlyphWiki logo
navigation
help
search

toolbox
languages
articlediscussionedit this pagehistory

GlyphWiki:ソフトウェアへの要望-保存

From GlyphWiki, the free glyph database

過去分の記録ですので編集しないでください。必要な場合は、新たに提議しなおしてください。


(non title)

  • Ext.H対応について、以下の2件を提案します。
  • (1)CJK統合漢字のソース表示について、Unicode15.0へのデータ更新をお願いします。
  • (2)GlyphWiki:関連付けるべき符号位置-ExtHへの対応をお願いします。
    • 以上。--kesuuko 10:12, 25 September 2022
  • 対応しました。(1)については明日早朝より反映されると思います。--kamichi 2022年9月25日(日) 12:25

(non title)

MJ文字図形名(jmj-######)グリフの文字コード関連情報の「文字情報基盤データベース」のリンク先が消えています。新しいデータベースは https://moji.or.jp/mojikibansearch/basic に存在するようです。文字ごとの情報は例えばjmj-006294であれば https://moji.or.jp/mojikibansearch/info?MJ文字図形名=MJ006294 のようになるようです。対応をお願いいたします。--spinda-kkmr 2021年5月21日(金) 18:20

  • 本件、未だに改善されていないようですので早急な対応をお願いします。--kesuuko 02:20, 25 July 2022
    • すみません。今反映させました。ご指摘ありがとうございます。--kamichi 2022年7月27日(水) 09:09

(non title)

現状,登録済みのグリフを編集する場合はFlash版・HTML5版の両方へのボタンが出ますが,新規登録の場合だとHTML5版へのボタンが表示されません。新規登録でもHTML5版を使えるように改善をお願いいたします。--spinda-kkmr 2020年10月31日(土) 16:23

  • 改善されているので,この項目は撤回いたします。--spinda-kkmr 2021年5月21日(金) 18:21

(non title)

ネット上の情報によると、Google Chromeは2020年末にFlashに対するサポートを終了すると判明しました。これに関する対応策があるかどうか教えていただきたいのですが... --simons 2019年10月17日(木) 19:16

  • SWFからHTML5に単純移植の作業中です。本来は今年の夏に終わる予定だったのですが、相変わらず作業が進まず、2020年春に終わらせることが目標です。--kamichi 2019年10月17日(木) 23:27
  • tweさんが作ってくださったkage-editorを取り込みました。--kamichi 2020年10月16日(金) 10:25

(non title)

IDSエディタ もhttpsに対応していただけないでしょうか。iOSではiOS12.2以降ではHTTPのサイト全てに対して「安全ではありません」と表示されるようになりました。HTTPS版IDSエディタのアドレスは「https://fonts.jp/glyphwiki/idsedit/idsedit.html 」が良いと思います。--kesuuko 2019年4月3日(水) 11:48

(non title)

  • ISO/IEC 10646 付属の、 CJKSRC.txt において、各 Uxxxxx に対する各国・各地域のソース情報がある場合、 uXXXXX の他に、 uXXXXX-{c,t,j,v,u,k,kp,h,m} のグリフも例示する機能を、拡張Fまで搭載できませんでしょうか? -- golconda 2018年1月13日(土) 10:50
    • 2017/12/22改定のデータで更新しました。--kamichi 2018年1月13日(土) 12:27

(non title)

  • u2d000u2ebe0にも前の符号位置および次の符号位置を表示してください。--kesuuko 2017年12月26日(火) 17:31
    • すみません、バグでした。修正しました。--kamichi 2018年1月13日(土) 12:01

(non title)

  • GlyphWiki全体、またはグリフ画像のリンクをSSL対応していただくことは可能でしょうか。現在GlyphWiki:グリフを利用するのURLからグリフ画像を利用させていただいているのですが、https付きの他サイトから引用するとそこだけhttpのままになります。現在はブラウザが少し警告を出す程度で機能に問題はないため喫緊の課題ではないですが、iOSが将来SSL必須にするのではないかという話 もあり、できればhttpsプロトコルでも利用できるようにしていただければうれしいです。n747 2017年3月24日(金) 16:55
    • ご提案ありがとうございました。早速ですがGlyphWiki全体(ただしglyphwiki.orgのみで他語種未対応)に対してSSL(TLS)を導入して見ました。不具合ありましたらお知らせ願います。--kamichi 2017年3月25日(土) 15:36
      • さっそくのご対応誠にありがとうございます。遅ればせながらで申し訳ありませんが、httpsで取得できることを確認いたしました。今後ともよろしくお願いいたします。n747 2017年4月10日(月) 14:19

(non title)

  • 旧部品の一括更新時に失敗して赤い×印になってしまう事例がありました(例:waseikanji-no-jiten-2135@2waseikanji-no-jiten-2135@3,現在は復旧済み)。この他にも赤い×印のまま放置されているグリフが存在すると思われます。赤い×印になっているグリフを検出するツール(「最近更新したページ」のような特別ページ)があれば赤い×のまま放置されることを防げると思います。--spinda-kkmr 2017年2月9日(木) 19:29
    • 特殊ページを新規に増やすのが難しいので、このような 検索ができるように細工をしてみました。新しいものから10個の赤バツのグリフが新しい順に表示されます。
    • それで、赤バツのグリフは(1)生成時にプロセスが落ちたもの(2)データが間違っている、の2つありますが、(1)については(手動で)定期的に再生成することにします。(2)いついては(手動で)定期的に削除することにします。--kamichi 2017年2月10日(金) 18:48
      • 掃除が終わったので現在0個です。--kamichi 2017年2月10日(金) 21:07

(non title)

  • 命名ルールに沿わないグリフは登録・編集ともにできなくなっていますが,「編集は可」としていただくと,一般使用者も既存の該当グリフを整理することができます。命名ルールにないbsmg3033a2205@1extf-06486@2と同字形なので整理したいのですが,現状の仕様ではこうした作業をいちいちkamichiさんにお願いしなければならず,管理者の負担が大きいのではないかと思います。 --ziyang 2017年1月29日(日) 10:58
    • 私も上記意見に賛成いたします。登録のみ不可とすれば既存不適格グリフの整理ができるのでよいと思います。「匿名利用者は登録・編集ともに不可,登録利用者は編集のみ可」とすれば荒らしを防止しつつ既存不適格グリフの整理も可能になるのでよいと思います。--spinda-kkmr 2017年1月29日(日) 11:10
    • ご意見ありがとうございます。そのように改善しました。--kamichi 2017年2月10日(金) 16:55

(non title)

  • Add Extension F support? The Extension F chart is already finalized and any modifications (e.g. removal of EXACT duplicate character) I have proposed to have already been rejected by experts from UTC via email correspondence. hkcs 13:04, 31 December 2016

(non title)

  • 「最近更新したページ」にて、「ユーザー占有グリフを表示or隠す」を追加して頂きたいです。最近ユーザー占有グリフ(username_xxxxxx)が劇的に増えています。そのため、他の方が登録編集ミスしたグリフを見落としする可能性がありますので、当フィルタがあると有難いです。--kamiyo 2016年12月30日(金) 13:15
    • 上記,私も賛成です。康熙字典命名移行後あたりに行ってくれればありがたいです。--spinda-kkmr 2016年12月30日(金) 22:05
    • 最近,ユーザー占有グリフが増えており,このままでは荒らしの編集を見落とす可能性があります。なるべく早い実現をお願いいたします。--spinda-kkmr 2017年1月15日(日) 10:48

(non title)

  • 「最近更新したページ」にて,簡体字中国語の利用者が編集した「旧部品の一括更新」に対する「旧部件批量更新」や「エイリアス実体変更による自動更新」に対する「别名实体变更引起的自动更新」の表示を,日本語ユーザー利用時も(自動編集の表示オフ時に)表示を省略するようにしてほしい。--spinda-kkmr 2016年9月17日(土) 10:14
    • 対応しました。翻訳が固まっていないので他言語(おそらくハングルのみ)については都度追加とします。--kamichi 2016年9月17日(土) 11:34
  • バグがあるようです。このページの@470の編集が「最近更新したページ」から見えなくなってしまっています。「文章のみ」の表示にして自動編集の表示を切り替えれば確認できると思います。--spinda-kkmr 2016年9月17日(土) 19:15
    • 失礼しました。自動更新などのキーワードの部分一致で判定するのをやめ、要約メッセージの完全一致で判定するように修正しました。--kamichi 2016年9月17日(土) 20:40

(non title)

(non title)

  • Req 1: Currently there is previous / next codepoint buttons for uxxxx-y and koseki-xxxxxx. Is it possible to specify which sequences to show the prev/next buttons, in a way similar to GlyphWiki:グリフの説明?
    The main use case is the previous mentioned h-propose-uxxxx, it would be much easier to navigate if there were link for the previous and next character.
    For now maybe just assume that all characters are sequential in order.

    • 現在、ページ表示の計算処理に時間がかかっているので、これ以上追加したくないのですが、前向きに検討します。ただし、汎用的な機構を用意するのではなく、あくまでもソースコードに個々のケースの追加となります。--kamichi 2015年5月12日(火) 13:08

  • Req 2: It would be better if the suffix (e.g. hen-ka deformation, locale can be preserved in the links), i.e. in u4e00-t next button will be u4e01-t instead of u4e01.

    • ちょっと要求と違いますが、拡張してみました。--kamichi 2015年5月12日(火) 13:08

  • Req 3: For the glyphs that do not exist in the Unicode Multi-column Chart, e.g. u200b8-t, is it possible to show a warning at the top of the page?

    • これも追加したいと思います。グリフ命名のルール化に伴う機能拡張の一部として考えています。--kamichi 2015年5月12日(火) 13:08

Thank you in advance!! -- chanhenryfaihang 16:50, 8 May 2015

  • ご提案ありがとうございます。仕様をどのようにするか迷っています。
    • まず、エイリアスグリフでも一般グリフと同じように情報を出す方向で考えています。
    • 地域コードつきは地域コードつきの移動ができるようにしたいですが、グリフが無い場合、あるいはそもそも地域コードが無い場合にどうするか
    • そろそろ全地域コードが一覧できたほうが良いか
    • などなど--kamichi 2015年5月9日(土) 18:18

  • UIは試行中ですが、とりあえず拡張しました。見にくいでしょうか… --kamichi 2015年5月12日(火) 13:03

  • Thank you very much!!
  • I think I would be better to place the boxes in a <table> so "previous code point", "browser view" and "next code point" line up. Also, in that case, maybe having them in fixed table cell would be better. An empty cell would be inserted if that country did not have source reference.
  • The order may be better if it follow the Unicode Chart order i.e. GHTJKV. For now, no KP glyph exists in the code chart, so maybe it can be ommitted.
  • For Extension B, there should be an -i glyph. Also for characters with no Japanese source, there should also be a -jv glyph.
  • A design suggestion is available at http://hovertravel.byethost17.com/glyphwiki-suggest-1.png .
  • --chanhenryfaihang 20:54, 15 May 2015

    • l think that jv should be displayed only if a jv glyph aiready exists, so that people are not tempted to create it when jv rules are not applicable. Also, -ja needs to be included (see u34f2-ja)--umbreon126 2015年5月16日(土) 00:26

(non title)

  • 現状では日本語でグリフウィキを利用していると,「最近更新したページ」で自動編集を表示しない設定にしていても,英語での利用者が編集した「旧部品の一括更新」に対する“lump update of old components”や「エイリアス実体変更による自動更新」に対する“Automatic update by changes of substance of aliases”が表示されてしまうので,表示されないようにしてほしい。--spinda-kkmr 2015年4月20日(月) 17:51
    • ご指摘ありがとうございます。ということで現状の英訳について、表示しないようにしました。--kamichi 2015年4月20日(月) 23:37

(non title)

  • KAGEエンジンのパス統合済みのSVGを出力する関数はどれですか?教えてください turgenev 2014年12月5日(金) 00:29
    • 現状では存在しません。外部ツール(Clipper )で結合しています。--kamichi 2014年12月5日(金) 07:54
    • リポジトリ(git.chise.org)のどのファイルを見ればclipperの使われ方が分かりますか?ローカル(WindowsやLinux上)でkage→パス統合SVGに変換したいです。--turgenev 2014年12月5日(金) 18:46
      • User-talk:kamichiのような感じでPerlを介してKAGE出力SVGをパス統合SVGにしています。--2014年12月6日(土) 15:18

(non title)

  • Special:Mustrenewのサイズ(HTMLだけ)は5MB以上です。(ブラウザのコンテキストメニューの「Save Link as」をクリックしたら5MB以上のページが保存されました)これは好ましくないと思います--umbreon126 2014年11月20日(木) 11:32
    • ご指摘ありがとうございます。コストをかけずに対処するにはどうすればいいでしょうかね。先頭の一部しか出さない、とするのは望ましくないでしょうし。--kamichi 2014年11月22日(土) 09:13
    • 考え方を変えて、ランダムに500個表示する方式に変更してみました。網羅性は落ちますが、表示するごとに集合が変わります。(現在日本語ページでのみ動いています)--kamichi 2014年12月4日(木) 11:59

(non title)

  • u0022u1f0a3のような非漢字のUnicodeページでも前の符号位置,次の符号位置が表示されるようにしてほしいです。--spinda-kkmr 2014年10月5日(日) 13:22
    • ブロックの空き符号位置を考慮せずに単にプラスマイナス1、でしたら可能と思います。--kamichi 2014年10月5日(日) 14:45
      • ご検討ありがとうございます。非漢字は空き符号位置が多いので考慮するのは事実上不可能だと思うので,それで十分だと思います。--spinda-kkmr 2014年10月5日(日) 15:00
      • やってみました。なお、手抜きによりU+3###の符号位置は漢字として扱われ、それ以外の非漢字は非漢字として処理します(他サイトへのリンクが表示されません)。--kamichi 2014年10月5日(日) 16:15

(non title)

  • 「部品の一括更新」からユーザー占有グリフを除きますのは便利ですと思います。他のユーザーの編集はできませんので、表示しますのは意味がありませんか。--umbreon126 2014年9月21日(日) 04:59
    • おっしゃる通りと思います。対応いたします。--kamichi 2014年10月5日(日) 14:46
    • 対応してみました。--kamichi 2014年10月5日(日) 16:15

(non title)

  • U+9FCDからU+9FE9まで、UNCが追加される予定です。関連字の範囲を変更してください。(UNCの臨時命名は困難なので、直接登録するしかないと思います。)
  • http://std.dkuug.dk/JTC1/SC2/WG2/docs/n4585.pdf --johotogoshinentai 2014年6月6日(金) 19:31
    • http://blogs.adobe.com/CCJKType/2014/06/9fcd-thru-9fe9.html 通用规范汉字表のマッピングも更新され、変更もない可能性が高いようです。 --johotogoshinentai 2014年6月7日(土) 10:49
    • 早いかなとも思ったのですが、グリフウィキの近年の目的として、制定中事項の対応も必要性が高いので、変更しました。ご提案ありがとうございます。--kamichi 2014年6月7日(土) 14:59

(non title)

(non title)

  • u91d2-01の「旧部品の一括更新」http://glyphwiki.org/wiki/Special:Mustrenew?view=listup&target=u91d2-01 が,ユーザー占有グリフで埋まってしまい進まなくなりました。「ユーザー占有グリフの表示の有無を選べるようにする」か「ユーザー占有グリフは本人分のみ表示する」かのいずれかの対応をするほうがよいと思います。--spinda-kkmr 2014年5月10日(土) 11:48
    • ユーザー占有グリフは自分の分のみ候補として出す事に変更しました。ご指摘ありがとうございます。--kamichi 2014年6月7日(土) 17:42

(non title)

  • 現在、koseki-######とdkw-#####は、「前/次の符号位置/番号」が表示されますが、このようなものをjuki-####とtoki-########にも適用するのはどうでしょうか。 --johotogoshinentai 2012年11月4日(日) 13:41
    • 「juki-」は連番になっていないですよね、テーブルを持たないと対応できないとなると若干面倒です。「toki-」はどうなんでしょうか。--kamichi 2012年11月4日(日) 17:55
    • いったん凍結として閉じます。--kamichi 2013年2月10日(日) 21:44

(non title)

  • 特殊グリフには説明文を付けたい --kamichi 2012年6月9日(土) 11:49
    • メタ情報に相当するので実装済みとして閉じます。--2013年2月10日(日) 21:43

以下見出しなし(上記と時期のクロスありに注意)

  • “u(2)####-us”を作成するときに,自動的に関連字が設定されるようにしてほしいです。現状では〓が入力されるので,手動で入力しなければなりません。--spinda-kkmr 2012年12月30日(日) 15:05
    • 失礼しました。対応しました。--kamichi 2012年12月30日(日) 15:24

  • www.glyphwiki.orgのglyphwiki.orgへのリダイレクト --kamichi 2012年11月4日(日) 21:47
    • 対応 --kamichi 2012年12月29日(土) 23:15

  • u4db5の「次の符号位置」をu4e00に、u2b81dの「次の符号位置」をu2b820にするように改良する必要があると思います。 --johotogoshinentai 2012年11月4日(日) 13:41
    • 対応しました。そもそも少し間違って作っていたので修正しました。

  • u(#)####-##-var-###(例:u7fbd-03-var-001)のように,「偏化変形のバリエーション」のグリフを作成しようとするときにも,自動で関連字が入力されるようにしてほしいです。現状では〓が入力されます。--spinda-kkmr 2012年10月28日(日) 15:58
    • ご指摘ありがとうございます。実装ミスと判断し修正しました。--kamichi 2012年10月28日(日) 18:18

  • 異体字のデフォルト表示をonに戻すのを提案します。現状では以前の私の提案によって、デフォルトoffになっていますが、グリフページのローディングが遅いのは異体字の表示が原因ではなかったようです。現状でもu9089u9f9cのローディングは遅いですが、これは同じ関連字を共有するグリフの数が多いのが原因です。
  • むしろデフォルトoffにすると、初心者が異体字を探すのに不便を与えているようです。u974f@12のような編集は、靏(U+974F)の異体字である靍(U+974D)を探し出し方がわからなかったから、でしょう。以前もそのようにUCSグリフをUCSにある異体字の字形に変更してしまう匿名利用者がいました。--johotogoshinentai 2012年5月21日(月) 10:03
  • そうですね、戻したいと思います。--kamichi 2012年5月25日(金) 08:47
  • 私のプログラムの問題と思うのですが、関連字のチェックでたくさんのSQLを実行することになり、そうするととても時間がかかります。もしかすると私の書き方が良くないのかもしれませんが…。一つグリフウィキの設定に失敗したと思っているのは、DB内ではグリフページもドキュメントページも同じテーブルにしてしまったので、処理効率が悪いのではないかと思われます。よくよく考えると、切り分けることはそれほど大変ではないので分割したいですね… --kamichi 2012年5月25日(金) 08:51
  • 戻しました。併せて、部分indexの作成と、shared_bufferの修正をしました。どうやら劇的に早くなった気がします。もっと早く対処すればよかったです。--kamichi 2012年5月30日(水) 23:35

  • 「GlyphWiki:」や「グループ:」で始まる記事名に使用可能文字の範囲を広めてほしいです。今は漢字、かな、数字、ASCIIアルファベットで限っていますが、[、]、#、スペース、サロゲートペア、BMPのnon-character部分などを除外したほかの文字も含められるようにしていただけませんか。 --johotogoshinentai 2012年4月2日(月) 04:51
    • お気持ちは理解できるのですが、私(管理者)が読めないとちょっと怖いな、という思いはあります。いずれにしても、「●●以外はOK」ではなく「■■は可」という方向で「■■」の対象を増やす形で対応したいと思います。ほかの方でコメントありますでしょうか。--kamichi 2012年4月7日(土) 20:56
      • GlyphWiki-talk:Botのページ名衝突を見て、以下の文字を記事名の使用可能文字に追加するのを提案します。
      • U+AC00~U+D7A3 (가~힣)
      • U+3131~U+3163 (ㄱ~ㅣ)
      • U+00B7 (·)
      • --johotogoshinentai 2012年4月30日(月) 15:25
      • 最近、大変忙しいのようですが、これを処理していただけませんか。 --johotogoshinentai 2012年5月21日(月) 10:03
  • すみません、やっと対応できました。--kamichi 2012年5月25日(金) 08:47
    • 対応してくださってありがとうございます。 --johotogoshinentai 2012年5月25日(金) 11:35

  • フォントの生成時、[[(文字) (グリフ名)]]の(文字)の部分を非漢字にも対応するのがもっと便利だと思います。(例: u3042(u3042) だけではなく、 あ(u3042) にしても「あ」の符号位置(U+3042)にu3042のグリフが割り当てます) --johotogoshinentai 2012年3月25日(日) 09:40
    • もともとは漢字のためのグリフウィキでしたので、単純に抽出の範囲が漢字に限られているということで、非漢字に開放してもいいと思います。--kamichi 2012年3月25日(日) 13:38
      • より詳しく例を引きます。誰かは「あ」の符号位置にu4e00を割り当てたいです。ですが、その人は「あ」のUnicodeの符号位置を知っていません。この時、 あ(u4e00) と入力してフォントの生成ができれば、確かにその人には助かるでしょう。グリフウィキは漢字のグリフを扱うウィキですが、グリフを割り当てる符号位置は漢字である必要はないでしょう。文字を非漢字にも対応するように広めるのは、こんな長所があります。 --johotogoshinentai 2012年3月25日(日) 13:51
    • ありがとうございます。導入に躊躇している点は1つで、その文字を抽出するのは正規表現で書くのですが、なにを充てるか、という問題です。「\S」だと拾いすぎてしまいます。「[^\x{0000}-\x{0020}\x{007f}]」ですかね… --kamichi 2012年3月25日(日) 14:10
    • ということで、対応しました。U+0000~U+0020, U+007F, U+FFFE, U+FFFF以外を拾うはずです。--kamichi 2012年3月25日(日) 14:49
      • 返事が遅くなりました。[\x{D800}-\x{DFFF}]も外してください。 --johotogoshinentai 2012年3月25日(日) 15:01
      • あとnoncharacterの66符号位置もですかね。次対応します。--kamichi 2012年3月25日(日) 15:41
      • サロゲートペア部分およびBMPのnon-character部分を除外しました。--kamichi 2012年3月25日(日) 17:42

  • u(#)####-jv、u(#)####-ue01##を作成する際に,関連字に該当する文字(u(#)####)が自動的に入力されるようにしてほしいです。現在は〓が入力されるので,間違ってそのまま登録してしまうと探すのが困難になってしまいます。--johotogoshinentai 2012年1月7日(土) 13:32
    • あと、u(#)####-jv、u(#)####-ue01##の中に、関連字が正しく設定されていないものがあるらしいです。これもボットで直すのが必要だと思います。 --johotogoshinentai 2012年1月7日(土) 15:28
    • 私も気になっていました。改善を予定しています。--kamichi 2012年1月7日(土) 15:51
    • 新規ページ時の関連時自動設定に対応しました。大変遅くなりました。--kamichi 2012年10月28日(日) 18:21

  • 関連字と異体字をロードしない機能があってほしいです。u9089u9f9cのように、関連字と異体字のグリフが多いと、グリフページのロードが遅すぎ、サーバに過負荷を与えます。たとえば、「関連字と異体字のグリフがが多いのでグリフページのローディングが遅くなっています。関連字と異体字のローディングを中止しますか? (はい/いいえ)」のようなメッセージを出力されるのです。--johotogoshinentai 2012年1月7日(土) 13:26
    • そうですね。以前、異体字を2ホップ以上表示する機能の負荷が高かったので削除しましたが、もう1歩必要でしょうか。オプションで表示の有無を選択できるようにしたいと思います。また、実は今年度の研究助成金で高性能のサーバを購入しまして、いま設置待ち状態です。これが入れば改善するかもしれません。--kamichi 2012年1月7日(土) 15:50
    • 異体字の表示をデフォルトでオフにしました。さすがに関連字は出した方がいいと思うので、そのままとしています。--kamichi 2012年1月24日(火) 09:40
      • でも、これはu9089u9f9cのような、1つの関連字に多数のグリフが割り当てられていると役に立たないようですね。 --johotogoshinentai 2012年1月24日(火) 09:57

  • 自分を自分のエイリアスにするのを禁止したほうがいいと思います。自分を自分のエイリアスにすると、編集履歴もエイリアスの関係も複雑になってしまいます。 --johotogoshinentai 2011年10月8日(土) 18:35
    • juki-4f6dの編集の時に誤って自分自身をエイリアスにしてしまったので,juki-4f6d@2およびjuki-4f6d@3がそれぞれ1つ前のバージョンのエイリアスとなってしまったようです。juki-4f6d@4でエイリアス先を正しく指定したので解消されましたが,自分自身をエイリアス化するのはシステム側で禁止したほうが望ましいと思います。--spinda-kkmr 2012年1月29日(日) 20:37
    • ちょっとお尋ねします。自己エイリアスというのは、たとえばu4e00のグリフデータに「99:0:0:0:0:200:200:u4e00」を指定するということでしょうか?--kamichi 2012年1月29日(日) 20:57
      • 以下の2つのタイプがあります。
      • glyphAをglyphAのエイリアスにするもの (= kamichiさん、spinda-kkmrさんの例)
      • glyphBがglyphAのエイリアスになっている場合、glyphAをglyphBのエイリアスにするもの
      • ちなみに、私が最初言おうとしたのは後者です。 --johotogoshinentai 2012年1月30日(月) 03:17
    • johotogoshinentaiさんの言葉を借りるなら,「glyphAをglyphAのエイリアスにするもの」です。グリフウィキでは編集窓に【【グリフ名】】(【】は本当は角括弧,以降同じ)と入力すると,エイリアスグリフとすることができるのですが,この時編集対象のグリフと同じグリフ名を入れても受けつけられてしまうのです。
    • 具体的にはjuki-4f6d@1(この時点では実体)を編集した時に,誤って【【juki-4f6d】】と入力してしまったため,juki-4f6d@2juki-4f6d@1のエイリアスとなってしまいました。それと同時に「エイリアス実体変更による自動更新」が行われ,juki-4f6d@3が作成され,juki-4f6d@2のエイリアスとなりました。その後【【u4fd6-var-001】】と入力し直して,juki-4f6d@4で正常化されました。
    • このように,自分自身をエイリアスにしてしまうと,自分自身の過去のバージョンのエイリアスとなってしまいます。これではバージョン関係やエイリアス関係が厄介になるので,自分自身をエイリアスにしようとした時にグリフウィキのシステム側で受け付けないようにしていただけると良い,ということです。
    • 以上,--spinda-kkmr 2012年1月30日(月) 12:46
    • u45d9@3のとき、間違って【【u45d9】】を入力してしまって、その時までu45d9エイリアスだったkoseki-379870koseki-379870@3で白紙化されてしまいました。u45d9@5で【【u45d9-ja】】を入力してu45d9は正常化されましたが、koseki-379870は白紙化のままだったので、直接u45d9-jaのエイリアスにしなければならなかったです。この事例を見ると、自己エイリアスはほかのエイリアスもややこしくなるようです。 --johotogoshinentai 2012年2月4日(土) 20:23
  • 自己エイリアス([[自分]]で登録、およびBが[[A]]のときAを[[B]]で登録)を受け付けないようにしました。大変お待たせしました。--kamichi 2012年3月21日(水) 12:00

  • CJK Compatibility Ideographs Supplement (U+2F800 – U+2FA1F)の中、関連字が正しく設定されていないグリフが多数あります。autoglyph-botで関連字を正しく設定するのが必要だと思います。 --johotogoshinentai 2011年7月14日(木) 09:47
    • チェックします。以下、すっかり手付かずですが、やります。--kamichi 2011年7月14日(木) 10:13
    • なかなか不可解でしたが、チェックしました。互換漢字の関係が異体字に出てきていないですね。--kamichi 2011年7月14日(木) 15:57

  • グリフページの title に「関連字」を入れられないでしょうか。
    • aj1-14037(望)- GlyphWiki
    • aj1-14037 望 - GlyphWiki
    • 望 / aj1-14037 - GlyphWiki
  • みたいに。— sayunu 2011年5月14日(土) 14:09
    • ご意見ありがとうございます。関連字なのであまり目立つのも、と思います。1番目が妥当ですかね。--kamichi 2011年5月14日(土) 14:28
    • 対応しました。--kamichi 2012年1月2日(月) 13:45

  • “u####-var-###”や“u####-itaiji-###”を作成する際に,関連字に該当する文字(u####)が自動的に入力されるようにしてほしいです。現在は〓が入力されるので,間違ってそのまま登録してしまうと探すのが困難になってしまいます。--spinda-kkmr 2011年4月6日(水) 20:48
    • ご指摘ありがとうございます。直します。--kamichi 2011年4月7日(木) 11:01
    • 直しました。--kamichi 2011年4月8日(金) 21:45

  • KAGEエンジンの buhin.js は配列にデータを格納していますが、配列だと頭からひとつづつ探さなければならないのに対し、ハッシュを使ったほうが単純で高速にアクセスできるので、修正した物をつくりました。(pushとsetは同じ機能になりました。) http://dl.dropbox.com/u/1224536/tmp/buhin.js
    • ありがとうございます。触発(?)されて、いまいろいろ手を付けようとしています。--kamichi 2011年2月22日(火) 09:51
    • ということで閉じます。--kamichi 2013年2月1日(金) 11:32

  • 目次の隠し方について質問
    • グループページで、目次が隠せる方法がありますか。Group:KSX1001
    • Group:KSX1002は目次が長すぎるので、なんか閲覧が面倒になっています。(ちなみに、その2つのKS標準では漢字の韓国語読みも表しています。) --johotogoshinentai 2011年2月18日(金) 20:14
    • 現状では用意されていないので、要望として承ります。近いうちに用意できると思いますが…--kamichi 2011年2月18日(金) 21:13
    • ページが長くなると、閲覧が大変で参照しづらいです。例えば面区点の区ごとに1ページ100文字ぐらいにして、複数のページに分割した方が使い易いと思います。--mandel59 2011年2月18日(金) 23:38
    • とはいえ、実装しました。--kamichi 2013年1月22日(火) 16:27

  • 12:12:188:188の範囲から抜けているグリフを確かめられるツールがありますか。私が最初に作ったグリフたち中の一部は範囲から抜けているので、それを確かめて直したいです。--johotogoshinentai 2011年1月3日(月) 14:11
    • 作ります。ちょっとお待ちください。--kamichi 2011年1月4日(火) 03:36
    • すみません、ちょっと手こずってしまい、作業が止まってしまいました。もう少しかかります。--kamichi 2011年2月10日(木) 13:47
    • 不可能そうですので、取り消します。--johotogoshinentai 2012年1月2日(月) 14:16

  • 検索ボックスにIVSが入力された場合も表示できるようにして欲しいです。--mandel59 2010年12月19日(日) 21:02
    • ご指摘ありがとうございます。対応しました。--kamichi 2010年12月20日(月) 17:37

  • 以前から不便だと思つて居たんですが、「最近更新したページ」で利用者指定と自動編集を隠すの両方を指定して更新分を表示出来ないのを、出来る様にして欲しい。―lizard 2010年9月2日(木) 03:26
    • ご意見ありがございます。改良しました。--kamichi 2010年9月2日(木) 12:48
      • 早速の変更ありがたうございました。―lizard 2010年9月3日(金) 11:44

  • 更新内容の要約などを書いている時、うっかり return(enter)を押し過ぎて、途中で投稿してしまったりしますよね。return で押されるのを投稿ボタンではなくプレビューボタンにしてはどうでしょうか。— sayunu 2010年4月25日(日) 17:35
    • ご指摘ありがとうございます。たしかに間抜けな要約をよくやってしまうのは私なんですが、Enterで直投稿できるのも便利かとは思っていました。冷静に考えるとやはりEnterでプレビューのほうが適切なので、変更します。--kamichi 2010年4月25日(日) 19:02
    • Enterを押したときの挙動はどうやら出現順のようで、任意のボタンにEnterの動作を割り当てられなかったのでボタンの配置を入れ替えてみました。昔ときどき「投稿したつもりがまだプレビューでウィンドウを閉じてしまう」ということがあったので、「プレビューであることの表示」を太字にしました。--kamichi 2010年4月25日(日) 19:18

  • 他のドメインにあるJavaScriptからでもGlyphWikiのデータを取得できるようにJSON、JSONPに対応して欲しい。--mandel59 2010年4月6日(火) 01:57
    • ご意見ありがとうございます。まずはグリフ情報だけを想定していいでしょうか。以下のような感じでしょうか。もっと情報が必要ですか?--kamichi 2010年4月6日(火) 07:25
 {
   "name": "u4e00",
   "version": "2",
   "data": "1:0:0:14:96:186:96"
 }
    • とりあえずそんな感じで結構です。--mandel59 2010年4月6日(火) 17:25
    • まずはJSON出力に対応しました。--kamichi 2010年4月7日(水) 08:58
    • JSONPにも対応しました。なるほどこれは面白いですね。--kamichi 2010年4月7日(水) 09:28

  • Windows 7でIVSが認識されない件について調べました。詳しくは私の利用者ページに書きましたが、結論だけ要約すると
    • ダミーのGSUBテーブルを入れる。
    • U+0020にグリフを定義する。
  • の2点を実行していただけないでしょうか。--emk 2010年3月12日(金) 02:23
    • あと、OS/2テーブルのulUnicodeRangeのbit57もセットする必要がありました。ここがセットされていないと、UCS4のcmapがあっても「BMP外に文字がある」とみなしてくれないようです。--emk 2010年3月12日(金) 02:34
    • 貴重な情報、ありがとうございました(結局Win7はOSレベルでIVS対応していたんですね…)。対応します。実はまだWin7環境がないので、インストールからはじめます。--kamichi 2010年3月12日(金) 08:00
    • 手元では豆腐のままですね。花園フォント最新版に、U+0020を定義、VLゴシックのGSUBをコピー、OS/2のUniRangeの57をオン、でだめでした。もしよろしければグリフウィキベースでIVSが表示できるフォントを提供していただけないでしょうか(KozProNではIVSが表示できることを確認しています)。--kamichi 2010年3月12日(金) 15:08
    • 出ました!単純にフォントキャッシュの問題でした。--kamichi 2010年3月12日(金) 15:49
    • IVSonWin7対応度雑感:メモ帳OK(1文字として処理される)、ワードパッドmmm(表示できるが無駄な空白がでる(Alt+xが使えるので入力に最適)、IE8NG、Office2010BetaNG、SafariNG、GoogleChromeNG、OperaOK、ということでWin7+OperaがWindowsでのIVS使用環境として最適と思います。多分。
    • Win7+OperaでIVSを表示し、XPS出力OK。PrimoPDFによるPDF出力NG
    • 以上 kamichi 2010年3月12日(金) 16:49
    • AcrobatならIVSをPDFに出力可。ただし一部の文字がU+10xxxxにマッピングされる --kamichi 2010年3月12日(金) 17:47
    • IE9PrevieNG残念--kamichi 2010年3月21日(日) 22:43
    • 大変間が空きましたが、やっとemkさんよりご指摘いただいた全条件を満たすように修正しました。IVSがある場合のフォント生成において「U+0020」グリフの追加、「U+20000」グリフの追加、ダミーGSUBテーブルの追加、UnicodeRange57bitをon、cmapの追加およびxAvgCharWidthの修正を行います。--kamichi 2010年5月23日(日) 20:32」

  • グリフ生成時に斜め直線の直線への接続で反対側にはみ出さないようにしてほしいu4e94 --uchi 2010年3月1日(月) 00:47
    • 後者につきエンジンの方対応しました。部品エディタはFlashオーサリングツールが手元にないので明日以降対応します -kamichi 2010年8月9日(月) 18:38
    • 修正完了しました。--kamichi 2010年8月10日(火) 13:41

  • グリフ名にu####を含む場合、それをエディタの部品リストに表示させたほうがいいと思います
  • たとえば、 ⿰魚針(u2ff0-u9b5a-u91dd) なら、魚と針などをエディタの部品リストに表示させるということです。(-usを作る際にも使います。)--tomomo 2010年1月31日(日) 20:55
    • グリフエディタの部品検索については根本的に再検討が必要と思いますが、とりあえずIDSグリフ(kumimoji-,sokei-含む)については含まれるUCS符号位置と部分一致するグリフを検索するようにしました。--kamichi 2010年2月11日(木) 22:29

  • 私の環境(Mac OS X 10.4.11、Safari 4.0.4、Flash Player 10.0.32.18)に特有の現象なのか知りませんが、特定の部品を含むグリフを Flash のエディターで開くと、最初の読み込みが完了して操作できる様になるまでに相当長い時間待たされる事が有ります。その間 CPU を 100% 占有し続け、Safari 全体が道連れで操作できなくなります。見た感じ、一部の部品が読み込まれる時に止まる様なんですが。例えば u4d0c@7 を開くと、ワ冠が表示される前に数十秒か数分止まり、〈豕〉で更に数分止まり、全て表示された後も操作を受け付ける様にならず、結局 Safari を強制終了して抜けました。(グリフの更新は KAGE データを直接記述して行いました。)出来れば操作不能にならない様に改善して頂けたらいいんですけれど。これが当方だけの現象なら、別のブラウザーを試してみたりしますが。— sayunu 2010年1月30日(土) 02:28
    • ご指摘ありがとうございます。手元で確認したところでは、「それほど」重くなりませんでした。u4d0c@7は部品数が多いことを考えると、部品の呼び出し待ちに(本来は別プロセスなのですが)処理が引っ張られているのかと思います。もしかすると(グリフウィキ側の)ネットワークが混んでいる際に部品を読み込もうとするときに生じる状況かもしれません。Macも手元にあるので確認してみます。--kamichi 2010年1月30日(土) 09:04
    • 私の環境(WinXpSp3、Opera 10.10、Shockwave Flash 10.0.42.34、メモリ640MB)でも同様の現象が発生します。現象が発生するわけは、メモリの使用量が多い(640MBで1GBを超えるメモリを消費)為のようです。同じマシンで Firefox 3.6(Shockwave Flash 10.0.42.34)では、メモリ消費50MB未満で普通に操作できました。Opera ではこの字 u4d0c@7 以外でも遅かったので、作業をFirefoxで行うようにしています。以上報告させていただきます。--uchi 2010年2月1日(月) 19:23
    • 大学の Windows 機でちょっと試して来たんですが、やっぱり同じ様な状態になりました。Windows XP 5.1.2600 SP 3、Internet Explorer 8.0.6001.18702、Flash Player 10.0.22.87 の様です。比較的 非力なマシンだと思いますが、冷却ファンをブンブン回したまま「応答なし」になってしまいました。— sayunu 2010年2月1日(月) 21:01
    • Mac・Safari での話ですが、どうも引用に引用を重ねたグリフは重くなり易い気がします。u27c28-04@3u8c55@5 は瞬時に操作できる様になり、u51a1@6 も一・二秒ほどで操作できる様になり、u8499@11 は八秒ほど掛かり、u8499-02@3 は 20 秒ぐらいで、u4d0c@7 は極端に重いです。ただ、そうでもないグリフでも重い場合が有る気がするので、それだけではないかも知れませんけど。— sayunu 2010年2月1日(月) 21:01
    • Safariのステータスバーを表示させて当該グリフの編集をしてみると、構成するファイルがどんどん増えていって4000台になりました(つまりページロードが終わらずに待たされていた)。内訳を見ると同じ内容が重複して呼び出されていました。原因をこれから調べます。--kamichi 2010年2月3日(水) 08:23
    • レイジーローディングで呼び出し中の部品を新たに呼び出さないように変更したところ、無駄な読み込みがなくなって問題が解決した模様です。--kamichi 2010年2月3日(水) 10:00
    • 劇的に軽くなりました。ありがとうございます。— sayunu 2010年2月3日(水) 15:18

  • 正しくないグリフ名を使ったときに、警告を出す、投稿を受け付けないなどの対策を取ったほうが混乱が無いと思います。例えばdkw-5290というグリフ名を使おうとした時は、正しいdkw-05290にリダイレクトするなど。--mandel59 2010年1月23日(土) 23:09
    • ご指摘ありがとうございます。検討します。--kamichi 2010年1月24日(日) 10:39
    • 機能を追加しました。とりあえず大漢和番号、戸籍統一文字の桁数と、baseparts-の排除の3つをチェックします。--kamichi 2010年2月11日(木) 23:17

  • エディタで、シフトキーを押しながら部品をクリックすると、複数選択になりますが、選択済みの部品を再びシフトキーを押しながらクリックしたときに、選択が解除されないので、解除できるようにして欲しいです。--tomomo 2010年1月1日(金) 14:07
    • ご指摘ありがとうございます。昔自分でもおかしいなと思ったのですが、直していないというのは理由があったかも?いずれにしても検討します。--kamichi 2010年1月24日(日) 10:39
    • 修正しました --kamichi 2010年8月10日(火) 13:54

  • エディタで「折れ」線で両端の「開放」の指定をOKにしてほしい。u61f8-ue0101で使用しています。--uchi 2009年12月31日(木) 18:12
    • ご指摘ありがとうございます。修正します。--kamichi 2010年1月24日(日) 10:39
    • 追加しました。--kamichi 2010年2月3日(水) 10:00

  • autoglyph-botによって生成されたグリフは、旧部品の更新を行うと簡易調整が出来なくなるようですが、出来たほうがいいと思います。--tomomo 2009年12月28日(月) 19:56
    • ご意見ありがとうございます。現在「簡易調整」の位置づけが定まっていないため、公開当時の条件(最終登録者がautoglyph-botである)を満たすときのみ出現、となっています。--kamichi 2009年12月28日(月) 20:24
    • 簡易調整はなるべく手の入っていないグリフを対象にしたい、ということと、なるべく多くの人にやっていただけるという希望・逆に一見さんに適当に選ばれては困る、という相反する見方から、条件付けが決まっていません。ご意見ありましたらお知らせください。--kamichi 2009年12月28日(月) 20:24
      • 機能追加により厳密にはデザイン調整が入る可能性がありますが「(旧)部品の一括更新」を行ったグリフも簡易調整の対象となるように変更しました--kamichi 2010年2月16日(火) 00:49

  • 「最近更新したページ」で(エイリアス実体変更による自動更新)、(旧部品の一括更新)を表示しない様にするモードがほしいです(ボットの編集を表示/隠す のような感じを考えています)。--uchi 2009年12月27日(日) 11:25
    • ずいぶんと横長になってしまうので「自動登録系を見せる/見せない」という形で1項目の追加を考えます。--kamichi 2009年12月28日(月) 20:25
    • 追加しました。--kamichi 2010年2月11日(木) 18:56

  • エディタの部品検索欄をサロゲートペア対応にして欲しいです。--mandel59 2009年12月26日(土) 16:20
    • ご提案ありがとうございます。サロゲートペア対応というのはたとえばどのような入力を想定しているでしょうか。--kamichi 2009年12月26日(土) 17:13
      • UCS第2面の漢字を検索欄に入力すると、(キーワードが短すぎます)と表示されてしまいます。サロゲートペアを正しく1文字として扱って、検索できるようにしてほしいです。よろしくお願いします。--mandel59 2009年12月26日(土) 17:18
      • ということで修正しました --kamichi 2009年12月26日(土) 23:37

  • エディタについていくつか要望です。
  • まず一つは、直線を曲線に変更したときに、形が乱れてしまいます。 「制御点」は始点と終点の間に出るようにして欲しいです。 二つ目は、曲線を直線に変更したときに、始点と制御点の直線になってしまいます。 出来れば、始点と終点の直線にして欲しいです。よろしくお願いします。tomomo 2009年12月25日(金) 18:03
    • ご指摘ありがとうございます。ずっと手をつけていませんでした。制御点が増減する際の処理を加えました。現状では線種で区別しないで同じ処理としていますが、たぶんこれで問題ないと思います。--kamichi 2009年12月25日(金) 20:12
    • 私の要望ではありませんが、大変使い易くなりました。ありがとうございます。— sayunu 2009年12月29日(火) 12:45

  • glyphEditorの中央下に「明朝」「ゴシック」の切り替えがありますが、それに中心線の表示を追加していただけないでしょうか。曲線との接続の時の位置あわせ等に使用できればと思っております。--uchi 2009年12月16日(水) 00:24
    • これは各ストロークの中心線ということでしょうか?--kamichi 2009年12月16日(水) 00:44
      • はいその通りです。よろしくお願いいたします。--uchi 2009年12月16日(水) 08:36
    • 改造に手間取っています。すみません。--kamichi 2010年1月24日(日) 10:39
    • 線だけにすると選択できなくなるという問題があるので、チェックボックス形式にしてチェックを入れると白抜きの中心線が表示されるようにしてみました。いかがでしょうか --kamichi 2010年8月10日(火) 14:47

  • フォント生成で曲線によるフォントの生成がほしい。「パス」による曲線のSVG画像が出来ているのですから可能だと思います。お忙しい時期の要望ですいませんが、よろしくお願いします。--uchi 2009年12月16日(水) 00:24
    • 実は手元ではやったことがあるのですが、fontforgeが落ちる問題がありペンディングになっています。もう一度トライしてみます。--kamichi 2009年12月16日(水) 00:44
    • 機能追加しました。残念ながらKAGEエンジンが追いついていないのでまだ実用段階ではないのですが、今後の課題とします。--kamichi 2010年2月12日(金) 08:35

  • 残っているbaseparts-付きの部品(baseparts-kuchi,baseparts-kuruma,baseparts-tanbo,baseparts-yotsugashira)について、tsutetoさん、mashabowさんの占有グリフのために自動変換が出来なくなっていると思いますが、お二方とも最近は参加なさっていない様ですので、それ以外のグリフの自動変換をしてほしい。ソフトウェアへの要望ではなく、作業依頼ですがよろしくお願いいたします。--uchi 2009年12月15日(火) 22:00
    • ご指摘どうも。お二方、私も気になっているのですが(今日の臨時会合でも話しが出たのですが)どうもお休みされているようなので、管理者権限ということで強制的に置き換えを行います。で、間の悪いことに学会週間になってしまったので作業は少々お待ちください。--kamichi 2009年12月15日(火) 23:58
    • すみません、上記とは別件なのですが、先日baseparts自動更新のスクリプトを実行したのですが(現在tomomoさんが更新してくださっている)グリフ群が対象になりませんでした。原因は不明です。ちょっと手がつけられない状態なので、ToDo事項として保留扱いとします。--kamichi 2010年1月1日(金) 15:46
    • ああ、わかりました。baseparts-yotugashiraの古い版が使われているためでした。ですので。(1)旧部品引用グリフでbaseparts-yotugashiraの古いものを最新のものに更新する(2)私がbaseparts自動更新プログラムを走らせる、という手順で自動化できます。--kamichi 2010年1月1日(金) 15:50
  • 「baseparts-」について廃止化作業が完了しました。--kamichi 2010年1月1日(金) 20:38

  • GlyphWikiで生成するフォントのベースラインを他のフォントのベースラインに合わせられるようなパラメーターが欲しいです。現状ではIPA明朝と混植するとベースラインがずれてしまいます。--mandel59 2009年10月19日(月) 22:08
    • これも手付かずでした。--kamichi 2010年1月24日(日) 10:39
    • 追加しました。フォントごとの推奨値を提示できるといいですね。--kamichi 2010年2月12日(金) 08:47

  • 自分の投稿履歴が確認できるようにしてほしいです。mandel59 2009年10月16日(金) 16:41
    • 強く賛同します。今はどこか更新する度に一々ローカルなテキストファイルに記録しています。 — sayunu 2009年10月16日(金) 17:51
    • 機能を追加しました。いかがでしょうか --kamichi 2009年10月29日(木) 11:01
    • とても便利です。これで人に何をやっているのか紹介することも出来ます。 — sayunu 2009年11月7日(土) 23:27

  • グリフエディターで部品・複数選択の変形つまみが右下だけに有りますが、四隅に欲しいです。あるいは、四辺をつまんで横方向・縦方向だけに変形できるなら、隅よりも望ましいです。 — sayunu 2009年9月5日(土) 11:50
    • 設計の制約でやや大掛かりな修正が必要です。個人的には必要な昨日と認識しています。--kamichi 2010年1月24日(日) 10:39
    • 上下左右にも用意しました。ただ、端のストロークが外側の枠と重なっていない場合、大きさを変えた時にストロークも動いてしまうので、結局位置調整は必要になります。--kamichi 2010年8月10日(火) 16:33

  • グリフページの「このグリフを内部で引用している他のグリフ一覧」の下に「このグリフの旧版を内部で引用している他のグリフ一覧」がほしいと思います。安易な編集を避けてもらう目的です。先ほどu961d-07が削除されてしまいましたが、時期尚早でした。旧版(@5)を引用するグリフが残っているからです。--y-iijima 2009年9月2日(水) 08:38
    • 今ふと思いつきましたが、上記のような方法よりも、他から引用されているグリフ(旧版が引用されている場合を含む)はシステム側で削除禁止にしてしまったほうが間違いが起こらないので良いかもしれません。--y-iijima 2009年9月2日(水) 11:29
    • ご提案ありがとうございます。これ以上通常ページの負荷を上げたくないので、「他から(旧版であっても)引用されているグリフ」は削除できないようにしました。ただ、ユーザー占有グリフがこれに引っかかると他者からは削除できなくなるという問題があります。これはその問題が起きたときに考えたいと思います。--kamichi 2009年9月3日(木) 21:01

  • 現在の一括更新のような形で、ある部品を使っているグリフを一覧して、その中から一部を選んで、別のグリフに一括置換できる機能がユーザー向けに有るといいです。baseparts から UCS 部品に移行する今の段階ばかりでなく、今後も有用だと思います。例えば部品専用ではないグリフを部品として右側に使っていたのを新設の -02 に置き換えるとか、-08 として左右共通に作った部品を -01 と -02 に分けるとかいう場面が考えられます。 — sayunu 2009年9月1日(火) 16:08
    • 賛同いたします。出来れば、縦方向または横方向に[0-200]のサイズで変換するオプションがほしいです。--uchi 2009年9月1日(火) 20:38
    • 前向きに考えています。機能として、KAGEデータの外周が一致するように取り替える現状に加えて、配置する領域の左上、右下の2座標を固定するモード、XとY方向に大きさと位置の指定ができるモードの追加を考えています。--kamichi 2009年9月3日(木) 21:17
      • まずは機能の実装ということで、旧部品の一括更新に機能追加しました。指定のインターフェースがいまいちのような気もしますが(コメント求む)、なれると便利です。これで問題が無いようでしたら任意の部品間置き換えとして追加します。--kamichi 2009年9月4日(金) 00:17
      • 「部品の大きさを新旧で合わせる」と「新たな配置領域座標を記述 」のミックスモードがほしいです。縦では「新旧」横では「座標指定」または縦では「座標指定」横では「新旧」のような感じです。--uchi 2009年9月5日(土) 06:59
  • 取り急ぎ胸に去来したことを。
    • 「見た目位置合わせ」「見た目位置合わせ後に相対座標変形」「絶対座標指定」の三つですが、「見た目位置合わせをせずに相対座標変形」が欲しいです。つまり、旧部品の座標を基準にする。多分それがあれば「位置合わせ後に変形」より専らそっちを使うと思います、私は。
    • 「見た目位置合わせ」は「位置合わせ後に変形」で数値「0,0,0,0」を指定するのと同じことなので、インターフェイス上は一項目にまとめた方がいいんぢゃないでしょうか。
    • uchi さんもおっしゃっていますが、縦方向と横方向は別にしてほしいです。インターフェイスとしては、メニューとテキストボックスの行を二段にして行頭に「縦方向:」「横方向:」などと書いて、三行目に更新ボタンを置くとか?
    • 対象グリフに複数の旧部品が使用されていた場合、その両方に指定した通りの変形が適用されるようなので、すごい崩れる場合があります。そもそも、部品 A を一括更新する時に部品 B も抱き合わせ更新するのは、B はわざわざ更新を保留してたのに一個だけ更新されてしまったりするし、実行者にも予想外の変化になるので、やめた方がいいです。
  • 以上です。でもこの機能はとても良いです。 — sayunu 2009年9月5日(土) 11:44
    • 縦と横を別に指定できるように拡張しました。それでsayunuさんの「見た目位置合わせをせずに相対座標変形」というのがイメージできないのですが、もう少し説明していただけ無いでしょうか。--kamichi 2010年2月12日(金) 13:56
  • 別の部品への置換も実装されて、位置調整で縦と横に別に指示できる様になって、一括更新時に更新対象以外の旧部品が「ついで更新」されなくなって、ひとまづとても使い易くなりました。
  • (1) 「見た目位置合わせをせずに…」について。まづ整理すると、現在の三種類の配置方法は、次の様な内容だと思います。
    • 補正値の記入無し : 新部品の「見た目外接矩形」が旧部品に一致する様に座標値を変更
    • type1 : 「見た目外接矩形」が一致する様に座標値を変更した上、更に入力値の加算によって相対補正
    • type2 : 旧部品とは無関係に、入力値よって新部品の座標値を決定
  • 旧部品の座標値をそのまま継承して、外接矩形の一致を行わないという選択肢が欲しいんです。例えば、右側用の部品(-02)で、左拂いが左下へ長く伸びている物を想像して下さい。仮に、この左拂いが長過ぎるので、少し短くしたとします。左拂い以外の部分は全く触っていないので、その辺は ずれないで欲しいです。でも突出した左拂いが短くなった事で、外接矩形の形が変わっていて、現行の一括更新では ずれてしまいます。type1 の補正で或る程度なら相殺できますが、この補正値は加算方式なので、全てのグリフに合わせる事が出来ません。(幅広に引用していた場合は 5 px、細く引用していた場合は 2 px のずれになったりする。)そんな場合、旧部品の座標値をそのまま継承できれば便利です。その上で、更新のついでに多少補正も掛けられたらもっと便利だなという事です。
  • (2) それ以外に気になる点を少々。被引用が百件以上の部品について一括更新をする場合、最初の百件のグリフしか表示されないので、困る事が有ります。これまでは「旧部品の更新」だけの話だったので、前から順に更新して進んでいけば何とかなったのですが、別の部品への置換となると、全てを置き換えるのではなく、一部を選択して置き換えるという場合が有ります。例えば、u53e3@7 のうち左側に使われている物を u53e3-01@2 に置換していましたが、左側以外に使われた用例が先頭 99 件を占めてしまったので中断しました。こうなると「次の百件を表示」といった機能も必要ですね。
  • (3) 旧グリフのページにも「部品グリフを別のグリフに置き換える」のリンク文字列が有りますが、リンク先は何も無いページになりますね。例えば :
  • 旧部品から別の部品への置換というのも便利の筈なので、出来ると良いのですが。
  • sayunu 2010年2月14日(日) 12:57
    • 取り急ぎ(3)を修正しました--kamichi 2010年2月16日(火) 01:02
    • 部品更新の100件目以降の列挙に対応しました。一応ご要望はすべて対応したと思うので閉じます。--kamichi 2010年8月14日(土) 12:50

  • ①グリフに対してのコメントの入力がほしい(-itaiji-、-var-、IDSによる記述 等の為です)。②「全グリフデータ」に「関連字」がほしい。③__no_font__ の指定時でも実装率を出してほしい。以上三点ほどお願いいたします。--uchi 2009年8月5日(水) 19:55
    • ご提案ありがとうございます。①は「ノート」ページではダメでしょうか?想定されているイメージをもう少しお知らせください。②は追加します。他の情報も必要があれば追加しようと思ったのですが、とりあえず関連字ぐらいでしょうか。③「グループ」ページがフォント生成ではなく純粋なドキュメントページにもなりうるので、最上部に実装率を記述することにはやや躊躇します。末尾に括弧付けで表示するとか、あるいはHTMLのコメント形式<!-- -->で記述するといういずれかはいかがでしょうか。--kamichi 2009年8月7日(金) 13:42

    • ①表示してほしい情報は、Group:IDSの「メモ」に記述されているような情報です。元ネタは、変更履歴の@1の「編集内容の要約」やリンク先の解説などです。たとえば、u2ff0-u51ab-u571fGroup:国字から『地名「高知県高岡郡四万十町仁井田<ぬた>の川」、現在はさんずいの字が使われている』のメモを持ってきています。またu4e0d-03-var-001は変更履歴に(新規、下に入る部品が中央で上に突き出ている場合)とあり、こういった情報を表示してもらいたいのです。表示位置については特にイメージはありませんが出来れば、「関連字」くらいまでにあればと思います。--uchi 2009年8月7日(金) 17:17
      • そうですね。実はグリフウィキの設計時にはあえて「メタ情報」を保持しない、としました。メモのような情報については他の何か(Webサービス)がグリフウィキと連携する形で別個に存在することをイメージしていました。残念ながら、具体的にそのような何かが出現することはなく、どうすべきか悩んでいます。関連字の拡張とあわせて、グリフウィキ自体を拡張するのか、連携する別のwikiのようなものを立ち上げるのか、も含め思案中です。ご意見ありましたらお知らせ願います。--kamichi 2009年8月7日(金) 18:47
      • uxxxxやaj1-xxxの様に規格化された文字や(ユーザー名)_xxxxxの様な利用者固有のグリフには必要ないと思いますが、-itaiji-、-var-、IDSによる記述 等はグリフの再利用(作成者以外の使用)のためにもちょっとしたコメントがあったほうが良いと思います。また再利用を行うためには外部ではなく、グリフウィキ自体を拡張がいいように思います。ただuxxxxやaj1-xxxの様に規格化された文字に対するメタ情報はグリフウィキ外のほうが良いと思います。--uchi 2009年8月7日(金) 19:47
      • Googleなどでもグリフウィキがかなりヒットするようになっていますが、一般の方がここを見に来た場合、最低限のメタ情報が1~2行増えるだけでかなり親しみの持たれ方が違うと思います。itaijiなどに限らず、どのグリフもメタ情報を持てるようにしたらいいと思います。試行的にはノートページを流用すればいいので、ある特殊なフォーマット(例えばノートページ最上行にコメントアウト形式で書く)で書いた場合だけ、グリフページの目立つところ(例えば「文字コード関連情報」の上)に自動転記するといった感じではどうでしょうか。--y-iijima 2009年8月8日(土) 13:11
      • 私も似たような感じで考えていました。その線で検討したいと思います。--kamichi 2009年8月8日(土) 14:21

    • よろしくお願いします。あとここで書くことではないと思いますが、GlyphWiki:どうやって使うのかで全グリフデータは、1週間に1回ごととなっていますが毎日に変更になっているのではないでしょうか。--uchi 2009年8月7日(金) 17:17
      • ご指摘ありがとうございます。修正しました。--kamichi 2009年8月7日(金) 18:47
      • 変更しました。--kamichi 2009年8月7日(金) 19:49

    • データの表示方法は特にこだわってはいません。末尾に括弧付けで表示する 当たりでお願いできればと思います。以上よろしくお願いいたします。--uchi 2009年8月7日(金) 17:17
    • ③の no_font 時の実装率については、私もあった方が便利だと思います。グリフ数が多い(3000グリフ超など)ページでは末尾まで表示されるのに時間がかかるので、個人的にはページ上部にほしいところですが。--mashabow 2009年8月7日(金) 18:07
      • では、まずはトップに括弧付けとしてみます。--kamichi 2009年8月7日(金) 18:47
      • 短めにつけてみました。--kamichi 2009年8月7日(金) 20:01

    • 機を逸した感が強いですが、メタ情報を記録できるようにする方向に切り替え、試行を始めます。設計上の問題で既存のノートページの末尾を間借りする方法で実装しました。インターフェイス上は分離しているので、あまり違和感はないかと思います。メタ情報の内容は、とりあえずは自由記述としますが、そのうちメタ情報のガイドラインを設けてある程度統一的な内容・記法にしたいと思います。--kamichi 2013年1月30日(水) 21:43

  • 『最近更新したページ』で2ページ目、3ページ目と遡って表示出来る様にしてほしい。(昨日(7/25)1日での更新回数は軽く1000件を越していますので、500件では半分にもなりません)--uchi 2009年7月26日(日) 00:45
    • 同感です。あるいは「0年0月0日(日) 00:00 までに編集された 500ページ」とあるうち「日時」の部分を自由に変更して過去に遡る機能があったらいいと思います。手元にエイリアス設定したいデータがまだ4500字くらいあるのですが、「最近更新したページ」で履歴を500件しか表示できないということが、自由に投稿しづらい壁になってしまっていると思います。--y-iijima 2009年7月26日(日) 07:24
    • 更新した人が同じ場合は他何件のように表示するモードがあればよいのではないでしょうか。horaiwataru 2009年7月26日(日) 11:34
    • このご要望は前からペンディングになっていたのですが、やっと対応しました。--kamichi 2009年7月27日(月) 14:51
      • かなり使いやすくなったと思います。ただ「後のn件」「先のn件」よりも、隣の「最新」「最古」に合わせて「新しいn件」「古いn件」にした方が分かりやすいと思うのですが、いかがでしょう? --mashabow 2009年7月27日(月) 18:34
      • 分かりにくいなぁと思いつつWikipediaに盲目的に従っていました。変えます。--kamichi 2009年7月27日(月) 18:36
      • 対応ありがとうございます。なるほど、Wikipedia がそうなっていたんですね。--mashabow 2009年7月27日(月) 18:54

  • エイリアスの参照元と参照先の入れ替え機能があったら良いなと思います。--uchi 2009年7月23日(木) 00:03
    • そうですね。実装したいと思います。--kamichi 2009年7月23日(木) 22:51
    • やっと実装できました。--kamichi 2013年1月22日(火) 14:17

  • 専用エディタ内の部品検索で、kumimoji-####のグリフを検索一覧から外してほしい。--uchi 2009年7月12日(日) 22:18
    • 部品検索についてはいろいろToDoが残っていますがこれもそうします。--kamichi 2009年7月23日(木) 22:51
    • 対応しました。--kamichi 2009年8月25日(火) 23:43

  • 自動生成されたグリフのうち、まだ手が加えられていないグリフについては、もう一度生成しなおしてはどうでしょうか。baseparts-* ではなく u####-## を使うようにすれば後で移行する手間が省けますし、バランスも少しは良くなるはずです。--mashabow 2009年7月11日(土) 11:24
    • ご提案ありがとうございます。先日自動生成を実行したときはautoglyph-botが最終投稿者のグリフも自動生成対象にしたと思いますがうまくいってないでしょうか?実は旧部品の一括更新機能を使ってしまうとautoglyphによる生成グリフもユーザーが修正したことになってしまうので先日の自動生成対象から外れています。それも対象に含める改良が必要と認識しています。
    • もう一つ、もうすぐ仕事が一段落し、グリフウィキに費やせる時間が確保できる(ハズ)ので、現在の自動生成(単なる過去のデータの平均。よって部品同士の隙間や重なりが生じる欠点がある)を、KAGE/cgiの生成エンジンと合体させることを考えています。すると目論見ではもう少し品質が向上すると思っています。--kamichi 2009年7月11日(土) 13:08
    • 長期的検討課題ということで、いったん閉じます--kamichi 2010年2月12日(金) 09:52

  • 専用エディタ内の部品検索で、グリフ名がIDS形式であるものは不要だと思うので結果から除外されてはいかがでしょうか。他グリフの部品として使えるものはほとんどないと思うのですが…。--y-iijima 2009年7月6日(月) 08:50
    • 専用エディタの部品検索は要改良なので議論したいと思います。mandel59さんの部品リストや、既存データの部品利用頻度を含めた提示や、検索対象を検討できればと思います。--kamichi 2009年7月11日(土) 13:11
    • これに関連して、IDS形式の名前をもつグリフ(例えば u2ff0-uxxxx-uyyyy)を作成する際に現状では u2ff0-uxxxx-uyyyy で検索されて「該当部品なし」となりますが、自動的に uxxxx OR uyyyy とみなして検索されるようになるとラクではないでしょうか。--mashabow 2009年7月12日(日) 22:41
    • とりあえずIDSは対象外とするよう変更しました。--kamichi 2009年8月25日(火) 23:43

  • 各ページに、版の番号・リンクを表示してください。--mandel59 2009年6月21日(日) 13:32
    • 個人的にほしいと思っていたのですがインターフェースの参考とするWikipediaでは出ていない(あちらは最新版のみがメイン)なので入れていませんでした。ということで、最新版グリフ表示ページについてのみ表示するようにしました。ところでリンクというのはどこへのリンクでしょうか。--kamichi 2009年6月21日(日) 15:55
    • Wikipediaのツールボックスにある、「この版への固定リンク」のようなものです。--mandel59 2009年6月21日(日) 16:03
    • ご教示ありがとうございます。それでしたら現在作業中の他言語へのリンクとあわせて追加します。ちょっと苦労しているのでお待ちください。--kamichi 2009年6月21日(日) 17:41
    • なかなか手をつけられないので先に設置しました。--kamichi 2009年7月27日(月) 19:06

  • バックアップアーカイブのためのREADMEを英語に翻訳しておきました。Group:dump-README-en。よろしければ、アーカイブに含めていただけませんでしょうか?ファイル名を「README_en.txt」になれば、いいと思います。日本語の「README.txt」のファイル名をそのままにしても、「README_ja.txt」にしても、個人的に構いませんが、「_ja」を付けたほうが明らかかもしれませんjeroen 2009年6月5日(金) 06:58
    • ありがとうございます。ファイル追加+ファイル名変更しました。ところで花園フォントもそうですが、jaとenでファイルを分けるべきか、各ドキュメントで統一しておいた方がいいと思います。現状ではそれほど長い文章ではないので一緒にしていますが、分けた方がいいでしょうか?--kamichi 2009年6月6日(土) 23:20
      • そうですね、利用者にとって統一されて、それぞれの言語をそれぞれのファイルに分けたほうが明らかだと思います。ところが、もし将来にほかの言語も含めるようになると、または花園フォントのREADMEが大きくなると、便利かもしれませんが、そういうファイルの内容が約二十行を越えないと、分けなくてもいいと思います。jeroen 2009年6月7日(日) 00:26
      • 了解です。ありがとうございます。--kamichi 2009年6月7日(日) 01:09

  • フォント生成に失敗した場合、わかるようにしてほしい。--uchi 2009年4月12日(日) 19:26
    • すみません。判定できるかどうか、いま調査中です。--kamichi 2009年4月13日(月) 00:28
    • 追加しました。ただFirefoxではキャッシュがなかなか更新されない状況が確認できています。--kamichi 2009年4月13日(月) 07:20

  • 新たに備えられた「井戸端」へのリンクをメインページも、ナビゲーション又はヘルプというリンク集にも含むと便利かもしれませんjeroen 2009年4月9日(木) 23:52
    • 追加しました。ご提案ありがとうございます。--kamichi 2009年4月10日(金) 14:23

  • 現在、言語間リンクは常にトップページを指していますが、たとえばページ中に[[ en:GlyphWiki:GlyphNaming]]と書くとそのページへのリンクに変更できるようにならないでしょうか。--emk 2009年4月2日(木) 07:52
    • バーベイタム機能を使おうとしたのですがうまくいかなかったので、「[[ 」の後ろに空白を開けました。バーベイタム機能の使用例はありませんか?--emk 2009年4月2日(木) 07:52
 --バーベイタムは行まるごとの指定のみのようです。--[[kamichi User:kamichi]] 2009年4月2日(木) 10:35
    • バーベイタムは行まるごとの指定のみのようです。言語間リンクについては追加します。Wikipediaの中国語指定についてはいろいろなバリエーションがあってややこしいですね。--kamichi 2009年4月2日(木) 10:35
    • やっと追加できました--kamichi 2010年2月12日(金) 09:50

  • u4e55u200b0の変更履歴を見て思ったのですが、u####形式のグリフの関連字を自分自身以外に変更できる必要はあるのでしょうか。--emk 2009年3月29日(日) 21:42
    • UCS符号位置に相当するグリフに関連字を任意で設定できるかどうかは設計時に迷いました。結局現状ではUCS符号位置そのままにして、くっつけたい場合は「関連付けるべきグリフ」で結びつける方向になっています。ですので強制的にしてもいいのですが、UCSに対してこれ以上例外を増やすことに躊躇してそのままです。UCS符号位置そのもの、別ソース、偏化変形部品、-itaiji、の4種については強制的に割り当てる方向で考えてよいと思います。--kamichi 2009年3月31日(火) 13:13
    • やっと修正しました --kamichi 2009年8月7日(金) 18:33

  • トップページのURLが2つ存在している(http://glyphwiki.org/ http://glyphwiki.org/wiki/ )ので、ブックマークや言及リンクが分散してしまっています(e.g. http://b.hatena.ne.jp/entry/http://glyphwiki.org/ http://b.hatena.ne.jp/entry/http://glyphwiki.org/wiki/ )。リダイレクトさせて一本化できませんでしょうか。--mashabow 2009年3月24日(火) 01:14
    • http://glyphwiki.org/wiki/ にリダイレクトすると検索エンジンから見えなくなってしまうという問題がありますね。負荷の問題とか書き込めるところなら見境なしに爆撃するspambotの対策としてクローラを弾いているのだと思いますが、もう少し何とかならないものでしょうか。--emk 2009年3月29日(日) 21:42
      • Sitemapsを使えば主要な検索エンジン(Google, Yahoo, Microsoft, Ask.com)のクローラの負荷を軽減できると思います。http://en.wikipedia.org/wiki/Sitemaps --匿名利用者 2009年3月29日(日) 22:28
      • トップページのURLですが、Wikipediaを参考に http://glyphwiki.org/wiki/メインページ にするのも一手と思います。これは変更を考えています。--kamichi 2009年3月31日(火) 13:13
      • robots.txtの設置は、クローラの負荷・spambot爆撃というよりも、グリフウィキ運用開始時に、どのようなデータが投稿されるか不明だったので、下手にキャッシュされると後で取り下げたくなったときに面倒だ、という意図で設置しました(実際同じサーバで別ドメインが動いていてひっきりなしにクローラが来ています)。現状についても、ドキュメントページについては好きな文章を投稿できるので検索エンジンによるキャッシュは望ましくないと考えています。emkさんの「何とかならない」という対象は何でしょうか?あと、そういえばspambot爆撃が来ないな、と思いはや1年半ですが、そういう効用もあるわけですね。--kamichi 2009年3月31日(火) 13:13
      • グリフの画像ファイル自体は/glyphに分離されているのでクロール排除の対象になっていませんがリンクされていないのでもったいないですね。たとえば/wikiの内容を閲覧のみの固定ページとして別ディレクトリ(/document)から参照できるようにするとか、そうすればいいかもしれません。--kamichi 2009年3月31日(火) 13:13
      • 「何とかならない」というのは、検索エンジンにヒットしないと認知されないという意味です。少人数でひっそりやっていくなら問題ではありませんがそういう方針ではないみたいですし。spambotには認知されたくないという問題もありますけど。--emk 2009年4月2日(木) 07:52
  • そうですね。基本的にrobots.txtを無くす方向で考えたいと思います。spambot対策を考えましょう。KAGEデータの方はチェックすればはじけますが、問題はドキュメントの方ですね。一応bot対策ということでurlを記述してもリンクだけでインライン展開しないようにしていますが、それだけでは足りないです。--kamichi 2009年4月7日(火) 00:43
  • 遅ればせながら http://glyphwiki.org/wiki/GlyphWiki:メインページ および http://en.glyphwiki.org/wiki/GlyphWiki:MainPage にリダイレクトするように変更しました。メインページは「GlyphWiki:」をとるとすっきりしますが、あまり特例を増やしたくないので、そのままです。--kamichi 2009年4月21日(火) 00:22

  • FontForgeにもIVS対応フォントを作成する機能 があるようなのですが、この機能を使ってフォントを生成できませんか?--emk 2009年3月21日(土) 22:33
    • GUIでは確かにできることを確認しているのですが、現状ではFontForgeのscriptからIVSを指示する関数を見つけることができないため、やむなくTTXを併用しています。なにか情報は無いでしょうか?--kamichi 2009年3月21日(土) 23:04
    • FontForgeのスクリプトではできないようです。GUIを使わない場合、.sfdファイルにAltUni2を直接追加する必要があるようです。--emk 2009年3月29日(日) 21:42
    • AltUni2を考えたのですが、デフォルトでFontforgeが出力する.sfdファイルはAltUni2に対応していない古いバージョンなので、AltUni2を追記するだけでなく、いくつか変更する部分が出てきて面倒なのでやめました。--kamichi 2009年3月31日(火) 13:13

  • ところで、今は管理用に私だけが使っている機能として、新着投稿があったときにメールでお知らせするものがありますが、一般に開放してほしいという要望はありますか?古い部品の一括更新とか、autoglyphbotの活動で100とか10000とか届いてしまうことがあるので、多少調整が必要ですが。--kamichi 2009年3月20日(金) 21:15
    • 特にコメントがないので、将来のネタにします。--kamichi 2009年3月31日(火) 13:13

  • 下の要望に関連して、最近更新したページ(Special:Recentchanges)に「記事の編集のみ表示(=グリフの編集は隠す)」というオプションがあれば、議論の流れが追いやすくなるような気がします。また、最近の500件分以降の表示も可能になると助かります。--mashabow 2009年3月20日(金) 20:56
    • 同感です。そういう機能があれば使います。jeroen 2009年3月20日(金) 21:05
    • 御意。それ有用ですね。--kamichi 2009年3月20日(金) 21:18
    • まずはページ種別選択機能をつけました。--kamichi 2009年3月21日(土) 01:40
    • 履歴のページ切り替えにやっと対応しました。--kamichi 2009年7月27日(月) 14:51

  • ページの差分表示が欲しいです。--匿名利用者 2009年3月13日(金) 10:27
    • 追加しました。--kamichi 2009年3月16日(月) 11:39

  • 未作成のグリフのサムネイルはmandel59_undefこのような赤い印が表示されますが、現状では赤い印の画像のファイル名が全て違うためにブラウザがすべてを参照してしまい、表示に時間がかかるようです。HTMLに出力される、画像の場所を一つにできますか? --mandel59 2009年3月9日(月) 20:00
    • ということでやってみました。--kamichi 2009年3月9日(月) 22:03

  • グリフページにその部品を一括更新するページへのリンク --kamichi 2009年1月24日(土) 12:42
    • 今後のスケジュールに移動 --kamichi 2009年6月17日(水) 15:48

  • 99部品について、接着フラグを立てると下端などの開放形状が接続形状になる機能 --kamichi 2009年1月23日(金) 09:36
    • 今後のスケジュールに移動 --kamichi 2009年6月17日(水) 15:48

  • 仮想ボディの底辺でカカトの調整をする。もしくはカカトを短くする --kamichi 2009年1月22日(木) 22:11
    • 今後のスケジュールに移動 --kamichi 2009年6月17日(水) 15:48

  • ExtC祭でいただいたご要望 --kamichi 2009年1月22日(木) 13:24
    • エディタ
      • 部品のコピー
      • グリッド吸い付き
      • グルーピング
      • 比率固定のサイズ変更
    • ユーザーの投稿履歴閲覧
    • グリフに対するメタ情報の記録
    • プレビュー時に前バージョンと比較できる
    • カカト調整で曲線の制御点を使わない
    • 部品の一括差し替え(矩形サイズによる計算およびグリフ名のみの2種類)
      • 今後のスケジュールに移動 --kamichi 2009年6月17日(水) 15:48

  • レコードへの最新フラグの付与--kamichi 2009年1月12日(月) 18:19
    • つけました。--kamichi 2009年5月28日(木) 16:15

  • 旧部品一括更新で、すべてにチェックをつけたことにする機能をつける --kamichi 2009年1月12日(月) 17:59
    • つけました --kamichi 2009年1月12日(月) 20:47

  • 最終更新者がautoglyphでないグリフについても簡易調整機能を表示する(落ち着いたグリフも編集されてしまう可能性があるので、バランスをどう確保するか)--kamichi 2009年1月12日(月) 15:12
    • 今後のスケジュールに移動。議論が必要 --kamichi 2009年6月17日(水) 15:48

  • 「旧部品引用グリフ」ページの再構築(遅い)--kamichi 2009年1月12日(月) 13:51
    • ひとまず1段階完了 --kamichi 2009年1月12日(月) 18:19

  • 自身の古いバージョンが他のグリフから引用されている場合に、旧部品の一括更新ページへのリンクを表示する --kamichi 2009年1月12日(月) 13:51
    • 今後のスケジュールに移動 --kamichi 2009年6月17日(水) 15:48

  • 作成されたフォント(花園明朝等)や(SVG画像)が直線近似で作成されています。曲線で生成することはできないのでしょうか?--uchi 2009年1月2日(金) 08:26
    • これは私の知識不足です。KAGEエンジンは曲線の骨格を2次スプラインで表現します。この骨格から等幅(払いなどの場合、0から1の間で直線的に太さが変化します)となる2次、3次曲線の関数で表現できればいいのですが、現状では不明なため、単純に曲線を分割して直線の集合を取っています。たとえばFontForgeでは1つの曲線線分に等幅の太さを持たせる編集があります。この部分に相当する機能をKAGEエンジンで実装できればいいのですが。このあたりの実装についてどなたか相談に乗っていただけないでしょうか。--kamichi 2009年1月2日(金) 12:14
    • 和田研フォントの肉付けをさんという方がhttp://kzk9.net/column/wadaken/ で解析されているようです。参考にできないでしょうか?--uchi 2009年1月2日(金) 22:07
    • inkscape次期版のLive Path EffectのFreehand shape(太さを自由に弄れるもの)ではsvgに独自拡張の目印を付けて実装しているようです。同様にspline curve(点を通る曲線)のspiroも実装している訳ですが、こっちも同様のようです。inkscape拡張のsvgを吐いてinkscapeで変換すれば良さそうですが、バックエンドにinkscapeを使うわけにはいかないと思うので参考までに。--匿名利用者 2009年1月2日(金) 22:56
    • イベントの準備も含め少々優先度が低くなっています。mashabowさんが独自肉付けにチャレンジされてまして、成果を取り込む・差し替えができればと思います。--kamichi 2009年1月10日(土) 01:19
    • テスト版機能を追加しました。各グリフ最新版の「SVG画像 パス」がそれです。曲がり具合の激しいグリフについての検証がまだ終わっていません。現在グリフを再生成中なので、それが終わり次第花園フォントに用いてチェックしたいと思います。--kamichi 2009年5月28日(木) 16:15

  • フォントの生データ一式(ソース)をまとめて公開して欲しいです。バックアップしているとは思うのですが不安ですし、KAGE/cgiを試そうと考えているので使いたいです。--匿名利用者 2009年1月2日(金) 00:08
    • 「フォント」は何を指していますか?「グリフ」データのことでしょうか。グリフウィキのすべてのグリフデータ(「編集」タブで表示される「1:0:0:10:12:160:198」などのKAGE形式のデータ)をまとめて公開してほしいということでしょうか。公開するとしてどのような形態がいいでしょうか。たとえばウィキペディアは全データ公開ってやっているんでしょうか。ちょっと調べてみます。 --kamichi 2009年1月2日(金) 00:15
    • 定期的に別の場所にデータのスナップショットを置けると良いと思います。データの種類、形式、間隔、場所などが検討事項です。場所はたとえばsourceforgeなどが想定されます。--kamichi 2009年1月2日(金) 00:28
    • グリフウィキのバックアップについて現状では同HDDにDBのダンプを1日おき、別HDDに関連データすべてを1週間おきに自動バックアップしています。今回のご提案を受けて、一部のデータ(純粋な投稿データ)についてはkage.sourceforge.jpへ1週間ごとの蓄積も行うことにします。 --kamichi 2009年1月4日(日) 13:47
    • 準備しました。こちら をご覧ください。 --kamichi 2009年1月5日(月) 07:19

  • (特にインポートした)グループから任意のグリフをフォント化しない記述機能の追加--kamichi 2008年12月17日(水) 09:39
    • 追加済 --kamichi 2008年12月30日(火) 09:26

  • 横棒の下に接続する斜めの直線(u4e02のT字部分など)についても、横棒の下の左払いと同様に、切り口を水平にできないでしょうか? --mashabow 2008年12月4日(木) 21:01
    • ご指摘ありがとうございます…。現在機能に関する作業時間が取りにくい状況ではありますが早急に直します。--kamichi 2008年12月4日(木) 22:49
    • すみません。まだ着手できていません。今後のスケジュールに移動しました。--kamichi 2009年1月22日(木) 12:06

  • ウィンドウを小さくしたときに文章が自動改行してください。--kitti 2008年11月26日(水) 22:15
    • ご指摘ありがとうございます。画面を設計する際、Wikipediaのcss等を引用せず一から画面を作っていった関係で、見た目はWikipediaに似ているのですが構造が全然異なってしまいました。その1つとしてこの改行問題があります。もしくはcssの問題点を指摘してくださるとありがたいのですが、この問題修正の優先度は低いのが現状です。--kamichi 2008年11月26日(水) 22:30
    • 実現の見通しが悪いので閉じます。--kamichi 2009年3月21日(土) 23:15

  • 基本的にノートページは要らないんじゃないですか?グリフページにかけるので。--kitti 2008年11月26日(水) 22:15
    • まず確認ですが、グリフページには字形データしか書けません。文書を書けるのはドキュメントページ(wiki名が「GlyphWiki:」で始まるもの)のみです。また現状ではグリフ登録に参加してくださっている方がエキスパートな方(ISO/IEC 10646やJIS規格の正しい字形を認識できている)がほとんどなので、意見・見解の齟齬がおきにくい幸運な状況にあるためであり、基本的にノートページは必要と考えています(たとえばTalk:u23dacのようなケースもありました)。--kamichi 2008年11月26日(水) 22:30
    • とくにご意見がないようなので閉じます --kamichi 2008年12月30日(火) 09:26

  • Wikipediaのインターフェースに固執しない。たとえば1つのグリフをベースにした新しいグリフを作成する機能(別名コピー) --kamichi 2008年11月24日(月) 12:40

  • 横棒の下に左払いを接続したとき、左払いの上部が突き抜けて表示されてしまうのは何とかならないでしょうか。u9858@2のように本来接続されている部分を切り離すような調節をしなければならないのは、あまりよくないように思います。--emk 2008年10月29日(水) 01:23
    • ご指摘ありがとうございます。優先度を上げます。--kamichi 2008年10月29日(水) 07:52
    • とりあえず水平横棒に対して接続するものと仮定した上で切り口が水平になるように改良しました。傾きのある横棒や、曲線に対しての切り口調整は後回しにします。特に問題がなければ全グリフへの適用+ファイル再生成を行います。--kamichi 2008年10月29日(水) 14:32

    • 全グリフへの適用を現在実施中ですが、「家」などに悪影響が出てしまいました。接続の対象を限定する改良が必要です --kamichi 2008年11月5日(水) 13:32
    • 以降、順次他のケース(毎)にも適用していきます --kamichi 2008年11月5日(水) 14:23
    • この改良に際し、他画接合の筆画の開始・終了位置を座標にあわせるようにした(もともとは線の幅だけ膨らましていた)ため、「家」などのストロークの開始位置に隙間ができているグリフがありますが、本来接合するストロークの芯に開始位置を合わせるべきなので、これは今後データのほうを修正する必要があります --kamichi 2008年11月5日(水) 14:28

  • ページの読み込みに時間がかかるので、多くのグリフに引用されている場合、そのグリフを少しずつ表示する(または別ページで表示する)ようにしてほしいmandel59 2008年10月28日(火) 19:08
    • もしよろしければ具体的な該当ページを教えてください。現状でページ生成の8割以上の時間をページリンクの未リンクを赤色にする作業に費やしていると思われまして、非常にネックになっています。グリフページのリンク存在チェックとドキュメントのそれとで別の方法を取っていて、このうちドキュメントへのリンク存在チェックがSQLの実行を伴うため遅くなっていると考えます。ということで、もしmandel59さんの指摘される遅いページというのがドキュメントへのリンクを多く含むページなのであれば、ドキュメントページへのリンクチェックについてどうにか改善すればよいと思います。
    • それともグリフのサムネイル画像の表示が遅いということでしょうか?これはapacheに対する多重リクエストをうまくさばけていないのか、もしくはglyphwiki.orgを設置するネットワーク(Bフレッツ+VDSL)もしくはルータに問題があるのかもしれません。
    • お願いばかりで恐縮ですが、1秒単位で結構なので具体的な表示にかかる秒数を計測していただけると幸いです。その際、ページ自体の読み込み時間と、グリフのサムネイルも含めた完全な表示にかかる時間の2種類を教えていただきたく思います。--kamichi 2008年10月28日(火) 20:11
      • 例えば、baseparts-sanzuiは現在“このグリフを内部で引用している他のグリフ一覧”のグリフがひとつなので、表示も2秒ぐらいですが、baseparts-sanzui@3のように、大量に引用されているページでは36秒かかりました。
      • “このグリフを内部で引用している他のグリフ一覧”は登録済みのグリフの一覧なので、別ページで表示しても良いと思います。mandel59 2008年10月28日(火) 20:28
      • あと、関連字が大量に表示されるページ(u53f3“右”など)も時間がかかるようです。mandel59 2008年10月28日(火) 20:32
  • 情報ありがとうございます。たしかに時間がかかりますね(これらの旧部品を新部品に更新するのは大変です…)。問題となっているのは私の考えていたところと別のところでした。被引用対象などの情報を別ページにするか、一部だけ表示にするか、および生成プログラム部分の再検討も含め調査、改善します。ご指摘ありがとうございます。--kamichi 2008年10月28日(火) 20:41
    • 対応しました --kamichi 2008年12月30日(火) 09:46

  • プレビューのときに大きい文字だけでなく小さい文字(あなたのブラウザでの表示のサイズ)も表示して欲しいです。hnakamur 2008年10月28日(火) 02:37
    • これはサムネイルの50ドットよりも小さい字ということでしょうか?となると初めて用意することになるのでちょっと優先順位が下がります。現状ではグレースケールを用いた小さなグリフ画像の生成は単純な黒面積比の変換でやっているので50ドットよりも小さくなるとつぶれてしまうかもしれません。--kamichi 2008年10月28日(火) 20:11
    • ご意見が無いようなので閉じます --kamichi 2008年12月30日(火) 09:26

  • u4e41のような新端形状の追加 --kamichi 2008年10月22日(水) 21:50
    • 今後のスケジュールに移動 --kamichi 2009年1月22日(木) 12:06

  • Safariに続いてFirefox 3.1(現状ではbeta)でも@font-faceが使えるようになったので、それに対応した機能(グループページにおいて実際の生成フォントを使ったグリフ一覧とか)

  • u4e44の左払い上はねの実装 --kamichi 2008年10月15日(水) 22:52
    • 今後のスケジュールに移動 --kamichi 2009年1月22日(木) 12:06

  • グループに関して、未実装グリフ数の表示、および引用グリフ・引用グループの更新時にどうするか --kamichi 2008年10月15日(水) 22:52

  • 戸の旧活字のような角度の浅い左下払いの頭の形状の改良 --kamichi 2008年8月2日(土) 11:07
    • 今後のスケジュールに移動 --kamichi 2009年1月22日(木) 12:06

  • エイリアスの関連グリフ情報は手抜きをせずにエイリアス先の関連グリフを引っ張って使うようにしたい --kamichi 2008年7月27日(日) 18:36

  • エイリアスのページからも文字コード関連情報を参照できるようにしてほしい。 --匿名利用者 2008年7月24日(木) 15:23
    • エイリアスのページ名がUCS符号位置相当の場合のみ情報を出すようにしました。そうでない場合は、エイリアス先のグリフの関連字を引っ張ってくる必要があり、煩雑になるので表示しないようにしています。これを仕様とするかどうか悩むところです。また、履歴のページも「最新でない」ことを強調するために関連情報を表示したくないところですが、今は表示するようになっています。これも悩むところです。 --kamichi 2008年7月24日(木) 16:41

  • 引用部品が更新された時の最新部品への一括更新機能 --kamichi 2008年6月10日(火) 16:01

  • デザイン時に使おうとする部品が他のグリフでどこにどの大きさで配置されているかを表示する機能。透過にして濃くなる部分が頻度の高い場所を示す。部首で上下に隙間ができる部品のデザインに便利 --kamichi 2008年3月4日(火) 15:44
    • または平均的な場所に移動する機能 --kamichi 2008年3月4日(火) 17:17

  • 検索機能の対象を最新バージョンに限るか、全バージョンにするか。古い情報の隠蔽ポリシー --192.168.11.3 2007年11月23日(金) 08:50

  • ユーザ専有と同様、ユーザーグループの設定と、グループ専有命名記述 --192.168.11.3 2007年11月4日(日) 08:50
    • すでに「グループ」をグリフ集合の意味で使ってしまっているので、ユーザ集合を表現する言葉を考える必要あり --192.168.11.2 2008年1月19日(土) 17:58
    • GlyphWiki:今後のスケジュールに移動 --kamichi 2009年3月21日(土) 23:15

  • 0:0:0:0をIDS区分記号とし、IDSデータ内蔵とあわせて仮想部品の実現 --192.168.11.3 2007年11月2日(金) 08:43
    • グリフエディタでメタ情報を編集する機能を考えること --192.168.11.2 2008年1月19日(土) 17:58
    • KAGEデータの構造化(XML?) --kamichi 2008年6月10日(火) 16:01
    • 今後のスケジュールに移動 --kamichi 2008年12月30日(火) 09:46