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

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

GlyphWiki:バグ報告

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

グリフウィキでのページエラーや挙動がおかしいところなどがありましたら是非ご報告願います。なお、ソフトウェアの改変状況はシステム変更記録に載せていきます。

記述は、新しい項目を上にして、項目ごとに1行空行を入れてください。

また、機能の追加などに関する要望は、ソフトウェアへの要望にてお願いします。ネットワークの不具合と思われる場合など、サイトのサービス不全についてはお知らせにて連絡願います。


  • 「グリフウィキには現在この名前の項目はありません。」ページの翻訳が消えました。jjanggu 2020/11/24 15:22

  • 既に存在するグリフを編集するとき、プレビュー画像が表示されない。--kesuuko 2020年11月24日(火) 12:16
    • すみません、修正しました。--kamichi 2020年11月26日(木) 19:56
      • 似た原因と思われるバグとして、「未作成のグリフの編集ページで、グリフエディタと関連字の間に存在していたはずの改行が消滅している」があります--kesuuko 2020年11月26日(木) 20:01

  • HTMLエディタでは、「←入替」「←」「入替→」「→」は中国語を表示言語にすると「作为前一」「前一」「作为后一」「后一」と表示しました。

  • KAGE-Editorを使用すると、既存のグリフを読み込めないようで、「错误:TypeError: Failed to fetch」というメッセージが表示されます。--fitzgerald 2020年10月16日(星期五) 00:00
    • (バグ報告のほうにお書きください)ほかに同様の症状の方はいらっしゃいますでしょうか?--kamichi 2020年10月15日(木) 23:51
    • ちなみに、本家 https://github.com/kurgm/kage-editor のほうでも同じ症状でしょうか?--kamichi 2020年10月15日(木) 23:52
      • はい、私はそこに行き、メッセージを残します。
      • しかし、githubには大変申し訳ありませんので、2番目の質問にはお答えできません。--fitzgerald 2020年10月15日(星期四) 23:58
    • 状況がよくわからないのですが、エディタは表示されるということでしょうか?左側の編集部分にグリフは表示されますか?右側の部品検索にグリフは表示されますか?あとOSとブラウザの種類も教えてほしいです。--kamichi 2020年10月16日(金) 00:22
    • わかりました、クエリーをhttpsで出す部分がありますね。これどうやって直すのか、調べてみます。ご指摘ありがとうございます。--kamichi 2020年10月16日(金) 00:33
      • 修正しました。試してみてください。--kamichi 2020年10月16日(金) 01:04
      • 問題は解決しました、どうもありがとうございました。--fitzgerald 2020年10月16日(星期五) 09:56

  • 細入り→左ハネ の曲線の終筆部分について、角度によっては右払いのポリゴンがはみ出て見えることがあります(sandbox@6199)。また、SVG画像を拡大してよく見ないと分からない程度ですが左ハネ付近で太さが揃っておらず段差が生じています(u9725@12の下などは段差が見えやすいでしょうか)。―twe 2020年8月30日(日) 00:22

  • 白抜きグリフのSVGが白抜きにならないようです(u2776@8など)。―twe 2020年8月26日(水) 09:54
    • ご指摘ありがとうございます。外部ライブラリ(Clipper)のメソッド名が変わっていました。修正しました。影響するグリフについて再生成を実施します。--kamichi 2020年8月26日(水) 10:39
      • 再生成完了しました。--kamichi 2020年8月26日(水) 11:05
    • 今回のサーバ入れ替えで導入したClipperライブラリが以前と別のものでした。前のものに戻しました。再度2020年8月16日 08:30以降の全グリフの再生成を行い、SVGデータを以前と同じ形式に戻します。--kamichi 2020年8月26日(水) 21:34
      • 再生成完了--kamichi 2020年8月27日(木) 09:27

  • GlyphEditorでは日本語以外の言語版では「部品検索」は使用できず、ページ番号に「1 / NaN」が表示されることが判明しています。グリフボックスに既存のグリフがある場合、それらは表示されません。--fitzgerald 2020年8月26日(星期三) 01:58
  • PS:これは、日本語以外の環境でGlyphEditorを開くことを指します。--fitzgerald 2020年8月26日(水) 02:06
    • ご指摘ありがとうございます。HTTPSでアクセスしているとうまくいくようですが、そうすると中国大陸のユーザーが困るため、対処法を検討中です。--kamichi 2020年8月26日(水) 08:07
      • 上記「うまくいく」のはFirefoxだけのようです。Chromeは不具合が発生します。--kamichi 2020年8月26日(水) 08:58
    • 設定を変更して{en,ko,zhs,zht}.glyphwiki.orgのHTTPアクセスでもグリフエディタが正常に作動するように修正しました。--kamichi 2020年8月26日(水) 09:29

  • u298c6-j@3のSVG画像に於いて、馬偏の一部が黒塗りになってしまう。--kesuuko 2020年8月16日(日) 16:06
    • u2a0f9-j@1も同様のバグが鳥の部分で発生。--kesuuko 2020年8月16日(日) 16:29
    • u92c2-g@1u93a2-t@2で同じバグが発生しました。--someyamako 2020年8月16日(日) 19:31
    • 今回のサーバ入れ替えで影響は起きないはず(Ruby,Clipperいずれも同じもの)なので、以前から発生していたりしないでしょうか。いずれにしても直します。--kamichi 2020年8月17日(月) 15:35
    • なぜかclipperの重ね塗り部分の出力が変わったようなので、SVG側を修正して対応しました。いつからこうなったのかが不明ですが、おそらくサーバ切り替え後だと思うので、切り替え後の全SVGの再生成を行う予定です。--kamichi 2020年8月17日(月) 18:28
    • 再生成完了しました。--kamichi 2020年8月17日(月) 22:07
    • 今回のサーバ入れ替えで導入したClipperライブラリが以前と別のものでした。前のものに戻しました。再度2020年8月16日 08:30以降の全グリフの再生成を行い、SVGデータを以前と同じ形式に戻します。--kamichi 2020年8月26日(水) 21:34
      • 再生成完了--kamichi 2020年8月27日(木) 09:27

  • 2点報告します。—twe 2020年8月13日(木) 20:40
    • 1. プレビュー時の「UCS関連グリフの関連字に別の文字の割り当てや未定義(〓)とすることはできません。別の文字を関連付けたい場合は関連付けるべきグリフに記述して異体字としての関連付けを申請してください。」というエラーメッセージで「関連付けるべきグリフ」の部分が GlyphWiki:GlyphWiki:関連付けるべきグリフ へのリンクになっています。(「GlyphWiki:」が一つ多いです。)
      • 修正しました。--kamichi 2020年8月17日(月) 16:45
    • 2. 統合漢字拡張Gの符号位置のUCS関連グリフでは、上記のエラーメッセージが出ないようです。
      • こちらもバグを修正しました。--kamichi 2020年8月17日(月) 16:55
  • ご報告ありがとうございます。サーバ切り替えが完了してから直します。--kamichi 2020年8月16日(日) 10:36
    • 修正完了とします。--kamichi 2020年8月17日(月) 16:55

  • u2ff1-u25ad7-u4ed3@3の仓の撥ねの部分がおかしい。--kesuuko 2020年8月12日(水) 17:29
    • ご報告ありがとうございます。サーバ切り替えが完了してから直します。--kamichi 2020年8月16日(日) 10:36
    • これは、撥ねの生成時に端点の位置を少し手前に移動する処理をした際に新たな端点と中間の制御点が接近しすぎ、ベジェ曲線があまりにも急カーブになって太くした際に制御点の位置が逆転してしまうことが原因のようです。バグというよりは、骨格部品の拡大縮小だけでグリフを生成している以上やむを得ない問題かと思います。グリフエディタでは正しく表示されているようにも見えますが内部の図形としてはうまくいっていません。中間制御点を少し上にずらすのがデザイン的には最適解だと思うので、もとの仓を調整するか新たな部品を作るしかないかと思います。--turgenev 2020年8月29日(土) 12:17
    • 中間の制御点と端点が接近しすぎるとこのような問題が起きやすいのは確かにそうだと思います。一方で5年前のzihai-123619@2ではこの問題は発生していなかった(が、エイリアス入れ替え後のzihai-123619@3では発生している)ので、この5年間でKAGEエンジンにバグが生じたと見ることもできる気がします。。。―twe 2020年8月29日(土) 15:31
    • 本件は、「KAGE engineの更新--kamichi 2020年7月19日(日) 12:00」でつなぎ目の半円を付けなくした副作用と認識しています(この変更の理由は、オプションで細身にした曲げストロークにおいて左撥ね部分がおかしくなるためです)。で、おっしゃる通り、そもそもは、骨組みの座標から内側に一定距離ずらして制御点を計算した結果、部品を小さくした場合に、制御点の逆転が起きるために生じていると思います。ですので、まずは一定距離ずらす計算の際に逆転が起きないように考慮する努力は必要かと思います。--kamichi 2020年8月29日(土) 16:16
    • そういうことだったのですね。失礼しました。--turgenev 2020年8月29日(土) 16:25
    • すみません、手を入れようと思ったのですが、これはturgenevさんがおっしゃるように、デザイン側で第2番目の座標を直すべきケースと判断しました。今まではたまたま座標が逆転しても「2:*:2」で切れ目に半円を重ねていたので問題が起きなかったのですが、今後は「2:*:0」となるので不具合部分がそのまま表示される結果になります。もともと「2:*:4」はあまりいろいろなケースを考えて設定されていない、という問題を引きずっています。いったん修正をあきらめます。--kamichi 2020年9月1日(火) 15:48
      • 「2:*:4」から「6:*:4」に修正してみました。--kamichi 2020年9月1日(火) 16:07
      • 左撥ねの設計を修正する必要があるかもしれませんね…。--kamichi 2020年9月1日(火) 16:15

  • 他言語は HTTPS が使えません。(SSL_ERROR_BAD_CERT_DOMAIN、HTTPSは glyphwiki.org, www.glyphwiki.org にのみ有効)sz 2020年6月15日(月) 10:35
    • もともと要望がなかったので無印のみ証明書を取っています。個人的にはHTTPS化は興味がないのですが、必要でしょうか。--kamichi 2020年6月15日(月) 13:06
    • 全語種でHTTPSに対応いたしました。--kamichi 2020年8月23日(日) 15:29

  • u3ca9-jvなどの一部グリフでsvgが白紙となり,それを引用したフォントもそのグリフが空グリフとなるようです。グループ:spinda-kkmr_第4明朝@6で空グリフとなっているコード位置は同様のバグが起こっていると思われます。--spinda-kkmr 2020年5月6日(水) 18:51
    • 状況確認しました。ご指摘ありがとうございます。原因は未調査です。その前に大事なことに気が付いてしまったので、先にそちらを修正し、そのあと取り掛かります。少々お時間いただきます。--kamichi 2020年5月7日(木) 01:19
    • 原因の特定はスキップ(おそらく高負荷で生成失敗)し、全グリフについて、再生成しました。もうすぐ処理が終わります。--kamichi 2020年5月8日(金) 23:02

  • 4月24日2時のdump.tar.gzから、dump_all_versions.txtとdump_newest_only.txtが空ファイルになってしまっているようです。— twe 2020年4月26日(日) 22:34
    • 状況確認しました。ご指摘ありがとうございます。原因は分かっているのですが、復旧ができません。別の方法で復旧に取り掛かります。少々お時間いただきます。--kamichi 2020年5月7日(木) 01:19
    • 本日復旧しました。外部ミラーもこれから解消していきます。ご迷惑をおかけいたしました。--kamichi 2020年8月17日(月) 16:15

  • バグとまでは言えませんが、kage.jsの95~97行目の
  • var temp = this.getEachStrokes(buhin);
    var result = new Array();
    var box = this.getBox(buhin);
    において、95, 97行目で同じストロークデータの取得を2回行ってしまっているため、データベースアクセスを伴う部品検索が必要以上に行われています。(再帰的にこれが起こった場合、必要の3倍以上のアクセスが発生する場合があることを確認しました。)getBoxにtempを渡すようにすれば容易に修正できるので、パフォーマンス改善の必要があればご検討ください。--turgenev 2020年4月17日(金) 14:00
    • ありがとうございます。これを富豪的プログラミングと言ったら怒られそうですが、たしかに無駄であることを確認しました。少し話がずれますが、いまのサーバではjsのインタプリタとしてSpiderMonkeyを使っているのですが、次期サーバはnode.jsに切り替えます。かなり高速化されるのですが、もしかしたらこの辺りをインタプリタ側で解消しているかもしれません。--kamichi 2020年4月17日(金) 17:19
    • やっと手を付けました。修正しました。--kamichi 2020年8月27日(木) 17:33

  • 現バージョンと同じKAGEデータで、関連字を変えてグリフ登録すると、レコードは増えないが、現レコードの関連字を書き換えられてしまう?また最新(バージョン指定なし)pngが消滅(バージョン-1にリンクを張られて非存在)--kamichi 2020年3月24日(火) 11:01
    • irg2015-05416において発生しなかったことから、修正済みであるか、さもなくば勘違いだと思われます。--kesuuko 2020年3月24日(火) 13:43

  • kagecd.jsの現在のgithubでの最新バージョンにおいて、水平でないストロークのウロコを描画するコードである1032行目の
  • poly.push(x2 - Math.cos(rad) * kage.kAdjustUrokoX[opt2] / 2 + Math.sin(rad) * kage.kAdjustUrokoX[opt2] / 2, y2 - Math.sin(rad) * kage.kAdjustUrokoY[opt2] - Math.cos(rad) * kage.kAdjustUrokoY[opt2]);
    は、正しくは(水平時のソースコードから回転行列を使うと)
    poly.push(x2 - Math.cos(rad) * kage.kAdjustUrokoX[opt2] / 2 + Math.sin(rad) * kage.kAdjustUrokoY[opt2], y2 - Math.sin(rad) * kage.kAdjustUrokoX[opt2] / 2 - Math.cos(rad) * kage.kAdjustUrokoY[opt2]);
    になると思います。この箇所が実際に動作する(漢字データに該当ストロークが出現する)ことは少ないと思いますが、一応報告しておきます。--turgenev 2020年3月23日(月) 20:02
    • 形状がどのように適切でないかは、グリフエディタ上でかなり短めの直線(頭も尾も"開放"に指定)を水平から徐々に傾けていくと確認できます。--turgenev 2020年3月23日(月) 21:51
    • 同ファイル1131~1137行目にかけて、おそらく0.6であるべきところが0.8になっているような気がするのですが、これは意図的なものでしょうか。折れ(番号3)および乙線(番号4)において上ハネを指定した時に動作する部分ですが、これだとわずかに水平でなくなった途端先端の丸が大きくなってしまうことになります。前述のウロコのものと合わせて状況がわかりやすいデータを添付したのでご覧ください。turgenev_test5--turgenev 2020年3月24日(火) 16:15
  • いろいろありがとうございます。それで現在かなり忙しい状態で、昔のことを思い出す余裕がありません。意図があったとは思うのですが、原則論で修正候補にしてよいと思います。ほかにも別途場所を設けて議論したいところなのですが、4月に入ってから余裕が出てくればありがたい、という状況です。--kamichi 2020年3月24日(火) 22:03

  • 「文字コード関連情報」がExt.Gや一部の(U+F900〜U+F9FFおよびU+2F800〜U+2FA1D)互換漢字に対して出ない。また「文字コード関連情報」のソース情報が古い。--kesuuko 2020年3月18日(水) 22:58

  • 異体字データの生成において、先頭のデータだけがなぜか反映されないという不具合が起きる。タイトルがないとダメな模様(1行目を無視?)--kamichi 2020年2月23日(日) 11:55

  • u0e3a@12が白抜けする。位置を少し動かしても改善しません。--kesuuko 2019年3月15日(金) 21:22
    • どの段階で白抜けするでしょうか。pngやsvgは白抜けしていない気がするので、フォントが、でしょうか。--kamichi 2019年6月8日(土) 13:39

  • 半角のグリフを異体字セレクタを使用してフォントに入れようとすると全角になってしまう。(グループ:kesuuko_sandbox@34)

  • グループ:ExtG-final-part1のフォントが正常に生成されません。U+30000〜U+DFFFF(?)がフォントにできないようです。--kesuuko 2018年2月5日(月) 00:03
    • 仕様ですが、第3面については開放を検討します。ご指摘ありがとうございます。--kamichi 2018年2月12日(月) 14:55
      • ExtGの漢字の作成が完了したので、第3面(TIP)を解放しても良いと思います。(ところで、ExtGの漢字は花園明朝のAとBどちらに入れられる予定なのでしょうか。)
      • 署名忘れ失礼しました。訂正が大きく遅れ申し訳ございません。--kesuuko 2018年11月22日(木) 00:12
  • (インデント戾る)フォント生成では、 u30729(unstable-u30729) のようにするとフォントに追加されませんが、 𰜩(unstable-u30729) とするとフォントに追加されます。 u30729(unstable-u30729) のようにしてもフォントに追加されるようにしても良いと思います。--kesuuko 2018年12月15日(土) 22:58

  • uXXXX-24の関連字の初期値が〓になっている(他の偏化変形はuXXXXが自動セットされている) --pyrite 2017年3月19日(日) 15:36

  • WebFont(グループ:umbreon126_test-font)を利用してみたが(Firefox+Chrome+Microsoft Edgeでは)書字方向が縦書きだと字の位置がおかしくなる(実例 )--sz 2017年2月27日(月) 19:15

  • バージョン付きのグリフを登録できない?(それは仕様?)指摘内容の確認から。--kamichi 2016年12月10日(土) 16:00

  • extf-02414@1extf-06495@1が一時的に「最近更新したページ」で赤い×印になっていました。いったん白紙化してその後復旧したところ@1が遡って正常化しました。--spinda-kkmr 2016年8月3日(水) 19:32
  • ご指摘ありがとうございます。KAGEデータに問題がない場合の「赤い×」は投稿時のサーバ負荷が高く、タイムアウトした結果、最後まで登録作業ができなかったものと推測します。現状でデータ投稿時の負荷が非常に高いので(いままで閲覧時の負荷低下にしか注力してこなかったため)どうにかしないといけないとは認識しています。--kamichi 2016年8月3日(水) 21:38

  • 1字フォントでグリフの右に余計な隙間ができる。グループページでは問題なし。両者の生成過程を比較して修正すべき。aj1-14027はNG、u90a6-itaiji-001はOK、u90a6-ue0105はNG。ユーザーより指摘あり(ありがとうございました)。--kamichi 2016年8月2日(火) 14:08

  • sandbox@2559は「u6bcc-h」のデータですが,専用エディタでは右下H/Tがおかしな方向に飛んでしまいます。 --ziyang 2016年7月17日(日) 22:30
    • 専用エディタの生成ファイルを捜索中…。いい加減HTML5にしなくては…--kamichi 2016年8月2日(火) 14:10

  • 以前solidblockさんに指摘された、中国語でのglyphwikiシステムから送信されるメールの文字化けの修正が必要。そもそも送信メールの文字コードをiso-2022-jpにしているので、そろそろutf-8に変更すべきか。--kamichi 2016年7月16日(土) 11:04

  • プロクシを使わないと投稿できませんになりました。--umbreon126 2016年5月27日(金) 07:45
    • データを調整しました。たぶん今は投稿できるようになっていると思います。確認をお願いします。--kamichi 2016年5月27日(金) 08:19
    • 投稿できます。迅速な対応に感謝します。--umbreon126 2016年5月27日(金) 10:24

  • RSSを更新したときの投稿者が利用していた言語でページprefixが記述される。仕様をどうするか。--kamichi 2016年3月11日(金) 00:06

  • ユーザー専有グリフ A のエイリアスグリフ B を作成し、「B が実体になるようにエイリアスを入れ替え」を行うと、B を変更することにより専有グリフである A を変更できるようになります。これはユーザー専有グリフの意義に反すると思います。―twe 2016年2月14日(日) 16:16

    • ご指摘ありがとうございます。頭がこんがらがっているのですが、エイリアス元が占有グリフの場合およびエイリアス先が占有グリフの場合の両方向について入れ替えできないように変更しました。逆は制限する必要がないでしょうか?そもそも占有グリフが既存グリフのエイリアスというのは珍しいかもしれませんが、そうした場合に、占有グリフ側をエイリアス元に変更できるようになります。たくさんエイアリスが張ってあった場合にそれを元に戻すのが手作業になってしまいます。これを防止する目的です。なお、まだ制限がかかる場合でも入れ替えのリンクは表示されます。後日表示させないように作業します。--kamichi 2016年2月15日(月) 00:23


  • グリフエディタでu5f1f-02を引用してストレッチの数値を 3 にすると、ストレッチしていない状態と同じグリフになってしまいます。―twe 2015年6月20日(土) 16:57
    • ご指摘ありがとうございます。確認しました。変ですね。調査します。--kamichi 2015年6月22日(月) 09:25


  • 専用エディタにて、「0:0:0:0」が含まれるグリフでストレッチ機能を使用すると、部品が消えるようです。
  • ※但し、編集ページで「99:215:10:###:###:###:###:uxxxx:0:5:5」の様に値を直接入力した場合は正常に動作します。
    (例)u809aにメタ情報でストレッチ境界を設定し、専用エディタでストレッチ境界を指定すると部品が消える。但し、編集ページで「99:190:0:###:###:###:###:u809a:0:-20:0」と入力した場合は正常に表示される。--kamiyo 2013年6月29日(土) 10:27


  • koseki-319460のストレッチ機能が使えない。1回編集してもう一度編集するとストレッチのパラメータがNaNになる--kamichi 2013年6月18日(火) 19:38
    • このバグは部品のストレッチ方向がUかDに指定されていると必ず発生するようですね… ―twe 2014年4月27日(日) 19:51
    • ご指摘ありがとうございます。--kamichi 2014年4月29日(火) 08:20

これよりも古い分はバグ報告-保存を参照してください。