GlyphWiki logo
navigation
help
search

toolbox
languages
articlediscussionedit this pagehistory

GlyphWiki:バグ報告-保存

From GlyphWiki, the free glyph database

このページは古くなった情報の退避用です。書き込みはご遠慮願います。2015年までに報告されたものについてはGlyphWiki:バグ報告-保存-2015年までをご覧ください。


2023年

【修正済】エイリアス実体変更による自動更新が自動編集として扱われない

グリフの自動編集のうち、「エイリアス実体変更による自動更新」が「最近更新したページ」において自動更新でないかのように扱われてしまっています。--kesuuko 05:53, 1 September 2023
  • ご指摘ありがとうございます。ファイル更新ミスがありましたので修正しました。--kamichi 2023年9月1日(金) 07:59
    • 本件の修正を確認しようとu29e7aを更新(u29e7a-jvのエイリアスに変更)しようとしたところ、Internal Server Errorが発生してしまいました。--kesuuko 08:06, 1 September 2023
    • すみません、チェックが不完全でした。修正しました。--kamichi 2023年9月1日(金) 08:44

(non title)

(non title)

(non title)

  • Talk:sat_g908553を私が編集した時に「他ユーザー占有グリフの編集」と誤判定されて「最近更新したページ」にデフォルトで表示されませんでした。ノートページはたとえ他ユーザーの占有グリフであっても書き込み可能な仕様であるはずなので,これはバグと思われます。--spinda-kkmr 2023年6月10日(土) 17:21

(non title)

(non title)

(non title)

  • 「古い部品を引用しているグリフの一括更新」が正常に機能していない。例えば,このページ から一括更新を試みても,何もなされずに古い部品を引用しているグリフの一覧ページ に戻ってしまいます。 --spinda-kkmr 2023年2月4日(土) 20:42
    • この件に関しては去年8月にも私やsayunuさんのところで発生しておりました。このページの少し下の方にありますが、「SPAM対策の誤検知」(kamichiさんより)とのことです。頻繁に編集を行った際に発生するイメージですが、そうでないときもある気がします。しばらく(1日ほど)待つか、kamichiさんに個別に連絡するといいようです。--turgenev 2023年2月5日(日) 09:32
  • サーバの負荷により対応不能、またはSPAM誤検知設定で改善したと見なし、いったん閉じます。--kamichi 2023年8月31日(木) 14:58

(non title)

  • u9fbb-g07@7は自動編集なのに、最近更新したページでは自動編集でないかのように扱われている。--kesuuko 00:45, 29 January 2023
    • 自動編集の判定方法を変更して解決したので閉じます。--kamichi 2023年8月31日(木) 14:58

2022年

  • SMPやTIPの文字に異体字セレクタをつけた文字をフォントに含めようとしてもフォントに反映されない(Group:kesuuko_sandbox7@18)。--kesuuko 22:57, 22 December 2022

  • フォント生成に何らかの不具合が起きているようです。過去にGlyphWikiで生成したフォントと昨日(2022/09/23)生成したGroup:spinda-kkmr_拡張H暫定を比較すると,後者のほうが下がって表示されてしまいます(参考 )。また,アプリケーションによってはフォントの上部が切れてしまいます(Excelで確認)。井戸端にて2021/06/09に報告されているものと同じ不具合かもしれません。
  • 2020/05/09に生成したGroup:spinda-kkmr_拡張G暫定は問題ないので,この間に何らかの不具合が発生したと考えられます。調査をお願いいたします。
  • 以上,--spinda-kkmr 2022年9月24日(土) 12:59
    • 本件、やや大ごとなので着手が遅れると思います。--kamichi 2022年9月25日(日) 12:26
    • 催促をするのは大変心苦しいのですが,早期のご対応をお願いいたします。せっかく登録されている拡張Hを活用出来ないのはグリフウィキにとって損失だと考えます。--spinda-kkmr 2023年1月2日(月) 16:57
    • 上記、恐れ入ります。1月下旬より着手します。--kamichi 2023年1月7日(土) 17:21
    • fontforgeで比較したところ、一部数値がおかしくなっていました。とりあえず、比較した部分が一致するように修正します。(近日中に…)--kamichi 2023年6月18日(日) 23:23
    • フォント生成のベースとなるベースフォントを更新しました。私の目的では不具合が解消している模様です。ひとまず様子見としますが、不具合残るようでしたらご指摘いただけると助かります。--kamichi 2023年6月21日(水) 21:16

  • 現在、手元で旧部品の一括更新が実行できない(Mustrenewのページにはいけるが実行ボタンを押すと https://glyphwiki.org/wiki/Special:Mustrenew に飛ばされる)状態になっています。私だけでしょうか。--turgenev 2022年8月7日(日) 22:22
    • 昨日試したら同様でしたが、今試したら正常に動作してるようです。 — sayunu 2022年8月9日(火) 00:03
    • 本件、詳細を公開できないのですが、SPAM対策の誤検知となります。支障がある場合には直接管理人までご連絡いただければと思います。--kamichi 2022年8月25日(木) 09:01

  • 説明リストのウィキ記法(dl・dt・dd になる奴)で、コロンを含むリンクを見出しにしたい時、そのコロンが記法の区切りと見なされてリンクが崩れます。例えば次のような…
 :[[sandbox]]:これはグリフ編集機能の練習や実験に使っていいグリフです。
 :[[Group:sandbox]]:これは記事編集機能の練習や実験に使っていいページです。
sandbox
これはグリフ編集機能の練習や実験に使っていいグリフです。
[[Group
sandbox]]:これは記事編集機能の練習や実験に使っていいページです。
  • リンクを見出しにする使い方は特殊ではないと思うし、望ましくは二重角括弧の中にあるコロンを別扱いした方がよさそうです。 — sayunu 2022年8月7日(日) 17:29
    • wiki文法処理部分は他者のスクリプトを使っていて、これからの手入れはなるべく避けたいため、仕様ということで記述を工夫していただく方向でお願いします。閉じます。--kamichi 2023年8月31日(木) 15:26

    • 先ほど↑の行をこのページに書き込んだのですが、「最近更新したページ」に表示されていないようです。--turgenev 2022年8月7日(日) 13:29
    • 「自動編集を表示」にしたら表示されました。どうやら要約の欄に"部品の一括更新"という文字列をそのまま書いたため自動編集と判定されたようです。他言語のメッセージで試しても同様のようです(今3回ほど試してみたので履歴をご確認ください)。私としてはとりあえずは一致する文字列を書かないよう気をつけますが、編集履歴を目立たなくするために悪用される恐れがありますので修正したほうがよいかと思います。--turgenev 2022年8月7日(日) 14:44
      • "自動編集と判定される文字列を手動で「要約」欄に書くと(自動編集を表示しない場合に)編集履歴に表示されなくなる"というこちらの不具合ですが、荒らしの発見が難しくなる恐れがあるためできるだけ早期の修正を重ねてお願いします。--turgenev 2022年8月24日(水) 19:10
      • こちらですが、対応は難しいです。というのは要約の記述内容に対して特定の語句があった場合に自動編集とみなしていますので、その語句を変更しても「荒らし」に対してはいたちごっこになるためです。下手に対策を行うとより復旧が面倒な方向に荒らし行為が変化することがこれまでの経験で得られているため、今後はいかに復旧を省力化するかに注力したいと思っています。後ろ向きな回答で大変申し訳ないのですが…--kamichi 2022年8月25日(木) 09:01
      • お忙しいところありがとうございます。確かに文字列を変更するだけでは意味がないのですが、私の意図としては、自動編集かどうかを表すユーザー編集不可能なパラメータを新設するということです。確かに復旧の省力化は大事ですが、復旧するにもまずは荒らしに早期に気づくことが必要で、それには多くのユーザーが「最近更新したページ」を頻繁に確認するしかないのではないかと思うのですが、どうでしょうか。多くの漢字で使われている部品に全く違うデータが書き込まれても数日にわたって誰も気付かない可能性があるというのは不安に感じます。とはいえ私は荒らしの形態にはそれほど詳しくないので、他ユーザーからの意見などもあればありがたいです。--turgenev 2022年8月26日(金) 14:52
      • 今後のことを考えるとグリフウィキのシステムにこれ以上の大掛かりな変更は望ましくないと思っています。その上で、一つのアイデアとして、自動編集の場合は要約の1文字目に「@」を付けることとし、一般投稿の要約で頭に@を付けた場合は自動的に除去することとし、最近更新したページの自動編集では「@」を付けたものを表示非表示の対象とする、という方法はいかがでしょうか。副作用として切り替え前の自動更新はすべて「非」自動更新と解釈される(あるいはデータベース上のidを見て新旧機能を切り替えることも検討します)ことになります。ASCIIの文字で当たり障りのない記号として「@」を考えましたが、記号の選定も含め、いかがでしょうか。--kamichi 2022年9月2日(金) 10:34
      • 「@1にリバート」が記述できなくなるので、別の文字にします。ウーム。--kamichi 2022年9月2日(金) 10:45
      • 上段が過去の全summaryの使用文字、下段がASCIIです。--kamichi 2022年9月2日(金) 10:59
 !"#  &'( *+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\  _ abcdefghijklmnopqrstuvwxyz   ~
 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
      • 先頭に0x20を書けない(自動カット)ようにして、0x20で区別すれば見た目の差異が少なくて良いかもしれません。現状で先頭が0x20のものが96レコードあるので、強制的に書き換える必要がありますが。--kamichi 2022年9月2日(金) 10:59
      • それはとても良いと思います。0x20にすることについても賛成です。--turgenev 2022年9月2日(金) 11:52
      • やっと対応完了しました。--kamichi 2023年8月31日(木) 14:40

  • 「部品の一括更新」(Renewallのほうです)(旧部品の一括更新(Mustrenew)にもあるかもしれませんが、未確認です)に漏れがあるということはありませんか?今日(2022/8/7)の9:31~と9:46~の2回、全く同じグリフ集合https://glyphwiki.org/wiki/Special:Renewall?view=listup&target=u5165-03 の1ページ目)に対して全グリフにチェックを入れてほぼ同じ操作(部品のサイズを変更しようと思い、1回目は"u5165-03,type1,0,-2,0,0"、2回目は"u5165-03,type1,0,1,0,0"を入力)を行ったのですが、例えばcbeta-04384は一回目しか更新されておらず、u204f2-jvは二回目しか更新されておらず、u2d1b9-jvは(該当のRenewallページには含まれているが)一度も更新されていないようです。
  • 操作としてはu5165-03を引用している全グリフ(の8/7 7:00頃時点のデータ)に対してRenewallで"u5165-03,type1,0,-1,0,0"をした状態にしたかったという感じです。もしこれが仮にバグだった場合、そのようにしていただけるとありがたいです。(ただ、たかが2ピクセル以内の移動なので、無視でもいい気はしますが) 勘違いや操作上のミスなどがあったらすみません。
    • turgenev 2022年8月7日(日) 10:33
    • 一つ確認をお願いしますが、状況は「処理されるグリフと処理されないグリフが生じる」の2つでしょうか。それとも「正しく処理されるグリフと誤って処理されるグリフが生じる」の2つでしょうか。前者の場合、プロセスが途中で止まった、という可能性もありそうですが、操作後のWebページは完了の表示(たしか更新対象のグリフが並びますよね)になるということでしょうか。--kamichi 2022年8月7日(日) 10:39
    • 前者(「処理されるグリフと処理されないグリフが生じる」)です。誤った処理には今のところ遭遇していません。量が多いので操作後のWebページが表示される前にエラーになってしまうのですが、それでも正しく更新は行われるとの記載があったのとMustrenewでは実際に全てできているような気がしていたため問題視はしていませんでした。--turgenev 2022年8月7日(日) 10:55
      • この不具合に関してですが、部品は同じで位置や大きさのみ変更したいような時には、一時的な作業用グリフを作成し、一旦全てのグリフがそちらを使用するように部品更新を行ったあと、改めて元の部品を使用するように一括更新を行えば、不具合があったとしても漏れなく更新できることに気づきました。--turgenev 2022年10月4日(火) 09:51
  • 関係あるか分かりませんが、最近「旧部品の一括更新」を使った時、チェックを入れたグリフ一覧の最後まで走らない事が多かったです。完了画面が出ないのは既知なのでいいとして、「最近更新したページ」で処理の進み具合を観察すると途中で終わっていました。時間を置いて一括更新画面を再び開くと、さっきチェックを入れた筈のグリフが未更新で再びリストアップされる。「一部抜ける」とかではなく「後半に辿り着かない」という感じでした。 — sayunu 2022年8月7日(日) 11:53
    • 私も最近よくMustrenewを利用していますが、確かにこちらの現象もある気がします。Renewallの件に関しては例えばcbeta-04384はかなり最初のほうに表示されているグリフなのでやや様子が違いそうですね。--turgenev 2022年8月7日(日) 12:22
      • ここまで、サーバ負荷にも関係すると対応不能なため、いったん閉じます。--kamichi 2023年8月31日(木) 15:26

  • こんにちは。Group:cp2021_字喃字典フォントのフォントを生成してみたら、出来なくて、一時間後、次のメッセージが出てきました:「フォント生成に失敗しました(念のためページを再読み込みしてください)。」色んな組合せで字を載せてみたが、結果は同じでした。解決方法を探していますが、生成ログで「Prepare glyph data.」に止まってエラーの情報など書いてありません。--cp2021 2022年7月28日(木)
    • 現時点でGroup:cp2021_字喃字典フォントGroup:cp2021_字喃字典フォント1が循環参照(お互いがお互いを参照している)になっているので記述として不適切です。片方のリンクを外すとどうなるでしょうか。--kamichi 2022年7月29日(金) 08:40
    • リンクは一方だけだったけどそのリンクを外してもGroup:cp2021_字喃字典フォントのフォントが生成できません。前と同じ、ログでは「Prepare glyph data.」に止まります。おそらく、問題はGroup:cp2021_字喃字典フォントにあると思いますけど見つかりません。--cp2021 2022年8月1日(月)
    • 原因が(おそらく)分かりました。7/28にSPAMユーザーによる投稿(あるいは操作)により、自己循環グリフが生成され、それをフォントに含めようとするとストロークデータ生成で自己循環により処理が終わらなくなってしまうためと判断しました。原因となるグリフは修正済みです。ストロークデータ生成における自己循環防止の修正を検討します。またグリフ登録時の自己循環拒絶の修正も検討します。--kamichi 2022年8月2日(火) 14:10
    • フォントを作ってみたら出来ました。ありがとう^^。--cp2021 2022年8月2日(火)

  • こんにちは。これはバグか、どこかの制限にぶつかってしまったか、よく分からないけど、フォントを作るための占有グループページに字を加えられなくなってきたのです。
  • グループのページはGroup:cp2021_字喃字典フォントで、最後のところを見れば「…」で字のリストが切られていて、その後になにも追加できません。 HTMLのコードで文字制限があるかなと思って、元の完全のリストを一行にしてみたら全部の字が表れたけど、一行に一つの字じゃないとフォントが作られませんよね。できれば、全部の字を一つのページでおさめたいから解決方法があれば教えてください。よろしくお願いいたします。 --cp2021 2022年6月9日(木)
    • どこかに書いてあるはずなのですが、ドキュメントは10万字、グリフは1000行(ストローク)が最大値となっています。その上でお尋ねの件は、グループページを引用する形で分割記述すれば可能です。グループ:cp2021_字喃字典フォント1,2,3…を作り、グループ:cp2021_字喃字典フォントにおいてそれらのページへのリンクを張る形です。GlyphWiki:フォント生成の「グリフの記述」の「他のグリフ集合 グループ:(グループ名) のインポート」をご覧ください。--kamichi 2022年6月18日(土) 08:13
    • そういう機能があって助かります、今度試してみます。二つ以上のページになりますけど、今まで二つのフォントファイルを作ってFontForgeでmergeしていたから、似た過程ですね。返事ありがとうございます。--cp2021 2022年6月19日(日)21:07

2021年

  • 非常に高い頻度でInternal Server Errorが発生します。hondono 2021年10月1日(金) 17:23
    • GlyphWiki:お知らせにあるようにバグではなく、対外的な問題です。また利用者は使用言語登録をお願いしています。これもGlyphWiki:お知らせにあります。
      • 上記のkamichiさんの返答以降、同エラーが発生していないことを確認しました。対処ありがとうございます。
      • エラーが発生するのならお知らせくださいというGlyphWiki:お知らせの記載通りに報告したのですが、今後はどちらで報告するべきでしょうか。hondono 2021年10月4日(月) 11:47
      • 説明不足で失礼しました。お知らせの当該記事の直下でお願いします。これから補足します。また、使用言語登録についてもご協力ありがとうございます。--kamichi 2021年10月4日(月) 13:08

  • GlyphWiki:関連付けるべき符号位置-入管別表第四の二の「その1〜その3」の内容が反映されていません。--kesuuko 14:30, 22 September 2021
    • バッチ処理の関連ファイルを確認しましたが、問題はないような気がします。具体的に反映されていないデータを1つあげていただけないでしょうか。--kamichi 2021年9月25日(土) 19:45
      • いつの間にやら治っていたようです。迷惑をおかけし申し訳ございません。--kesuuko 20:26, 25 September 2021
      • もしかするとこのところの高負荷の影響だったのかもしれません。とりあえず解消・様子見といたします。--kamichi 2021年9月25日(土) 20:45

  • グリフの赤×化が再発しているようです。--spinda-kkmr 2021年9月18日(土) 12:01
    • ご指摘ありがとうございます。Webサービスを再起動しました。それで、どうも想定をはるかに超えるWebアクセスが頻発し、その後遺症の模様です。そのアクセスはまだ全体を把握できていませんが、一つはGoogleBot、一つは https://zi-hi.com/ からの模様です(どうも前者はAgentを偽装している模様。後者は多いが前者の比ではない)。 制限するのではなく、うまく解消できる方向で対応できないかこれから取り組みます。--kamichi 2021年9月18日(土) 17:43

  • 多数のグリフが赤い×印となって正常に表示できません。1つ下のバグの再発かも知れません。--spinda-kkmr 2021年9月10日(金) 16:56
    • ご指摘ありがとうございます。確認しました。ちょっと原因究明する余裕がなかったので、まずは再起動して解消したと思われます。改めて状況を確認します。--kamichi 2021年9月10日(金) 18:30

  • 多くのグリフ(既存のものを含む)が赤い×印になってしまっている。--kesuuko 07:01, 7 August 2021

2020年

  • 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

  • 白抜きグリフの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
      • 閉じます。--kamichi 2023年8月31日(木) 15:10

  • 他言語は 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が白紙となり,それを引用したフォントもそのグリフが空グリフとなるようです。Group: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

年数未分類(新しい順)

  • GlyphWikiのページの大半が重くなってしまっている。--kesuuko 2020年3月30日(月) 15:16
    • ご迷惑をおかけしています。状況確認していますが原因不明なため様子見です。--kamichi 2020年3月30日(月) 17:40
    • サーバを更新したため、いったん取消とさせていただきます。--kamichi 2020年8月17日(月) 16:56

  • gfz-fba7(u29f7c-gと等価)に投稿できない。スパム対策が暴発しているものと思われる。--kesuuko 2020年2月21日(金) 19:33
    • 調整しました。--kamichi 2020年2月22日(土) 11:21

  • グリフを登録するボタンをクリックしても編集画面になります。どうすればよいですか。--yushin 2019年11月13日 03:05
    • ご指摘ありがとうございます。当該症状はバグではなく、何かしらの条件により投稿を受け付けない状況と思います。詳細は管理上お知らせすることができません。なお、投稿データとグリフ名を管理者までメールで直接お問い合わせいただければ、対応ができるかもしれません。--kamichi 2019年11月13日(水) 13:55

  • 近い頃、日本語版しか訪問できない状態になりました。ネームサーバの書き換えに関わるなのでしょうか?--simons 2019年7月15日(月) 03:12
    • ご指摘ありがとうございます。DNSの設定を間違えていました。今修正しましたので、しばらくすると回復すると思います。申し訳ありませんでした。--kamichi 2019年7月15日(月) 09:31

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

  • u2a09b-jv@1を復帰させようとしてもプレビュー扱いになってしまう。--kesuuko 2019年1月12日(土) 20:02
    • 解決済みと思いますが、@1の生成時に負荷が原因と思われる生成不具合が発生してグリフ画像が生成されませんでした。同じデータでは再登録できず、プレビュー画面に戻ります。ですので@2で白紙化された方法で一旦データを消し、再登録していただくことになります。ご了承ください。@1はこちらで再生成いたしました。--kamichi 2019年6月8日(土) 10:36
      • 正常に生成されなかったのは当時u82aa-jか作成されていなかった為と思われます。--kesuuko 2019年6月8日(土) 13:29
      • なるほど。負荷ではなく部品無しでしたか。了解です。--kamichi 2019年6月8日(土) 13:37

  • Group:kesuuko_二条明朝A@1で正常にフォント生成ができない。--kesuuko 2018年7月19日(木) 00:19
    • 仕様です。ログファイルを見てください。グリフ数が上限の65536個を超えているようです。それと、フォント名の英語はASCIIに閉じないとうまく設定されないのではないかと思います。--kamichi 2018年7月19日(木) 07:54
      • Group:kesuuko_二条明朝A@1の収録グリフの大半は花園明朝と同じなので、次期更新の花園明朝の文字数が心配です。--kesuuko 2018年7月22日(日) 01:48

  • u9febu9fefが関連字に設定できません。--kesuuko 2018年6月6日(水) 22:01
    • バグとは思っていませんが、とにかくUnicode11.0公開に合わせて漢字のコードポイントを広げました。--kamichi 2018年6月7日(木) 13:18

  • 半角グリフが正常に半角グリフにならない(Group:spinda-kkmr_test0@41)。Group:HalfwidthGlyphsが分割されたことが影響している可能性があります。--spinda-kkmr 2018年6月5日(火) 18:45
    • 失礼しました。単純ミスでまったく反映されていませんでした。修正しました。--kamichi 2018年6月5日(火) 22:04

  • 部品が組み合わさっている字(何でもいいですが、例えば「潟」)で「選択部品を分解」をすると、僅かに(しかも不規則に?)位置がずれます。分解をしたあとにCtrl+Zなどを押してみれば確認できると思います。turgenev 2018年2月26日(月) 14:18
    • 参考までに、u6f5fの分解前と分解後のsvgのリンクを貼っておきます。ブラウザのタブを切り替えて違いをご覧ください。http://glyphwiki.org/glyph/u6f5f.svg (before) https://glyphwiki.org/glyph/turgenev_decomposed.svg (after)--turgenev 2018年2月26日(月) 14:42
    • 自己解決しました。点の位置が整数でしか表せないことによる丸め誤差だと思われます。小数に対応するとデザインおよびサーバーの負荷が大きいという事ならやむを得ませんね。--turgenev 2018年3月1日(木) 09:11

  • u5e2d@4をエディタ上で表示すると,u5dfe-04@6が表示されず透明になります(厳密には透明な部品となる)。sandbox@3195のようになります。なお,異常なのはエディタ上だけで,グリフは正しく表示されます。--spinda-kkmr 2018年2月11日(日) 10:56
    • 他のグリフでも確認しました。おそらく最新版ではないグリフ(@#,@##が後ろにつくグリフ)が正常に表示できていないものと思われます。--spinda-kkmr 2018年2月12日(月) 14:06
    • 失礼しました。別件でいじっていたことの副作用でした。修正し、復旧しました。ご指摘ありがとうございます。--kamichi 2018年2月12日(月) 14:55

  • GlyphWiki:関連付けるべき符号位置の繁簡関係の内、下三行が正常に機能しません。いっそu9fffまで漢字扱いして良いと思うのですが。--kesuuko 2018年1月2日(火) 02:47
    • 下3行も表示できていると思います。もう一度ご確認ください。漢字扱いのコードポイントについては、あくまでも個別修正(拡張)とします。ご理解ください。--kamichi 2018年1月9日(火) 12:04

  • 花園フォントのバグ報告はどこにすればよいのでしょうか。絵文字関連でIVSを使うと、「VS15」などの文字が出てしまいます。--schwei2 2017年11月23日(木) 21:50
    • ドキュメントに連絡先が書いてあると思います。ここは不適切ですのでご遠慮願います。--kamichi 2017年11月23日(木) 22:46
    • あるいは実質的にGroup-talk:花園フォントでもよいかと。--kamichi 2017年11月23日(木) 22:47

  • バーベイタム機能が機能しない
  • バーベイタム機能が正常に機能しません。Group:kesuuko_shoukeimoji@1のようになってしまいます。
    • 正常に機能しているようですGroup:sandbox。ご確認ください。--kamichi 2017年11月7日(火) 22:01

  • sim-ch_kp-lm1を編集する際、若し「選択部品を分解」を押せば、左側のㄹの一部は消失しますよー!そして「編集終了」というキーを押して、グリフは空白になりました。そんな不思議なバッグが発生した原因を見つけて下さいませ。どうも有難う。 --sim-ch 平成29年10月17日(火) 20:57
    • 見落としていました。ご指摘ありがとうございます。部品エディタは42画(?)以上のデータを保持できないため、細かい筆画を組み合わせた部品を分解するとデータが飛んでしまいます。その結果(?)データに矛盾が発生したのかもしれなく、それで真っ白になった可能性があります。これはエディタの仕様です。次のバージョンのエディタでは改善します。--kamichi 2017年11月27日(月) 11:22
    • 今日私は再度試しました。42ではなく32です。wiriamu_cho-jj1は33画であって、その問題が出しました。 --井利阿牟(User:wiriamu) 平成30年3月18日(日) 17:08

  • sandbox@3009、エディターでは部品の位置をいじるだけで形がちょっとくずれる。sz 2017年10月13日(金) 13:22
    • 副曲線の切断面と本体の接続に問題があることを確認しました。ご指摘ありがとうございます。--kamichi 2017年10月17日(火) 08:50
      • この問題は2017年8月28日のエンジン修正で解消しているはずです(グリフエディタのKAGEエンジンが更新されていないため、エディタ上ではこの問題が生じていますが、グリフの生成やフォント生成には支障がないはずです)。部品の位置によってポリゴンが壊れたり壊れなかったりするのは誤差によるものと思われます。―twe 2017年10月18日(水) 00:57

  • IDSエディタのIDCボタンと分解・結合・変換・逆変ボタン全てが機能しなくなっているようです。https化の影響かもしれません。--spinda-kkmr 2017年4月2日(日) 16:25
    • ご指摘ありがとうございました。jqueryのファイルをローカルに置いてhttp,httpsを固定しないように修正しました。--kamichi 2017年4月2日(日) 19:43

  • IDSエディタにて,「⿸广K」を変換したところ,u2ff8-u5e7f-u004bとなるべきところが,“u2ff8-u5e7f-u4b”となりました。--spinda-kkmr 2016年11月27日(日) 14:14
    • ご指摘ありがとうございました。修正しました。--kamichi 2016年12月4日(日) 10:39
  • 対応ありがとうございます。しかし,今度はIDCボタンと分解・結合ボタンが機能しなくなっているようです(押しても入力できません)。変換・逆変は機能するようです。以前は正常にできたので修正時に予期せぬバグが入り込んだ可能性があります。--spinda-kkmr 2016年12月4日(日) 11:27
    • ご指摘ありがとうございました。内部で利用しているライブラリが公開停止になっていましたのでコピーをローカルに置きました。--kamichi 2016年12月4日(日) 12:04

  • the following links in 文字コード関連情報 are dead.. farter 2016年9月28日(水) 14:15
    • chise_linkmap (説明 )
    • IPSJ-TS 0008:2007 (説明 )
      • サービス元の提供が停止となりました。次回更新時に表示を停止します。--kamichi 2016年10月17日(月) 09:52
      • 更新しました。--kamichi 2016年10月17日(月) 10:26

  • 存在しないグリフのページタイトルの漢字が正しく表示していません 。--umbreon126 2016年9月25日(日) 20:51
      • 調査します。ご指摘ありがとうございます。--kamichi 2016年10月17日(月) 09:52
      • 未存在グリフの場合は表示すべきでないと判断し、修正しました。--kamichi 2016年10月17日(月) 10:22

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

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

  • プロクシを使わないと投稿できませんになりました。--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
    • 正直なところRSSのニーズは低いと思われるため、このままとして閉じます。--kamichi 2023年8月31日(木) 15:50

Cannot Edit glyphs with alias

  • Cannot Edit u9593, it shows 500 Internal Server Error. This happens with glyph with multiple alias. To succeed, one needs to remove all alias glyph, update glyph, then add back the alias.
    For reference, I want to adjust it to re-use components:
    99:0:0:0:0:200:200:u9580-05:0:0:0
    99:0:0:50:92:150:172:u65e5:0:0:0
    -- chanhenryfaihang 2016年1月18日(月) 18:09

  • これは井戸端でも話題になった、いたずらによるサーバ高負荷によるものと思いますので、現在は編集できると思います。--kamichi 2016年1月20日(水) 18:16

  • It still does not work... hkcs 03:47, 21 January 2016

  • ???私の理解では(1)u9593のページを開いて、(2)「編集」タブを押して、(3)「エディタ」を起動する…の一連の作業は問題なくできていますが、(2)ができないということでしょうか?--kamichi 2016年1月21日(木) 09:49
    • 別件で修正した、日英語版以外ではグリフエディタの部品検索が使えなかった機能とは関係ないですよね?--kamichi 2016年1月21日(木) 10:10

  • 問題は「編集の投稿が失敗します」と思います。--umbreon126 2016年1月21日(木) 11:15

    • ちょっと時間がかかった気がしてアレ?と思いましたが、編集できますね。chanhenryfaihangさんの書かれた「multiple alias」の解釈が不明です。グリフウィキはエイリアスのエイリアスはできないので、どのことを指しているでしょう。--kamichi 2016年1月21日(木) 11:22

      • "a glyph with multiple aliases"は「多数のエイリアスのあるグリフ」という意味と思います。--umbreon126 2016年1月21日(木) 11:42

      • 現在このバグに相当するグリフを挙げていただけないでしょうか。手元で再現できておりません。--kamichi 2016年1月22日(金) 07:55

  • cannot work with u8cab... suggest change to:
    99:0:0:0:0:200:200:u6bcc-03
  • 99:0:0:0:17:200:197:u8c9d-04
    hkcs 00:09, 23 January 2016

  • 編集して変更できましたよ。「何ができない」のかを説明していただけませんか。--kamichi 2016年1月23日(土) 00:39

  • 推測ですが、英語版のエイリアス実体の変更に伴う自動更新メッセージの文字列の中の ' をエスケープしていないのが関係あるかもしれません。 ―twe 2016年1月23日(土) 14:44
    • まさにおっしゃるとおりでした。ご指摘ありがとうございました。--kamichi 2016年1月23日(土) 15:11

  • ということで、修正しました。大変失礼しました。--kamichi 2016年1月23日(土) 15:14