グリフウィキでのページエラーや挙動がおかしいところなどがありましたら是非ご報告願います。なお、ソフトウェアの改変状況はシステム変更記録に載せていきます。
記述は、新しい項目を上にして、項目ごとに1行空行を入れ、見出しを立ててください。(見出し冒頭の凡例…(【】未記述):未着手、問題再発生 【修正済】:管理者により修正済 【様子見】:対応を見送り、当面様子見とします)
また、機能の追加などに関する要望は、ソフトウェアへの要望にてお願いします。ネットワークの不具合と思われる場合など、サイトのサービス不全についてはお知らせにて連絡願います。
アーカイブしたものはバグ報告-保存を参照してください。
おまかせ表示がメインページに飛ぶようになっている
上記の様になっています。修正を希望します。--
shien-donkama2000 00:08, 26 April 2024
一部の異体字関係が消滅している
現在、一部の異体字関係(向きの概念があるもの?)が消滅しているようです。修正をお願いします。--
kesuuko 01:33, 12 April 2024
- お知らせありがとうございます。サンプルとなるものがあればお知らせください。よろしくお願いします。--kamichi 2024年4月12日(金) 09:59
【解消済】他のユーザーの会話ページに投稿ができない
先程、
用户-对话:kamiyoに投稿をしようとしたのですが、投稿が正常に行えないようです。(投稿しようとした内容は、「叶典を典拠とする異体字関係のうち、正字が簡体字であるものは繁体字に直して登録してほしい」というものです)--
kesuuko 16:55, 23 March 2024
-kamiyo様。GlyphWiki:異体字にも記載のある通り、叶典を典拠とする異体字関係のうち、正字が簡体字であるものは繁体字に直して登録してください(当該規則は私が追加したものですが、繁体字に直したほうが検索しやすいと思います)。--kesuuko 17:16, 23 March 2024
- なお、「他のユーザーの」としていますが、kamiyoさん以外のユーザーの会話ページに投稿ができるかは確認していません。この名称は、特定のユーザーを名指しした見出しを立てるのは問題があると判断したためのものです。--kesuuko 17:16, 23 March 2024
- 詳細は伏せますが、ページ内にNGワードが含まれていたため編集ロックされていました。解消させました。--kamichi 2024年3月24日(日) 16:46
【解消済】英語版GlyphWikiで、「View more results」が正常に機能しない
2020年にkamiyoさんが指摘した「これ以降の検索結果を見る」に関するバグについて、英語版および中国語版において未修正のようです。対応をお願いします。--
kesuuko 08:56, 19 January 2024
- システムではなく翻訳データのミスでした。修正しました。--kamichi 2024年3月24日(日) 17:38
【様子見】たまにGlyphWikiののサーバーにアクセスできなくなる
ここ数日、GlyphWikiにアクセスしようとするとたまに「サーバーの応答が停止しています」と出てページが表示されないことがあるようです。--
kesuuko 11:02, 9 November 2023
- おそらくSPAMユーザーによるものと思われるため、様子見とします。--kamichi 2024年2月11日(日) 18:01
【修正済】一部UCSソースに関連字が自動入力されない
UnicodeのSソースやKPソースのグリフを作成する際、関連字がデフォルトで入力されません。--
kesuuko 10:26, 23 September 2023
- 修正しました。--kamichi 2024年2月11日(日) 17:59
2021年
- 自分所有のユーザー専用グリフのあいだのエイリアス交換ができません。--jjanggu2021.09.11 16:19
- まだチェックしていないのですが、これはニーズとして必要でしょうか。ちなみにユーザー占有グリフ同士だけができないのか、片方でもユーザー占有だとできないのか、どちらか判明していれば教えて欲しいです。--kamichi 2021年9月25日(土) 19:48
- 失礼しました。交換対象は双方ともユーザー占有グリフで自分所有です。--jjanggu2021年9月25日(土) 20:17
- u5317-h01のpng画像で、2画目が何故か3画目の下に飛び出ているかのように表示される。--kesuuko 2021年2月11日(木) 23:27
- これに関してですが、PNGの2値化に使っているソフトウェアが原因かと思い、手元でimagemagickを使ってmagick convert u5317-h01.svg -monochrome test.pngのように生成してみたところ、この症状は出ませんでした(svgのサイズが200x200なのでpngも200x200になります)。こちら( https://imgur.com/a/RIxX24M )にアップロードしました。参考になれば幸いです。 --turgenev 2024年1月18日(木) 22:47
- ありがとうございます。今、SVG画像をパーズしてGDライブラリでポリゴンを書き、キャンバスをPNG形式で保存する形でオリジナルのperlプログラムでPNG画像を生成しています。imagemagickなどの外部プログラムを使わない理由は単純にスピードです。十数年前の結論なので、もっと良い方法があれば切り替えたいと思います。--kamichi 2024年1月19日(金) 08:29
- ご返信ありがとうございます。ポリゴンの描画ごとにラスタ化の処理が走るとなると、形状が明確な長方形ポリゴンが「濃く」描画され、その結果(本来は完全に覆われるはずの)曲線ポリゴンからはみ出してしまうのではないかと思います。自作プログラムを使う場合でも、先にSVG全体を描画してからpng化するほうが品質は良くなるのではないかと思います。imagemagickは手元(Linux)で実験したところファイル1枚で0.05秒-0.1秒と、速いとも遅いとも言えない結果になりました。完全に感覚ですが、svg→png2値化に特化したプログラムなら、0.01秒くらいにできそうな気はします。ただ、大量のバッチ処理をするわけではないので、レイテンシとしては十分に小さい値のような気もします。--turgenev 2024年1月19日(金) 11:23
- 別の例として、u21230-sansのような凹凸も同じ原因だと思います(通常の漢字グリフでこのような形状は使いませんが)。これもimagemagickで生成した場合は綺麗な直線になります。--turgenev 2024年1月19日(金) 22:12
2020年
- 「グリフウィキには現在この名前の項目はありません。」ページの翻訳が消えました。jjanggu 2020/11/24 15:22
- 既に存在するグリフを編集するとき、プレビュー画像が表示されない。--kesuuko 2020年11月24日(火) 12:16
- すみません、修正しました。--kamichi 2020年11月26日(木) 19:56
- 似た原因と思われるバグとして、「未作成のグリフの編集ページで、グリフエディタと関連字の間に存在していたはずの改行が消滅している」があります--kesuuko 2020年11月26日(木) 20:01
- 最新版のグリフ(sandboxのみ?)が無効グリフだと過去分もすべてバツ表示される--kamichi 2020年10月18日(日) 16:32
- HTMLエディタでは、「←入替」「←」「入替→」「→」は中国語を表示言語にすると「作为前一划」「前一划」「作为后一划」「后一划」と表示しました。
アドバイスとして、「作为前一项」「前一项」「作为后一项」「后一项」がよさそうではないかと思います。--jjanggu
- 検索ページにて検索を行う際に、「これ以降の検索結果を見る」「これより前の検索結果を見る」アンカーをクリックすると検索キーワードのページへジャンプします。
- (例)検索キーワード「u7af9」(存在するページ)で「これ以降の検索結果を見る」アンカーをクリックすると、「u7af9」ページへ遷移する。
- --kamiyo 2020年10月2日(金) 13:21
- ご指摘と修正方法のご提案をありがとうございます。修正しました。--kamichi 2020年10月16日(金) 10:22
- この問題について、現在も英語および中国語で利用している場合に発生するようです(なぜか韓国語では発生しないようです)。--kesuuko 08:50, 11 June 2023
- 翻訳データのミスでした。修正しました。--kamichi 2024年3月24日(日) 17:39
- 細入り→左ハネ の曲線の終筆部分について、角度によっては右払いのポリゴンがはみ出て見えることがあります(sandbox@6199)。また、SVG画像を拡大してよく見ないと分からない程度ですが左ハネ付近で太さが揃っておらず段差が生じています(u9725@12の下などは段差が見えやすいでしょうか)。―twe 2020年8月30日(日) 00:22
- 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
2019年以前
- uXXXX-24の関連字の初期値が〓になっている(他の偏化変形はuXXXXが自動セットされている) --pyrite 2017年3月19日(日) 15:36
- バージョン付きのグリフを登録できない?(それは仕様?)指摘内容の確認から。--kamichi 2016年12月10日(土) 16:00
- 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
- ユーザー専有グリフ 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
- u5c38-05 のストレッチ値が −6 の場合も同じ挙動を確認しました。骨格データが「99:200:0:…」の場合に適用されるべき変形が行われないようです。sx = 200、sy = 0 ならストレッチモード B で移動先が (100, 100) という意味なので、sx2 = 0、sy2 = 0(すなわちつまむ位置も (100, 100))でない限りは変形の必要がある…という事だと思います…多分。 — sayunu 2022年7月17日(日) 21:55
- ご指摘ありがとうございます。エンジンを直さなければ→biangbiang麺もマシになるように肉付けも直したいな→データ形式も一度改めて設計しなおしたい→袋小路…になっています。--kamichi 2022年7月20日(水) 10:58
- 専用エディタにて、「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