このページは古くなった情報の退避用です。書き込みはご遠慮願います。2007年～2015年までに報告されたものをここに置きます。
Rendering of new right zh corner
- 縦棒が斜めになった場合にも対応させました。なお横棒が斜めになった場合にはまだ対応していません。--kamichi 2016年1月22日(金) 09:03
- 今回不思議に思ったのですが、そもそも右下角向け新H/T形状は
u6bcc-h,
u6bcc-tのために用意したつもりです。が、u6bcc-t（規格票例示字形も同じです）は明らかに右下は角を閉じてない（閉じたあと余韻の進み筆か）ですよね。まさかこの形状で座標位置は縦棒と横棒が同じ、というのは無茶かなと思いました。ですのでu6bcc-tは縦棒は32（接続）、横棒は0(開放）で座標は一致させない、というデータになると思います。Hソースのための形状になるのかなと思います。それともこの字だけでしょうか。
- 反応遅れましてすみません。直接ダウンロードして良いのでしたら、今後そのようにさせていただきます。If it is allowed to download fonts directly, I will do that. --two-lfdp 2016年1月21日(木) 02:31
- 反応が遅くなってすみません。フォント生成が完了しても、何かしらの理由でサイズが0の場合（失敗した場合）、「生成中」と出る仕様になっていて、本件もこれに該当します。私のほうで調べてみます。--kamichi 2016年1月21日(木) 09:43
- 大変遅くなりました。原因はIVSグリフが使われているのでIVSフォントとして生成しようとするのですが基底コード（
u25651-ue0101に対する
u25651など）が含まれないので矛盾をきたして生成失敗となっています。対処法はあくまでもグリフを使いたいという宣言「:IVS:no」を含める、というものです。（成功例：グループ:kamichi_test@39）いちおうフォント生成のヘルプには書いていますが、これだけでは説明になっていませんので書き換えが必要ですね。--kamichi 2016年1月21日(木) 10:31
- フォントが生成中なのか失敗かの判定ができていないバグについて修正しました。--kamichi 2016年1月21日(木) 10:48
- 確認しました。訂正ありがとうございます。 --two-lfdp 2016年1月22日(金) 00:59
グリフ専用エディタは中国語や韓国語のサイトに機能しません。 umbreon126 2016年1月14日(木) 20:20
- 修正しました。ご指摘ありがとうございます。--kamichi 2016年1月21日(木) 10:13
外部リンクのアイコンの右側に余計な空白が現れます。umbreon126 2016年1月12日(火) 19:56
- もともと半角スペースが左および右に1つずつ入ることにしていますが、そのことでしょうか？邪魔ですか？--kamichi 2016年1月12日(火) 20:24
- Personally, space to the left of punctuation feels out-of-place. 個人的に役物の左側のスペースは場違いに感じます。
- リンクの例
.
- umbreon126 2016年1月12日(火) 21:21
- 個人的に左は必要かなと思ったので、ご指摘の右空白のみ無くしました。ご指摘ありがとうございます。--kamichi 2016年1月21日(木) 11:12
u0031や
u0032の次の符号位置がu0000になります
- ご指摘ありがとうございます。Perlの盲点（というか私のミス）でバグとなっていました。興味深いので以下引用します。--kamichi 2015年12月4日(金) 21:51
バグ：if($parent_char > "\x{10ffff}"){
修正：if(unpack('U', $parent_char) > 0x10ffff){
(この続き）
$code = "0000";
$char = "\x{0}";
Rendering of new left zh corner
- I can't understand the meanings of 'fail(s)'. Please explain it. --kamichi 2015年4月20日(月) 23:36
- The rendering of the bottom left zh (new) is still strange in some more acute angles. For example, in http://en.glyphwiki.org/glyph/u725a-g.svg , the Left Bottom (ZH New) polygon for 牙 is not positioned correctly. The Left Bottom (ZH New) polygon should be shifted right and rotated clockwise if the downward stroke is of different angle. Illustration of the problem: http://jsecs.org/nsd.henry/fail.png . The desired shape is the one on the right, instead of the left. Would this be fixed in the near future? --chanhenryfaihang 20:47, 19 May 2015
- 必ず直します。６月中旬まで多忙のため、時期についてはお約束できません。ごめんなさい。--kamichi 2015年5月19日(火) 20:51
- Sorry for the urge, will it be fixed soon? hkcs 13:25, 21 July 2015
- Sorry for urging, could these two rendering be fixed soon? chanhenryfaihang 23:05, 14 January 2016
- 大変お待たせしました。調整してみました。再調整が必要でしたら教えてください。なお、現時点でグリフエディタは古いエンジンを使います。編集終了後のプレビュー画面で確認してください。--kamichi 2016年1月16日(土) 09:18
- Thank you very much for the changes! It is displaying nicely now. chanhenryfaihang 2016年1月18日(月) 17:56
- The Information About CCS (文字コード関連情報) does not show when in uxxxx-h or uxxxx-i etc. (feature request?) When pressing the previous code point / next code point button, the locale is not retained. chanhenryfaihang 16:36, 8 May 2015
- Fixed. Thank you for inform. --kamichi 2015年5月12日(火) 13:01
Inconsistent rendering of left tick
For 
u9699 (and other old created character which quotes 
u961d-01), the leftward complex hook stroke in png and svg files do not match. For example, http://en.glyphwiki.org/glyph/u961d-01.png vs http://en.glyphwiki.org/glyph/u961d-01.svg and http://en.glyphwiki.org/glyph/u9699.png vs http://en.glyphwiki.org/glyph/u9699.svg.
However, for newly created glyph, e.g. 
hka-bbd8, which is alias of u9699, the leftward complex hook stroke match for png and svg.
The main problem is was the change in the shape of leftward complex hook stroke intentional, and should the hook stroke touch the downward stroke or not?
chanhenryfaihang 23:01, 18 April 2015
- umm... KAGEエンジンの変更（左ハネの長さの調整）は2013年1月8日(火) です。ですので、少なくともu961d-01のpngファイルは、変更前の古いエンジンで生成されています。なぜsvgが新しいエンジンで生成されているかは不明です。
- このため、u961d-01を更新すればpngファイルも新しいエンジンで再生成されます。--kamichi 2015年4月18日(土) 23:31
- 本来は、エンジンを更新した場合には全てのグリフを再生成すべきですが、100万グリフ以上あるので、再生成していません。--kamichi 2015年4月18日(土) 23:31
Bug after update to support new Right Bottom ZH(t/h) style
When including components (e.g. type "99" stroke), the last right bottom corner often change into the Right Bottom ZH(t/h) style. The bug appears in the png and svg. However, the rendering is correct in the editor. Affected glyphs:
This bug occur for all new glyph. Example is visit http://en.glyphwiki.org/wiki/test-kagebug?action=preview&textbox=99:0:0:0:0:200:200:u5415:0:0:0 or http://en.glyphwiki.org/wiki/test-kagebug?action=preview&textbox=99:0:0:0:0:200:200:u8425:0:0:0 or http://en.glyphwiki.org/wiki/test-kagebug?action=preview&textbox=99:0:0:0:0:200:200:u5705-g02:0:0:0 and you find the preview is incorrect.
- ご指摘ありがとうございます。私の間違いで、バグが発生してしまいました。右下角のKAGEエンジンでの形状番号は２３番ですが、H/Tデザインを１２３番として新設しました。しかし、エンジン内部で１２３番は別の意味に使われていて、その結果、２３番の形状を指定しているにもかかわらずH/Tデザインになってしまっています。これは私のミスです。chanhenryfaihangさん、ごめんなさい。
- ですので、１２３番をやめて、２４番として振り直します。今まで、１２３番でデータを作ってしまったものは２４番に直す必要があります。また、バグのある状態でグリフを生成してしまった多数のグリフは、修正したエンジンで再度グリフを生成し直す必要があります。ちょっと時間がかかりますが、少しずつ修正していきます。--kamichi 2015年4月18日(土) 21:39
- 123番を使っているグリフは１つだけのようでした。24番に更新しました。--kamichi 2015年4月19日(日) 12:14
- まだ、グリフエディタではH/T右下角(24)は指定できません。ちょっと落ち着いてから更新します。--kamichi 2015年4月18日(土) 21:40
- この件、対応しました。--kamichi 2015年4月20日(月) 08:47
- 今、バグ発生時点からの全グリフを再生成しました。意図しないH/T右下角デザインは全て修正されました。大変失礼しました。--kamichi 2015年4月18日(土) 21:49
- No worries, thank you for the speedy fix! -- chanhenryfaihang 22:57, 18 April 2015
-
関連字が表示されません。 tsuruki 2015年7月22日(水) 23:36
- （取り急ぎ）昨晩のcronで関連字データの生成に失敗していました。手動実行で解消しました。--kamichi 2015年7月23日(木) 00:21
行頭で無く、行の途中で引用されている場合、グリフの引用されているページリストに出ない？--kamichi 2015年5月9日(土) 18:58
- いろいろ白紙化してしまったのは失敗だったかもしれません…。--kamichi 2015年5月9日(土) 19:16
- 仕様だったので仕様を変更しました。--kamichi 2015年5月10日(日) 16:06
-
「手書き漢字検索」が使用できなくなっているようです。―twe 2015年4月19日(日) 23:02
- ご指摘ありがとうございます。Rubyのバージョンが上がってライブラリを認識しなくなっていました。移行方法が不明なため、以前のRubyを使うように指定しました。とりあえず復旧しています。--kamichi 2015年4月19日(日) 23:43
- 「筆画による漢字検索」で、「ストローク」欄に漢字を入力した際に一部の漢字が無視されるようです。無視される漢字は、UCSの無印グリフがエイリアスになっているもの（例：冏、嶼、钅、…）のようです。（いずれもストロークを入力すれば、エイリアスの参照先が検索結果に出てきます）―twe 2015年4月19日(日) 23:02
- おそらくエイリアス先を参照していないため、UCSが実体グリフではない場合にデータを取りこぼしているのだと思います。修正候補ですが、ちょっと時間がかかると思います。--kamichi 2015年4月19日(日) 23:43
- 機能を閉じてしまったので閉じます。--kamichi 2016年1月22日(金) 18:26
-
u2481f、
u4e56などの異体字に
ufffdがあります
- ご指摘ありがとうございます。元データ（漢字データベースプロジェクト）に問題があるようです。関係者に連絡しました。--kamichi 2014年10月20日(月) 18:34
- 元データに当たって何が起きているかを本当は確認しなければなりませんが、さしあたり（昔通り）こちら側で対処することにしました。修正しました。--kamichi 2014年11月2日(日) 16:09
非漢字ページの「前の符号位置」「次の符号位置」は
I(u0049) 等を表示するはず[[I u49]]を表示します。好ましくないでしょうか。--umbreon126 2014年10月5日(日) 16:34
- すみません。修正しました。ご指摘感謝。--kamichi 2014年10月5日(日) 17:04
- swapの排他処理に問題があるかを調査。--kamichi 2014年9月30日(火) 08:34
- 一旦閉じます。--kamichi 2016年1月22日(金) 18:26
ユーザー占有グリフでソース表示のページがalignのclearができていない--kamichi 2014年8月26日(火) 13:07
-
異体字関係に、「簡繁関係」(など)がまた消えているようです。 --johotogoshinentai 2014年4月1日(火) 18:13
- 現在、データ提供元の方でデータの改変を行っているとの事です。落ち着くまでグリフウィキの関係データも不具合が出たままとなります。ご了承ください。--kamichi 2014年4月1日(火) 21:15
- かなり時間がかかっているようですが、いつ直るのでしょうか？ --johotogoshinentai 2014年5月26日(月) 17:23
- すみません、手つかずの状態が続いて、見通し不明です。何とかします。--kamichi 2014年5月26日(月) 22:14
- ということで新フォーマットへの対応が完了しました。異体字ラベル（項目名）もそのまま使うように変更したので、見た目が少々悪くなっています。調整が必要ですが、ひとまず完了とします。--kamichi 2014年5月27日(火) 13:30
- 向きも考慮してラベルを書くようにしました。原データは片方向と双方向の２つの関係があり、片方向のものについては逆参照を「←」付きのラベルで表示します。--kamichi 2014年5月28日(水) 16:34
グループ:グリフウィキに収録されている非漢字-3@13がフォント生成中のままです。このグループには無限ループは存在しないようです。--spinda-kkmr 2014年2月22日(土) 15:59
- 最終フォントファイルがサイズ０でした。生成時にプロセスが落ちたのか、生成に失敗したのか不明です。次回更新時の挙動を確認したいと思います。一つ考えられるのは無グリフ
u3000がわざわざ指定されているので、それがttxを通るときに実体無しで矛盾が発生してttfの出力に失敗しているのかもしれません（？？？）--kamichi 2014年2月22日(土) 17:21
- 今再生成しましたが問題ないですね。ログを見るとフォント生成が２プロセス同時に動いてしまっているようなので、それで最終フォントファイルが壊れたか上手く生成できなかった可能性があります。多重プロセスのチェックが甘いので要改善です。--kamichi 2014年2月22日(土) 17:27
- 閉じます。--kamichi 2016年1月24日(日) 00:05
(u1680) が
一(u4e00) のような正常な表示にならない。--spinda-kkmr 2013年9月22日(日) 13:07
設計思想が「対象：漢字」のため、現時点では仕様と理解しています。非漢字はコードポイントの抜けが多く把握しきれないので困っています。--kamichi 2013年9月22日(日) 13:45- あれすみません、変な事を書いてしまいました。特殊例だったのですね、チェックします。--kamichi 2013年9月22日(日) 13:46
- 現時点では不明です。
PerlではU+1680をなぜか3文字とカウントします。ただ第1項に使う文字は基本的に動作に関係ないので理屈に合いません。引き続き調べます。ご指摘ありがとうございます。--kamichi 2013年9月22日(日) 14:36
- 原因が分かりました。現在［［キャプション グリフ名］］の記述のキャプションの抽出に文字（Perl正規表現のS）または半角空白U+0020、としているので、PerlがU+1680を文字と見なしていないためです。一時的に文字と見なすようにしましたが、他にも存在するはずで根本的な解決になっていません。引き続き検討します。--kamichi 2013年9月22日(日) 15:40
- 以前はきちんと表示されていたはずですが，いつの間にか元に戻ってしまっているようです。--spinda-kkmr 2014年8月13日(水) 09:17
- u1680はspacing characterらしい。（同様に[[ u3000]] もできません）
- "OGHAM SPACE MARK // • glyph is blank in “stemless” style fonts // → 0020 [SP] space" --umbreon126 2014年8月13日(水) 09:29
- いま暫定的に再修正しました。U+1680の文字クラスが空白なのでemacsが勝手に空白に書き換えた？のかもしれません。なお、空白クラスはこの書き方ができないというのは仕様で良いと思います。ですので、現在は特別にU+1680のみ許されていますが、とくに用途がなければ、こちらも大元の状態に戻したいと思います。umbreon126さん補足説明ありがとうございます。--kamichi 2014年8月29日(金) 18:41
koseki-319460のストレッチ機能が使えない。1回編集してもう一度編集するとストレッチのパラメータがNaNになる
- このバグは部品のストレッチ方向がUかDに指定されていると必ず発生するようですね… ―twe 2014年4月27日(日) 19:51
- ご指摘ありがとうございます。--kamichi 2014年4月29日(火) 08:20
- エディタが変更となったので閉じます。--kamichi 2023年8月31日(木) 15:47
-
GlyphWiki-ノート:命名ガイドラインを閲覧しようとすると、Internal Server Error が発生します。バーベイタム機能が使われている箇所に、グリフへのリンクがある時に発生するようです。― twe 2013年3月30日(土) 18:15
- ご指摘感謝。修正しました。--kamichi 2013年4月17日(水) 23:12
-
異体字関係に、「常用新旧」、「原規格分離」などが消えたようです。 --johotogoshinentai 2013年3月30日(土) 12:26
- ご指摘感謝。データソース（github）の場所移動を反映していませんでした。次回更新より復旧するはずです。--kamichi 2013年4月17日(水) 23:26
メタ情報を追加することができません。JavaScriptをonにしてもoffにしても、メタ情報そのものがセーブされないようです。--johotogoshinentai 2013年3月13日(水) 16:45
- ご指摘ありがとうございました。スパム対策で間違えておりました。修正しました。--kamichi 2013年3月25日(月) 15:10
最近グリフエディタの利用時に以下のメッセージが出るという方がいらっしゃるようでしたらお知らせください。--kamichi 2013年2月7日(木) 16:22
ムービー内のスクリプトが原因でAdobe Flash Playerの
実行速度が遅くなっています。このまま継続すると、応答
しなくなることがあります。スクリプトの実行を中止しますか？
- 当方は今週に入ってから、「選択部品を分解」押下で上記メッセージが出現する事があります。因みに出現した時は、ダイアログの「いいえ」ボタンを押しても回避出来ず、已む無く「はい」を押下してもう一度エディタで、部品の順番を入れ替えたりして編集し直しています。今の所出現頻度は低いので、編集出来無い迄には至っておりません。--kamiyo 2013年2月8日(金) 01:45
- ご教示ありがとうございます。FlashMX5からFlashCS6体験版に移行してみました。これで変わるでしょうか？--kamichi 2013年2月8日(金) 15:58
- 当方側も、JavaConsole6.0.33、6.0.37、6.0.39をそれぞれ入れ替えてみたのですが、やはりダイアログが出現する、部品が消える現象が出てしまいます。
部品数の多いグリフ、例えば
u98dbのグリフエディタで、他の部品を選択し部品分解を行うとダイアログが出力され、編集不能に陥ります。--kamiyo 2013年2月10日(日) 00:06
u6c35-01のエディターを開き、
u6dbcを引用して分解しようとしたら、そのアラートが出ました。ちょっと条件を調べてみた所、現在のサンズイの四画目を削除し、一・二・三画目がエディター上に存在する状態で「涼」を分解した場合には発生しますが、一・二画目とか二・三画目とか一・三画目だけ残してある場合は発生しません。「涼」の位置や大きさは関係ない様です。— sayunu 2013年2月10日(日) 02:42- グリフエディター上で、或る引用グリフより書き順の若い筆画が三本以上有って、その引用グリフの中で更にほかのグリフを引用している場合に、その引用グリフを分解しようとすると発生する ? — sayunu 2013年2月10日(日) 02:49
- グリフを専用エディタの「選択部品を分解」を行うと、分解を行った部品より下のレイヤーに存在する部品が消える様です。
例えば、
u6f22は、
1| 99:0:0:2:0:154:200:u6c35-01
2| 99:0:0:48:0:198:202:u26c29
ですが、u6c35-01を分解すると、結果が、
1| 2:7:8:25:20:44:27:52:41
2| 2:7:8:11:66:31:73:39:87
3| 2:7:8:12:133:39:142:36:184
4| 2:32:7:32:150:35:138:67:67
5| 99:0:0:48:0:198:202:u26c29 ←消滅する
と、分解を行った部品より下のレイヤー
u26c29が消滅します。
※因みに分解を行う部品より上のレイヤーは消滅せずに残る様です。--kamiyo 2013年2月5日(火) 12:34
- 上記「スクリプトが停止する」「部分的に部品群が消える」２つについて、どうやらプログラム上の凡ミス1件にどちらも起因するようです。修正しました。引き続き状況の報告をお願い致します。--kamichi 2013年2月10日(日) 16:36
- 今回の修正はスクリプト停止にあまり関係ないような気がしています。もしスクリプト停止が発生しましたら、お知らせください。よろしくお願いします。--kamichi 2013年2月10日(日) 21:12
「99:～～～:グリフ名」以降のストレッチ機能情報が存在する場合、編集ページ下に表示される簡易調整のグリフが、白紙となり表示されます。
- ご指摘ありがとうございます。システムが肥大化しすぎているので、この機能はいったん停止することにしました。--kamichi 2013年2月3日(日) 17:02
u24d00-jv@1を編集後，このグリフで使われている
u582f-02-var-004を編集したにもかかわらず，
u24d00-jvのグリフページに「旧部品の更新」が表示されません。データの末尾にストレッチ機能B用の“:数字:数字:数字”がついていると(:0:0:0も含む)その部品が編集されても“@バージョン”がデータに付加されないようです。このままでは1つのバージョンのグリフで字形が違うという事態が発生する可能性があります
- ご指摘ありがとうございます。９９引用に関するプログラムの書き換えで残っている部分がありましたので修正しました。ストレッチ導入後に登録した、長い９９データを含むグリフのうち、その引用部品自体を修正した場合に、旧バージョンへの書き換えがなされなかったものが存在すると思います。影響の大小を考えてみます。--kamichi 2013年2月3日(日) 11:01
グリフページで、「このグリフを収録するグループ一覧」に列挙されている最後のグループへのリンクが閉じられていないようです―twe 2013年2月3日(日) 03:21
- 修正しました。ご指摘ありがとうございます。--kamichi 2013年2月3日(日) 11:01
グリフ編集、グリフ新規追加を行っても、使用した当該グリフページの「このグリフを内部で引用している他のグリフ一覧」に表示されない様です。
u93bcを使った
u21148のグリフ編集を行うと、u93bcの引用グリフ一覧にu21148が表示されません。
※「99:～～～:グリフ名」の末尾に、新たな３つ(ストレッチ機能Bモード)の情報が付与されたものが表示されないようです。--kamiyo 2013年2月3日(日) 00:28
- ご指摘ありがとうございます。修正しました。が、今回の改造で他にも不具合が出てきそうな予感がします。--2013年2月3日(日) 00:58
ドキュメントページの命名に「々」が使えない --kamichi 2013年1月14日(月) 20:22
- 文字種として追加しました --kamichi 2013年1月22日(火) 16:06
フォント生成ログの改行がLFのためWindowsで見にくい
- 仕様と考え、閉じます --kamichi 2012年12月6日(木) 22:43
利用者ページが誰でも編集できる --kamichi 2012年5月5日(土) 08:19
JSON/JSONP 形式のグリフデータの取得がエラーでできなくなっています。（先月末のサーバの切り替えがあった頃からかと思います。） ―twe 2012年3月21日(水) 17:54
- お知らせいただきありがとうございました。ライブラリ不足でしたので復旧しました。--kamichi 2012年3月21日(水) 21:01
SVG（パス）による出力に問題があります。ポリゴンによる出力 は適切ですが、パスによる出力 では、一部のストロークが不適切であるほか、ポリゴンによる出力と若干形状が異なります。 --zeeksphere 2012年3月15日(木) 16:24
- パス出力はまだ完成していません。KAGEエンジンの更新が滞っているためです。すぐに解消できる見通しは立っていないのが現状です。汚いながらソースは公開されていますので、応援求む状態です。--kamichi 2012年3月15日(木) 17:16
- ということで閉じます。--kamichi 2012年12月6日(木) 22:03
一括更新処理に不具合があるようです。（参考：http://glyphwiki.org/wiki/ufa66?view=all ）
- それですが、バグではありません。一括更新の時、「ufa66,type2,0,0,200,200」と打ち込んで更新しました。(0:0:199:200などのグリフを直すため) 3つの部品の2番目で使われているものを思いつかなかったのは私の見落としです… 申し訳ありません。でも今は時間がないので、明日までは直すようにします。 --johotogoshinentai 2012年2月16日(木) 17:55
- そうだったのですね。早とちりしてしまいました。私の方でも直せるものは手をつけようと思います。--pyrite 2012年2月16日(木) 18:04
- ということで閉じます。戻すついでの調整も含め、全部戻せたと思います。--kamichi 2012年2月16日(木) 21:05
juki-b273や
juki-b275が，登録されているにもかかわらず左上の「グリフ」と「履歴」が赤文字で表示され，また，このように引用すると未作成文字として表示される。
- 正常になっているようです。エイリアスの実体変更がなされると正常化するようです。--spinda-kkmr 2011年8月20日(土) 18:47
- 負荷が高くてリンク関係の計算に失敗しているのではないかと思います。すみません。--kamichi 2011年8月20日(土) 19:14
占有グリフであっても一般グリフのエイリアスだとそのエイリアス先の変更が反映される。これはどういう仕様がベストか？--kamichi 2011年8月15日(月) 17:59
- 私個人の意見としては，これは仕様として残していいと思います。完全な占有グリフにしたいのであれば実体グリフとして保存すればいいと思います。--spinda-kkmr 2011年8月15日(月) 20:08
- いったん閉じます--kamichi 2012年1月2日(月) 13:18
異体字情報が「UCS互換」しか出てきていないらしいです。--johotogoshinentai 2011年7月23日(土) 10:51
- 漢字データベースの異体字データの書式が変更になり、それへの対応ができていません。ちょっとお待ちください--kamichi 2011年7月23日(土) 21:50
- やっと対応しました--kamichi 2011年8月14日(日) 20:07
- 対応してから、逆に「UCS互換」のほうが出てきていないらしいです。--johotogoshinentai 2011年8月15日(月) 01:32
- プログラムが1か所間違っていたので修正しました。--kamichi 2011年8月15日(月) 17:59
縦書きでの字送りの量がおかしい？--匿名利用者 2011年5月18日(水) 16:41
- 花園フォントのことですよね。もう少し詳細な情報をいただけると助かります。使用環境、使用アプリケーションや実際の文字列などです。よろしくお願いします。--kamichi 2011年5月18日(水) 19:10
- OSはWindows Vista x86、アプリケーションは秀丸エディタ、Google Chromeで確認しました。花園フォントに存在する文字のみだと文字列が全く表示されず、その後に花園フォントに存在しない文字を並べると花園フォントに存在する文字の部分が重なって表示されます。おそらく字送りが0になっているのではないでしょうか。--匿名利用者 2011年5月18日(水) 21:23
- unitsPerEmが1024なのに、vmtxテーブルを見るかぎりほとんどのグリフのadvanceHeightが15しかなくて、明らかにおかしいですね。--emk 2011年5月25日(水) 01:49
- 匿名さん、emkさん、ありがとうございます。以前vmtxテーブルを作成する変更を行った時に、VWidthを設定していませんでした。これを1024にすると字送りは問題ないのですが、本来のカーソル位置よりも下に文字がずれて表示されます。一方、横組みと同じように144にすると、字送りが足りずに文字が重なってしまいます。VWidth(height)は1024で、vheaのどれかを直せばいいのだと思いますが、試行錯誤中です。--kamichi 2011年5月25日(水) 13:03
- 字送りは1024で問題ありません。hmtxテーブルを見る限り横方向の字送りも1024みたいなのですが、144ってどこから持ってきた数字でしょうか?
文字が下にずれるのは、単にtopSideBearingが大きすぎるからだと思います。字送りが1024しかないのに、ほとんどのtopSideBearingが768より大きいのは明らかに異常です。--emk 2011年5月25日(水) 23:36
- つまり、現状でFontoForgeにおいてtopSideBearingの値を設定できる場所が不明、というところで止まっています。144という数字は、字送りではなく、グリフの座標位置の範囲（880～-144）の数字です。間違えました。--kamichi 2011年5月26日(木) 09:23
- 現状はttf生成後にttxでTSB等を設定するスクリプトを別に走らせて解決しています。まだグリフウィキでのフォント生成に取り込めていません。--kamichi 2012年2月8日(水) 23:40
- いったん閉じます。--kamichi 2012年12月6日(木) 22:03
u2f882-01を作ったのですが、CJK Compatibility Ideographs Supplementの文字を関連字設定できないようです。
- これは仕様です。CJK互換文字は関連字に設定できません。そもそもu2f882ではなく、その文字に対応付けられている通常のCJK漢字の符号位置の変化変形の異体字（異形）として定義すべきと考えます。--kamichi 2011年4月30日(土) 22:55
「偽物」互換漢字(﨎(FA0E)、﨏(FA0F)、﨑(FA11)、﨓(FA13)、﨔(FA14)、﨟(FA1F)、﨡(FA21)、﨣(FA23)、﨤(FA24)、﨧(FA27)、﨨(FA28)、﨩(FA29))は修正できません。修正すると、関連字エラーメッセージが出ます。互換漢字そのものを関連字として設定できません。 --johotogoshinentai 2011年3月14日(月) 04:25
- 確認したところ、プログラムソースでは上記集合はすべて関連字として指定可能となっていました。実際に更新しましたが、特に問題は起きていません。もう一度不具合が生じるかどうかを確認していただけないでしょうか。--kamichi 2011年3月23日(水) 10:29
- あぁ、バグが生じる正確な状況を見つけました。エディタで編集して終了ボタンを押してエディタから出て編集をセーブしようとすると、関連字が設定できません。 --johotogoshinentai 2011年3月23日(水) 13:08
- 情報ありがとうございます。症状を確認し、修正しました。--kamichi 2011年3月23日(水) 14:12
異体字ばねグラフのUCSグリフが更新されていない？--kamichi 2011年2月11日(金) 13:04
- 更新スクリプトの実行フラグがたっていなかったので修正 --kamichi 2011年3月27日(日) 23:46
U+4DC0からU+4DFFまでのYijing Hexagram Symbolsのグリフを登録しようとしたんですが、「UCS関連グリフの関連字に別の文字の割り当てや未定義（〓）とすることはできません。」という関連字エラーメッセージが出て登録できません。 --johotogoshinentai 2011年1月8日(土) 05:58
- ご指摘ありがとうございます。バグではなくて、仕様です。というのはグリフウィキはもともと漢字のみを対象としていたので関連字も漢字しか指定できません。関連字の対象をUCS全体に広げるかどうか、これは新たに議論すべきことと思います。ただ、UCSのコードそのもののグリフは関連字を指定するメリットはほとんどないと思います。
- でも、他のUCS文字は登録できるのに、U+4DC0からU+4DFFのみを登録をできないようにするのは、よくないと思います。その文字は作りにくくないですし。 --johotogoshinentai 2011年1月10日(月) 02:23
- ちょっと確認していいでしょうか。「関連字」はある文字に対する複数の異体字形をグリフウィキに登録する場合に、1つのUCS符号位置に結び付けてそれぞれがバラバラにならないためにするためのものです。基本的に非漢字グリフはグリフウィキの対象ではなかったので複数の異体を登録することは想定していません。ですので非漢字のUCSは関連字に指定できません。今回johotogoshinentaiさんが提案されているのは（A)「非漢字」を関連字に登録できるようにするのか、（B)「Yijing Hexagram Symbols」を関連字に登録できるようにするのか、どちらでしょうか。（B)はそれだけを特別扱いする対象ではないので変です。（A)に踏み切るかどうかは、やや躊躇します。（C)あるいは「非漢字」を意味する関連字を設定できるようにして、検索で非漢字だけすべて抽出できる、というのはいかがでしょうか。--kamichi 2011年1月10日(月) 09:59
- I'm trying to say that any other 非漢字 glyphs (like
u0041, 
u3004) can be submitted without 関連字 (their 関連字 is 〓 but they were submitted without any problems), but Yijing Hexagram Symbols cannot be submitted no matter what. I'm wondering why do Yijing Hexagram Symbols only have that restriction.
- In short, this is my request: can you let Yijing Hexagram Symbols be submitted without 関連字 (that is, 関連字 being 〓)? --johotogoshinentai 2011年1月10日(月) 10:38
- ああ、すみません。バグでした。U+4DC0からU+4DFFはグリフとしては漢字扱いになっているけれども、関連字としては非漢字で指定できないため、結果としてグリフを登録できない状態になっていました。修正します。大変失礼しました。--kamichi 2011年1月10日(月) 11:35
u27951と
koseki-399750のハネがおかしくなっています。
- ご指摘ありがとうございます。この現象を直すよりも、大昔に追加すると決めていた回転・反転機能を実装すれば解決すると思ったのですが、そうすると調整機能を大幅に作り直す必要があることに気が付き、手が止まっています。もう少々お待ちください。--kamichi 2010年11月3日(水) 22:22
- とりいそぎバグの修正だけ施しました。--kamichi 2010年11月10日(水) 13:48
- 一括処理機能で新たなグリフを登録するときにデータエラーで生成できない(真っ白)時はそのグリフを登録しないでほしい --kamichi 2010年10月31日(日) 21:32
- 一旦閉じます。--kamichi 2016年1月22日(金) 18:26
ChromeやFirefox 4では、最終テーブルのサイズが4の倍数になるようにパディングがされていないと、ダウンローダブルフォントとしての使用を拒否されるようです(https://bugzilla.mozilla.org/show_bug.cgi?id=600821 )。実際にテストページでフォントを生成してみて、サイズが4の倍数にならない場合があることを確認しました。FontForgeのバージョンの問題でしょうか? --emk 2010年10月9日(土) 00:41
- ご指摘ありがとうございます。手元の環境の都合でまだ不具合を確認できていないのですが、これはFontForgeではなくIVSを埋め込むためのTTX(fonttools)の問題のようです。自分でダミーデータを加えるしかなさそうです。--kamichi 2010年10月13日(水) 10:07
- とりあえず今日の更新分についてはバイナリエディタで2バイト追加して4の倍数にしました… --kamichi 2010年10月13日(水) 12:31
- パディング付加をシェルスクリプトで書くとこんな感じでしょうか。--emk 2010年10月15日(金) 23:08
filesize=`wc -c < hanazono.ttf`
padsize=`expr \( $filesize + 3 \) / 4 \* 4 - $filesize`
head -c $padsize /dev/zero >> hanazono.ttf
- （気づくのが遅れました）ご教示ありがとうございます。反映させます。--kamichi 2010年11月14日(日) 09:34
- 対応しました。 --kamichi 2010年11月14日(日) 09:50
ChromeやFirefox 4では、最終テーブルのサイズが4の倍数になるようにパディングがされていないと、ダウンローダブルフォントとしての使用を拒否されるようです(https://bugzilla.mozilla.org/show_bug.cgi?id=600821 )。実際にテストページでフォントを生成してみて、サイズが4の倍数にならない場合があることを確認しました。FontForgeのバージョンの問題でしょうか? --emk 2010年10月9日(土) 00:41
- ご指摘ありがとうございます。手元の環境の都合でまだ不具合を確認できていないのですが、これはFontForgeではなくIVSを埋め込むためのTTX(fonttools)の問題のようです。自分でダミーデータを加えるしかなさそうです。--kamichi 2010年10月13日(水) 10:07
- とりあえず今日の更新分についてはバイナリエディタで2バイト追加して4の倍数にしました… --kamichi 2010年10月13日(水) 12:31
- パディング付加をシェルスクリプトで書くとこんな感じでしょうか。--emk 2010年10月15日(金) 23:08
filesize=`wc -c < hanazono.ttf`
padsize=`expr \( $filesize + 3 \) / 4 \* 4 - $filesize`
head -c $padsize /dev/zero >> hanazono.ttf
- （気づくのが遅れました）ご教示ありがとうございます。反映させます。--kamichi 2010年11月14日(日) 09:34
- 対応しました。 --kamichi 2010年11月14日(日) 09:50
-
「先ほどの関連字表示の修正がおかしかったので再修正（UCS符号そのものに対するエイリアスグリフが関連字をその符号に指定している場合は単独で出さないようにした）。--kamichi 2010年8月31日(火) 16:53」ということですが、UCS符号そのもの以外に対するエイリアスは直っていないようです。(例
unc-074) --daekyo 2010年9月1日(水) 01:46
- ご指摘ありがとうございます。やっとソースコードの問題部分の本質を解明しました。ということで、今度こそ正しい挙動になったと思います。--kamichi 2010年9月1日(水) 08:44
- 仕様と考えていいと思いますが、白紙化した場合にエイリアス関係が切れてしまう問題がありました。リバートを手動ではなく機能として独立した方がいいかもしれません。--kamichi 2010年8月30日(月) 23:11
これはバグではなく仕様なのかもしれませんが、エイリアス元と関連字が違うエイリアスで、(エイリアス元ではなく)関連元からエイリアスが表示されなくなったので不便です。(例:
u9115と
u9115-k(aj1-13725 のエイリアス)) --daekyo 2010年8月28日(土) 23:57
- これは、u9115のページにu9115-kに関する情報が載っていないということでしょうか。u9115-kは関連字をu9115にしているから、これはおかしいですね。--kamichi 2010年8月29日(日) 00:41
- その通りです。正直言うと、最初に気が付いたのはu9115ではなく
u6a4bのページを見ていた時なのですが、以前関連字に表示されていた
u6a4b-itaiji-002が表示されなくなったので、仕様が変わったのかなと思っていたのですが、やはりおかしいのですね。--daekyo 2010年8月29日(日) 02:46
- 修正しました。ご指摘ありがとうございました。--kamichi 2010年8月31日(火) 14:16
エイリアス元と関連字が違うエイリアスで、実体を変更すると、勝手にエイリアス元の関連字に変更されてしまいます。 --daekyo 2010年8月28日(土) 23:57
- これは上記の例でいうとaj1-13725を変更するとu9115-kの関連字がいじられてしまうということでしょうか。--kamichi 2010年8月29日(日) 00:41
- そうです。u9115-kの履歴を見てもらうと分かると思うのですが、@1では関連字がu9115になっているのに、aj1-13725を部品に置き換えたら、u9115-kの関連字が
u90f7になってしまいました(@2)。なので、@3で関連字をu9115に設定し直しました。--daekyo 2010年8月29日(日) 02:46
- ご指摘ありがとうございます。ミスです。これの影響でデータを直す必要があるのは15個のようです。それ以外に影響のない書き換え（エイリアスに〓以外の関連字を当てていて、その関連字がエイリアス先の関連字と同じため、〓に書き換わっても影響ない）が多数ありますが、こちらは直す必要はないと思います。--kamichi 2010年8月29日(日) 10:55
一応チェックに利用したSQLを記録しておきます。status=1というのは最新グリフの意です。
select a.name, a.version, a.related, b.related, c.related from wiki
a, wiki b, wiki c where a.name = b.name and a.version = b.version + 1 and a.re
lated <> b.related and a.summary like '%更新%' and a.data ~ '^99:0:0:0:0:200:20
0:[^$]+$' and b.data ~ '^99:0:0:0:0:200:200:[^$]+$' and substr(a.data, 20) = c.
name and c.status = 1 and c.related <> b.related and a.status = 1 order by a.na
me;
- 修正しました。--kamichi 2010年8月29日(日) 11:44
1字フォントの字幅がおかしい --kamichi 2010年8月28日(土) 00:50
-
新機能の実装など御苦労様です。私は今 課題で忙しいので（グリフを弄っているのは逃避）、取り急ぎ気付いたバグだけ報告します。
sandbox@413 をエディターで開いて、「夂」の筆画をクリックすると、「口」の方も一緒に選択されてしまいます。— sayunu 2010年8月10日(火) 20:33
- ご指摘ありがとうございます。修正しました。--kamichi 2010年8月10日(火) 21:43
KAGEエンジン更新の影響かもしれませんが、右上カドの曲線を含むグリフを更新しようとすると、プレビューで白紙になってしまう場合があります。具体的には始点より2点目が縦60pxに対して1px以上右にずれているとなってしまうようです。 --daekyo 2010年8月10日(火) 02:57
- ご指摘ありがとうございました。修正しました。--kamichi 2010年8月10日(火) 08:55
エイリアスの関連字を〓にしたいと思っても、エイリアスでの〓はエイリアス元の関連字に同じ、の意味になってしまう --kamichi 2010年8月2日(月) 19:00
- 仕様ということで閉じます。--kamichi 2016年1月22日(金) 18:26
部品エディタでIDSをキーワードとして検索した場合に含まれる部品で検索され、そのIDS（および部分）が候補にならない --kamichi 2010年6月16日(水) 07:31
- 仕様だったが、仕様を変更した --kamichi 2010年8月9日(月) 14:50
ページの編集履歴において、「(前の版)」のリンクのa要素の終了タグがありません。--匿名利用者 2010年5月10日(月) 19:32
- ご指摘感謝。修正しました。--kamichi 2010年5月10日(月) 22:39
他言語へのリンクが編集できなくなった--kamichi 2010年4月25日(日) 22:21
ページの編集履歴において、「(前の版) ＝ 直線の版との比較」と有りますが、「(前の版) ＝ 直前の版との比較」の間違いではないでしょうか。 --匿名利用者 2010年4月23日(金) 12:48
- ご指摘ありがとうございます。修正します。--kamichi 2010年4月23日(金) 12:57
- 修正しました--kamichi 2010年4月23日(金) 13:01
windows XPのnotepadで花園明朝（2010年2月22日版）のExt-B(SIP)領域を認識していないようです。ワードパッドなどでは問題なく表示されます。他のフォント（Code2002等）の指定でも表示されます。--uchi 2010年4月5日(月) 19:58
- あれれ、Win XP Pro SP3上で花園明朝2010年2月22版(gw406595)をメモ帳で使った場合、U+20000とU+22222は表示を確認できています。ほかの方はいかがでしょうか？--kamichi 2010年4月5日(月) 20:56
- Windows 7のXPモード上でのワードパッド、メモ帳（notepad）での花園明朝（2010-07-18版）Ext.B領域の文字表示に問題がないことを確認しましたので、いったん閉じます。--kamichi 2010年8月6日(金) 11:56
グループページで空白のトリミングをするべき --kamichi 2010年3月12日(金) 21:42
- どのような実害があるかを失念してしまったのでいったん閉じます--kamichi 2010年4月26日(月) 21:41
関連字を設定していないエイリアスページでエイリアス先の関連字情報が出ない--kamichi 2010年2月20日(土) 12:23
コメントが検索できない。仕様で片付けてよいか--kamichi 2010年2月20日(土) 00:43
専用エディタで「ゴシック」を選択した場合、複曲線、乙線が表示されません。--uchi 2010年3月1日(月) 00:41
- ゴシックは正式サポート外ということで閉じます。--kamichi 2012年12月6日(木) 22:04
「UCS全漢字w曲線」で生成したフォントをざらっと見てが付いた点を以下に報告させていただきます。- Ⅰ 曲線、ポリゴン関係な。①
u4e59「乙線」の始点うろこの形が2段になっている）
u5973斜めの「直線」の開始のうろこが本体にくっついていない
Ⅱ 曲線のみ（SVGのパスも同じ）。①
u6208２画目の「複曲線」の右ハネが形がおかしい（とめの上半分が無い）。 ②u4e59
u4e5a「乙線」、「折れ」の終点の輪郭が曲線になっていない。
- 修正しました--kamichi 2010年2月16日(火) 12:07
Ⅲ 曲線フォントで。
u475b
u6571
u99ca以上のグリフで白抜けしない（SVGのパスはOK)。FontForgeで重複処理を行った時に外側のパスが反時計回りになったためのようです。--uchi 2010年2月14日(日) 10:12
グリフエディタからの部品検索が正しくできない。Flashにバージョン10.2のβ版(LNX 10,1,51,66)を使っているからかもしれません。他のバージョンではうまく動きますか？--mandel59 2010年2月14日(日) 14:32
- 確認しました。Ubuntu9.10JPRemix上でFlashPlayerのstableでは問題なし、beta10.1ではテキストボックスに入力した値が時と場合により欠けてクエリーに渡されています。同じ入力でも一定しないのでバグではないかと思います。ということで、おそらくエディタ側では対処できないかと。--kamichi 2010年2月14日(日) 17:38
- 閉じます--kamichi 2010年4月26日(月) 18:00
言語間リンクでローカル前頭辞「グループ:」が変換されない--kamichi 2010年2月14日(日) 11:17
- 自分で意味を忘れたので閉じます。--kamichi 2016年1月22日(金) 18:26
「古い部品を引用しているグリフの一括更新」でtypr指定が利いていないようです。--uchi 2010年2月13日(土) 13:17
- 修正しました。ご指摘感謝。--kamichi 2010年2月13日(土) 19:53
ローカライズ機能が変か。書名の1回目は日本語で、2回目は英語で記録される--kamichi 2010年2月12日(金) 17:14
- 変更履歴表示機能の問題か？--kamichi 2010年2月12日(金) 17:15
- これは仕様でした。修正不可とし、閉じます。--kamichi 2013年3月25日(月) 15:11
ドキュメントページの履歴ページで言語間リンクが機能しない--kamichi 2010年2月12日(金) 10:01
- 表示しないように修正しました--kamichi 2010年2月12日(金) 10:12
IVSそのもののグリフを作ってフォント生成してみたのですが、できたフォントにはU+4E00しか含まれていないようです。IVSのグリフをフォントに含めることはできないのでしょうか。--emk 2009年12月25日(金) 07:27
- グループ:異体字セレクタ補助です。--emk 2009年12月25日(金) 07:28
- ご指摘ありがとうございます。フォント生成符号位置対象に入っていなかったので追加しました。これ便利ですね。ただ、グループ:異体字セレクタ補助だけだとMS Wordではwindings系統からでないとフォントの切り替えが有効にならないようです。次の花園フォントで追加してどうなるかやってみます。--kamichi 2009年12月25日(金) 08:14
- 数字グリフというか非漢字グリフをどうするか早く決めないといけませんね…--kamichi 2010年2月20日(土) 00:47
作業依頼になるのでしょうが、
aj1-19071のグリフがおかしくなっています。修正をお願いいたします。--uchi 2009年12月19日(土) 21:28
- ご指摘ありがとうございます。修正しました。予定では管理者権限を持つユーザー（このあたりまだどうするかは全くの白紙ですが）がWebからグリフを再生成できるようにすることを考えています。--kamichi 2009年12月20日(日) 00:16
-
現在、グリフを更新しようとすると internal server error が出ます。 — sayunu 2009年11月7日(土) 18:40
- 特に確認できていないのですが、現在もそうでしょうか？（この投稿は kamichi による）
- どうも一部のグリフで起こる様です。当方、
sandbox は更新できますが、
u5f61-02 でエラーになります。 — 匿名利用者 2009年11月7日(土) 22:16
- ログアウトしたままだった。上の投稿は私です。 — sayunu 2009年11月7日(土) 22:18
- ご指摘ありがとうございます。再現できました。現状では原因不明につき引き続き調査中です --kamichi 2009年11月7日(土) 22:30
- 原因がわかりました。修正しました。--kamichi 2009年11月7日(土) 23:05
- 御苦労様です。 — sayunu 2009年11月7日(土) 23:26
basepartsとエイリアスの入れ替えのautoglyph-botで 同じbasepartsが2つ連なると2つめを変換しないで残ってしまうようです。（
u23855,
u2387d等）--uchi 2009年9月19日(土) 21:49
- ご指摘ありがとうございます。そうなんです。今まであきらめて手動で変換し残しを直していました。今最後の実行を行っているところですが、今後実行することはないのでそのままとしたいと思います。--kamichi 2009年9月19日(土) 21:54
u47e6-ue0100の状態がおかしいようです。グリフページはあるようですが、参照が見ての通り赤くなり、ページ上部の「グリフ」「履歴タグ」が赤くなっています。
- ご指摘ありがとうございます。運悪く一部サイズのグリフ生成に失敗したようです。現状ではページの有無についてグリフファイルの有無でチェックしているため、赤（＝存在せず）と判定ミスしていました。当該グリフを再生成しましたので回復しました。--kamichi 2009年9月9日(水) 23:20
-
バグと言うかは分かりませんが、リンクに空白を含む名前を付けられません。つまり、
[[an useful wiki http://glyphwiki.org]]
- と記述して、リンクに「an useful wiki」という名前を付ける事が出来ません。現在の記法を維持するなら、括弧の中で「最後の」空白を区切りと認識するようにすると良いと思います。
- これはWiki文法の制限です。たしかWikipediaが「空白をアンダースコアで表現する」というルールをそのまま取り入れています。Wikipediaはアンダースコアを空白に変換して表示してくれますが、グリフウィキはその部分は省略しています。wiki文法のデコード部分は他人のコードを使っているので、安全面から余り変更したくないです。それでも、ということでしたら優先度を下げてToDoに加えます。--kamichi 2009年9月3日(木) 21:07
- もしくは「_」を空白に換える機能を追加しても良いです。他への影響はないでしょうか。--kamichi 2009年9月3日(木) 21:09
[[an_useful_wiki http://glyphwiki.org]]
→
an_useful_wiki
- Wikipedia の wiki（MediaWiki）の記法では、外部リンクはこんな風に書きます。なんか色々と違うようです。Help:ページの編集
[http://glyphwiki.org a useful wiki]
- （あと、すいません、英文法がおかしかったです。an ではないです。）
- アンダースコアを空白に換えて表示するのも良いと思います。 — sayunu 2009年9月3日(木) 21:25
- あ、勘違いでした。Wiki名に空白を入れようとするとアンダースコアに変換される、の間違いでした。あまり派生のルールにしたくないので、では、スペースを入れてもいいように変更します。--kamichi 2009年9月3日(木) 21:36
- 変更しました。a useful wiki --kamichi 2009年9月3日(木) 21:57
「旧部品の一括更新」が1つのグリフの更新の後、こけます。--uchi 2009年8月30日(日) 10:58
- 修正しました。ご指摘感謝。--kamichi 2009年8月30日(日) 11:40
複曲線が描画されない場合があります。
u8d1dを編集でプレビューすると一部が消えてしまいます。--uchi 2009年8月26日(水) 19:18
- ご指摘感謝。修正しました。--kamichi 2009年8月26日(水) 21:14
現在、UCS 文字の部品グリフは削除できないんでしょうか? 「0:0:0:0」と入力すると自動的に関連字が〓になり、「〓では投稿できない」とか言われてしまいます。 — sayunu 2009年8月23日(日) 01:28
- すみません。ちょっとここしばらくシステム変更への着手ができない状況にあります。もうしばらくお待ち願います。--kamichi 2009年8月25日(火) 01:34
- 修正しました。--kamichi 2009年8月25日(火) 14:05
下記mashabowさんの項目と関係すると思いますが、Ext-Dの文字（確認したのは
u2b776）が編集できなくなっています。関連字を 座、〓、𫝶のいずれでもエラーではじかれます。--uchi 2009年8月16日(日) 08:39
- 修正しました。--kamichi 2009年8月25日(火) 13:52
互換漢字を編集しようとすると「UCS関連グリフの関連字に別の文字の割り当てや未定義（〓）とすることはできません。別の文字を関連付けたい場合は関連付けるべきグリフに記述して異体字としての関連付けを申請してください。」と表示され、登録できません。--mashabow 2009年8月10日(月) 17:34
- 互換漢字は関連字を（厳密には独立字もありますがその場合は無理やり）CJK統合漢字の方で定めてもらうことを想定しています。いかがでしょうか。--kamichi 2009年8月10日(月) 22:58
- 関連字の選び方についてはそれで問題ないと思うのですが、そのようにすると（例えば
ufa2a の関連字を「飯」にして投稿しようとすると）上記のメッセージが出て撥ねられてしまいます。--mashabow 2009年8月10日(月) 23:12
- 失礼しました。修正しました。--kamichi 2009年8月25日(火) 13:54
専用エディタ上で、曲線→直線など（制御点が減るような）線種変更をした場合、減った点の座標がデータ上にゴミとして残ってしまうようです（実害はないのかもしれませんが）--y-iijima 2009年8月8日(土) 13:57
- ご指摘ありがとうございます。おっしゃるとおり、座標保存用に一旦確保した領域は開放しないのでそうなってしまいます。最終的なデータ出力時に整形する方向で改良します。--kamichi 2009年8月8日(土) 14:14
- 修正しました --kamichi 2009年8月8日(土) 15:18
エイリアスとなるグリフに対して「〓」を割り当ててもエイリアス先のグリフに設定されている関連字が引き継がれていないようです。--uchi 2009年8月8日(土) 09:49
- 修正しました。ご指摘感謝。--kamichi 2009年8月8日(土) 10:05
baseparts-ashiのグリフがダブっている様です。baseparts-ashiのエイリアス化と
u8db3-01の関連字の設定をおこなった事のいずれかが原因と思われます
- ダブって見えるのはu8db3-01ではないでしょうか？u8db3-01がエイリアスかつ関連字を指定しているので関連字情報に2回出てしまっています（ざっと確認した分ではグリフはダブっていないようです）。この場合、どのように関連字情報に表示させると良いか考えていませんでした。ちょっと考えさせてください。--kamichi 2009年8月7日(金) 22:50
- あ、baseparts-ashiも同じ状況なのでダブって見えますね。いずれもデータは正常で、関連字情報の生成でダブっていました。--kamichi 2009年8月7日(金) 22:51
- いちおう直してみました。関連字情報の部分だけを見るとエイリアスの関係が見えなくなってしまうので問題と感じる人がいなければいいのですが、いかがでしょうか。--kamichi 2009年8月25日(火) 21:51
- 上記、やや気になり、kosekiグリフについては「エイリアスかつ同じ関連字を指定」が大量にあったので、個別に全部(900グリフ以上)関連字削除しました。koseki以外はあまり手を付けていませんが、全部合わせても50グリフ以下だと思います。--y-iijima 2009年8月26日(水) 17:27
- ありがとうございます。先の修正で、「エイリアスかつ同じ関連字を指定」の場合は直接指定した関連字のほうだけしか出ないようにしました。ですのでダブることはなくなりましたが、エイリアスである、という情報は関連字情報だけからは見えなくなりました。とりあえず、この方針で行きます。--kamichi 2009年8月26日(水) 21:14
グリフエディターでの編集中、エイリアスではない部品に「→ ○○のエイリアス」という表示が出る場合があるようです。例えば 
u87e9@3 の編集中、右側の部品 
u53a5@4 を選択すると「部品：u53a5 → u5382-05 のエイリアス」と出ます。恐らく、その部品の中で一行目が「99:0:0:0:0:200:200:○○」となっている時、二行目以降を無視してエイリアスと誤認するんでしょうか。この例では 
u5382-05@4 がその位置に配置されています。 — sayunu 2009年8月7日(金) 13:24
- ご指摘ありがとうございます。ご指摘の通り、エイリアスの判定に手抜きがありましたので修正しました。--kamichi 2009年8月7日(金) 13:39
エイリアスを登録する際に、バージョン指定をしていない場合でも「エイリアスの対象グリフはバージョンを指定できません。このままでは登録はできません。バージョン指定を外すか、エイリアスではなく実体化する必要があります（専用エディタで部品を分解してください）。」と表示されてしまいます。登録自体はできるようです。--mashabow 2009年8月2日(日) 17:34
- ご指摘ありがとうございます。修正しました。--kamichi 2009年8月2日(日) 19:06
basepartsをUCS偏化変形に移行する過程で、お互いの旧バージョンにエイリアスを張ってしまった結果、旧部品の一括更新でエイリアス関係が狂っているケースが多数あるようです（まだ全体を把握できていません）。エイリアスではなく実体化してくださるようお願いします。具体的には、一度エイリアスとして記述し、プレビュー時に編集モードに移り、引用部品を選択し「分解」することで実体化できます。--kamichi 2009年8月2日(日) 12:52
- 現在確認が取れているのは、
u53daと
u5382-05の2つです（いずれも修正済み）。このほかにご存知でしたらお知らせ願います。とりあえずエイリアス設定時に旧バージョンを指定できないように変更します。--kamichi 2009年8月2日(日) 13:15
- 変更しました。--kamichi 2009年8月2日(日) 13:35
- またこの件に関して、ご報告＆修正ありがとうございました＞y-iijimaさん --kamichi 2009年8月2日(日) 13:39
u253f5@2が「旧部品の一括更新」でグリフが赤×なっっているようです。svg画像は「パス」「ポリゴン」ともＯＫみたいです
- ご指摘ありがとうございます。合わせて3件再生成しました。パスとポリゴンについても生成できていませんでした（表示されているのはバージョン指定なしなので@1のものでした）。「旧部品の一括更新」機能の安定化が必要ですね。--kamichi 2009年8月1日(土) 18:32
今気がついたのですが、「u****-02」のグリフを自動的に投稿する際、以前利用していたプログラムをそのまま利用した結果、関連字がでたらめになっていました。y-iijimaさん、修正してくださりありがとうございました。グリフ名をそのまま関連字に指定する仕組みになっていたのですが、perlのeval関数がご丁寧に「-02」を計算していました… --kamichi 2009年7月27日(月) 19:01
- いえいえ、私もuchiさんが修正されているのを見るまで気づいていませんでした。個別に修正していたのではラチがあかないと思って全部やっつけたつもりです。見落としがあったら手直しお願いします。--y-iijima 2009年7月27日(月) 21:39
u3696の表示で
u46eeのグリフが3つ出てきています
- ご報告ありがとうございます。うーむ、トランザクションがうまく行っていないのか60個程度のグリフにバージョンのダブり等問題が生じています。解決には少し時間がかかりそうです。--kamichi 2009年7月21日(火) 20:55
- とりあえず手作業でデータを修正しました。また、ダブりがおきないような対策を施しましたが、根本的な原因がつかめていません。こちらは将来的な課題としたいと思います。 --kamichi 2009年7月21日(火) 22:06
- 治ってないようです。旧部品の一括更新で編集競合がエラーにならないせいだと思います。ちなみに私が行った再現テスト方法は、全グリフ選択状態で更新ボタンを押す→すぐにブラウザの中止ボタンを押す→画面上は処理が止まったように見える→また更新ボタンを押す→すぐに中止ボタンを押す→何度か繰り返す、です。
- またデータ修正ですか…。逆に言うと、データベースのトランザクションではなく（仮に一番初めのケースも再読み込み等で同じリクエストを人為的に繰り返したとするならば）、旧部品の一括更新でチェック無しで処理をしてしまっている手抜きに問題があるわけですね。とほほ。なお、旧部品の一括更新は特別な処理にしているので競合は起きません。--kamichi 2009年7月21日(火) 23:59
- 時間があるときに修正ということで、ひとまず機能を無効にしました。 --kamichi 2009年7月22日(水) 00:05
- と思ったのですが、直してみました。前の重複データはまだ修正が終わっていません。--kamichi 2009年7月22日(水) 00:39
- 旧部品の一括更新ができなくなっているようです。（グリフを選択しているのに「更新したグリフはありません」になる）--y-iijima 2009年7月26日(日) 06:59
- 今試したところ更新できました。手元のソースとサーバ上とのバージョンの齟齬があったかもしれません。失礼しました。--kamichi 2009年7月27日(月) 16:10
- 後ろ向きですが、自動的にバージョンや最新フラグに齟齬のあるグリフを探し出し修正するプログラムを作りました。当面は定期的に実行することにします。--kamichi 2009年8月2日(日) 10:47
- dump_newest_only.txtを利用してグリフ数を数えていますが、8/1(21971)⇒8/2(21936)でSIPの文字数が減っており調べたところ8/1のdump内に以下の重複がありました。(ダブり(u289b2 u289ba u289bb u289bd u289c0 u289c3 u289c6 u289e4 u289ea u289eb u289ec u289f7 u289f9 u289fa u289fb u28a00 u28a0e u28a14 u28a1d u28a1f u28a20 u28a21 u28a27 u28a2a u28a2b u28a43 u28a44 u28a45 u28a47 u28a62 u28a63 u28a65 u28a66)、トリプリ？(u28a0f)) この事象による影響でしょうか？ --tsuruki 2009年8月2日(日) 11:41
- ご指摘ありがとうございます。おっしゃる通りと思われます。先ほど重複を修正したので、明日のダンプデータでは解消されているはずです。--kamichi 2009年8月2日(日) 12:43
- dump_newest_only.txt(Sun Aug 09 02:00:02 2009)内に重複が1件
u9243ありました。 --tsuruki 2009年8月9日(日) 07:59
- ご指摘ありがとうございます。チェック・修正したところこの1件だけでした。やはり定期的に自動チェックが必要ですかね。--kamichi 2009年8月9日(日) 10:38
- dump_newest_only.txt(Mon Aug 17 02:00:02 2009)内に重複が4件
u73ee
u73f1
u73f8
u7406ありました。 --tsuruki 2009年8月17日(月) 06:36
- ご指摘感謝。修正しました。自動修正にするとバグそのものを直す気力が減ってしまうのでしばらく手動実行とします。--kamichi 2009年8月17日(月) 23:50
- dump_newest_only.txt(Wed Aug 19 02:00:02 2009)内に重複が3件
u20458
u3c1c
u9a33ありました。 --tsuruki 2009年8月19日(水) 21:14
- いつもありがとうございます。さらに増えて9件、修正しました。--kamichi 2009年8月19日(水) 23:53
- dump_newest_only.txt(Fri Aug 21 02:00:04 2009)内に重複が11件
u232fb
u2502f
u258eb
u25f58
u288f1
u349d
u4be6
u5e6d
u61f1
u881b
u884aありました。すべて
j90-4a4eを含んだグリフです。 --tsuruki 2009年8月21日(金) 06:52
- 修正しました。--kamichi 2009年8月21日(金) 11:16
- dump_newest_only.txt(Mon Aug 24 02:00:02 2009)内に重複が1件
u217d2ありました。 --tsuruki 2009年8月24日(月) 06:43
- 修正。ご指摘感謝。--kamichi 2009年8月25日(火) 01:34
- DBにロックをかける様にしたところ、最新フラグが重複する不具合はなくなったようですが（同じデータで複数回、というのはまだ残っているのでこれは次の段階）、Webの反応が遅いような気がします。現在リクエスト自体もいつもより非常に多いので、原因がどちらか様子見です。--kamichi 2009年8月26日(水) 21:48
- 原因はともあれロックの不可でユーザー認証にも影響が出ているようですね。うーん --kamichi 2009年8月26日(水) 22:31
- スピードが犠牲になっていますが、問題自体は解決しました。スピード向上は別件として今後の課題とします。--kamichi 2009年9月4日(金) 00:13
登録グリフの無い異体字のリンク先が、uXXXX ではなく GlyphWiki:uXXXX になっています。--mashabow 2009年7月15日(水) 13:04
- orz...修正しました --kamichi 2009年7月15日(水) 13:43
koseki-464880の関連字欄に同じグリフが2個表示されています。他の文字では同じ現象を見た記憶がありません。ブラウザを変えても再現します
- ご指摘ありがとうございます。データベースの構造変更作業の際、サービスを停止せずに差し替えたため、その時点で大量に処理されていた一括更新要求をうまく処理できず、一部グリフの「最新」グリフが２バージョン以上存在する状態になっていたため、それを拾っていました。手作業で該当グリフを修正しましたので解決したと思います。--kamichi 2009年6月26日(金) 10:10
ドキュメントの投稿で変更点が無くても投稿できてしまう？--kamichi 2009年6月13日(土) 09:55
- 日本語ロケールで接頭辞を書き換えることによる変更検出失敗が原因でした。修正 --kamichi 2009年6月16日(火) 00:02
RSSフェードでちょっと気になりましたが、今週、匿名利用者によって登録されたグリフが命名ガイドラインに従わないようです。
g7838-1や
g7838-2や
j7836-1などですね。jeroen 2009年6月13日(土) 06:50
- すみません、これは実習の投稿です。来週の水曜以降に削除します。一応命名ガイドラインの範囲外の自由命名にしたのですが、紛らわしかったですね。--kamichi 2009年6月13日(土) 09:55
ダンプアーカイブにREADME_en.txtを追加してくれてありがとうございますが、README_en.txtには、文字化けが出てしまいました。ASCIIではないので、引用符（“と”）が変になってしまいました。UTF-8を文字符号化法にして、正しいバージョンはここにあります：
u9ce5 の2つ目の点が、PNGとポリゴンSVGで欠けてしまっています。制御点と終点のx座標が同じだと欠けるような感じです
- ご指摘ありがとうございます。具体的な情報をいただきましたのですぐにミスが分かり、修正しました。グリフ再生成がなかなか時間がかかるのでちょっとやり方を変えようと思います。反映まで少々お待ちください。これから新規に登録するグリフは直っています。--kamichi 2009年6月2日(火) 23:00
- 最新グリフが変にならないように修正した全グリフ再生成プログラムを実行中です。とても遅いので丸1日程度かかると思います。--kamichi 2009年6月2日(火) 23:07
- 再生成が終わりました。30時間ぐらいかかりました。--kamichi 2009年6月4日(木) 23:37
現在「dump.tar.gz」において、ファイルが二つあります。「dump.txt」は、グリフの最新のデータのみ、「dump2.txt」すべてのバージョンが含まれたものです。しかし、「dump.txt」に定義されたグリフは、他のグリフの特定なバージョンを引用する場合もあるので、「dump.txt」だけを使ったら定義のないグリフがあります。（例：「u64c1」が「baseparts-tehen@3」を引用しています）そういう引用された部品の数が少ないようので、「dump.txt」に含めばいかがでしょうか？jeroen 2009年6月1日(月) 21:03
- ちょっと考えます。個人的には現状どおり（以下の通り）がいいと思っています。--kamichi 2009年6月2日(火) 18:04
「dump.tar.gz」において、「LICENSE」や短い「README」などという情報を含めばいいかもしれません。もしアーカイブの構造を変えれば、「dump.txt」と「dump2.txt」を「dump_newest_only.txt」と「dump_all_versions.txt」にすると、それぞれの機能もファイル名だけで明らかになると思います。jeroen 2009年6月1日(月) 21:03
- ご提案ありがとうございます。さらにデータを活用するための情報の追加なども含めた変更を行いたいと思います。--kamichi 2009年6月2日(火) 18:04
- 変更しました。--kamichi 2009年6月4日(木) 23:37
存在しないバージョンを表示できてしまう。--kamichi 2009年5月30日(土) 11:50
- 修正 --匿名利用者 2009年6月15日(月) 22:49
u6998の修正を投稿した所、受け付けてもらえませんでした。また上部の「解説」「履歴」が赤で表示され、所属するグループも赤×での表示になってます
- すみません。DBの同時処理がうまくできていないのかもしれません。u6998は手動で再生成しました。もう一度投稿していただければと思います。--kamichi 2009年5月30日(土) 01:43
- 再度投稿したところ、また同じ状態になりました。uchi 2009年5月30日(土) 11:34
- すみません…、調べます。--kamichi 2009年5月30日(土) 11:50
- また凡ミスでした。修正しました。ただ、かのページのリンクが赤くなっていた件についてはちょっと原因がわかりません。ひきつづき様子を見たいと思います。--kamichi 2009年5月31日(日) 20:51
「フォント生成」で表示されるページ（Group:***?action＝makettf）において、リンクの色がおかしくなっています（既存ページが class＝"newpage" になっている）。--mashabow 2009年5月28日(木) 19:27
- ご指摘ありがとうございます。当方で確認ができないのですが、すべてのGroupページでしょうか？ドキュメントページの存在チェックはSQLクエリを発行しているのですが高負荷で失敗しているとかですかね。--kamichi 2009年5月28日(木) 22:23
- グループ:mashabow_base90です。もう一度試してみましたが、同じ症状でした。関係があるのかわかりませんが、フォントの生成もうまくいっていないようです。--mashabow 2009年5月28日(木) 22:50
- 確認できました。やはりDBへの接続が以上終了し、その後のアクセスができなくなっています。現状では原因にたどり着けなかったので、また時間を見つけて調べます。どうもすみません。--kamichi 2009年5月29日(金) 00:53
- 理由が分かりました。1文字誤って消してしまったためでした。それで修正し、フォントは生成できるのですが手動ヒントのエラーが多発しています。引き続き原因の調査に当たります。--kamichi 2009年5月29日(金) 23:26
- ヒンティング関連のエラーは原因が分かりましたので修正しました。丸め処理の誤差で数個程度エラーが残るようです。--kamichi 2009年6月1日(月) 11:09
svgのグリフ(ポリゴン/パス両方)の点に細く繋ぎ目の線が見えます(例えば
u706cの各点)。一つのポリゴン/パスにするのが良いと思います。--匿名利用者 2009年5月28日(木) 17:54
- まだ優先度は高くないですが問題は認識しております。ご指摘ありがとうございます。--kamichi 2009年5月29日(金) 00:54
- 今後の予定にあるので閉じます --kamichi 2009年6月15日(月) 23:24
エディタのバグ：直線を乙線に変えたときに、制御点が二つにならない。その後編集を終了しても、何も出ない。--mandel59 2009年4月29日(水) 21:25
- ご指摘ありがとうございます。確認してみましたが、私の手元では再現できません。恐れ入りますが、その現象が生じるKAGEデータを教えてください。なお、厳密には乙線は制御点は1つで、合計3つの座標で表現されます。よろしくお願いします。--kamichi 2009年4月29日(水) 22:03
- 保存されているグラフをエディタで開き、直線を乙線に変えると起こります。エディタ上で、一度別の曲線に変えていたり、「手書き」で新たに作った直線では起こりません。（訂正：「制御点が二つにならない」→「ガイドポイントが二つのまま」）--mandel59 2009年4月30日(木) 00:44
- 反応わるくてすみません。症状確認しました。次直します。--kamichi 2009年5月2日(土) 09:41
- 修正しました。だいぶ時間がかかってしまいました。--kamichi 2009年6月17日(水) 14:51
sandbox@147 右払いの尾形状を使う曲線では、コントロール座標と尾座標が縦軸で重なると、例のような現象が出ます
- うーん、2:7:0の曲線で座標1と座標3を結ぶ線分より座標2が右上に来ることはありえないと思います。ですので、仕様外ではないかと思います。この形状を使う実例はありますでしょうか？--kamichi 2009年4月6日(月) 23:42
- ダンプによるとほとんどなさそうです。（例外：
u0028）確かに、仕様外として扱っても問題になるはずないと思います。jeroen 2009年4月8日(水) 03:14
- 調査ありがとうございます。u0028は2:7:0よりも2:7:8がよさそうですね。--kamichi 2009年4月8日(水) 07:19
日本標準時はJTCではなくJST(Japan Standard Time)です。--emk 2009年4月2日(木) 07:36
- すみません…。すでに記憶がないんですが、UTCに引きずられましたか。次直します。--kamichi 2009年4月2日(木) 10:37
- 修正しました --kamichi 2009年4月5日(日) 11:28
Wiki名のルールが統一されていない。説明では2字以上、実際は5字以上(UCS最短に拠ると思われる）。記事ページは1字以上 --kamichi 2009年2月24日(火) 16:02
- 今後の予定に移動しました --kamichi 2009年6月15日(月) 22:57
あるグリフの最新エイリアスグリフを引用していて、かつ、その引用エイリアスが更新されているものである場合、2009-02-20_09:46以前のものはバージョンが間違っている可能性があるので抽出して直す必要がある--kamichi 2009年2月20日(金) 09:48
- チェック完了。各グリフ最新版については問題なし。旧版の数個については影響が小さいので放置。--kamichi 2009年2月20日(金) 16:19
エイリアス元の部品が変更してもエイリアス先を含むグリフが古くならない--kamichi 2009年2月20日(金) 08:48
修正、しかし、いままでの分が更新されていないので影響が大きい…--kamichi 2009年2月20日(金) 09:46- 上記のとおりチェック完了。--kamichi 2009年2月20日(金) 16:19
グリフエディタの部品検索で削除グリフも出てくる--kamichi 2009年2月15日(日) 23:15
u6ac9や
u78bfなどを作成しようとした際に、グリフエディタ右側に部品の候補は表示されるのですが、それをクリックしても部品がキャンバスに出てきません。環境は Firefox 3.0.6, Adobe Flash Player 10.0.12.36 です。IE7でも再現します。上記とまったく同じ体験をしています。今朝、朝7:00～8:00にグリフ作成をしていたときにはこういう問題はありませんでした。-- golconda 2009年2月14日(土) 01:01
- 修正しました。大変ご迷惑をおかけしました。部品数拡張の際、別のバグの解消に気をとられ、動作確認が完全ではありませんでした。申し訳ありません。--匿名利用者 2009年2月14日(土) 03:32
IDSに「鸟」が含まれていても、グリフエディタの候補に
u9e1f-01
u9e1f-02
u9e1f-04が表示されません（
u9e1fは表示されます。また、u9e1fなどで検索した場合は部品もちゃんと表示されます）。「鸟」に限らず、他にも表示されない部品が存在するようです。--mashabow 2009年2月13日(金) 01:40
- ご指摘感謝。修正しました。部品が多くなってきたのでどの部品を出すかについては、近いうちに整理してみなさまのご意見を伺いたく思います。--kamichi 2009年2月13日(金) 09:58
u72ac-04において、大きく曲がった「縦払い」で隙間が発生しています
- 認識しています。修正対象です。--kamichi 2009年2月7日(土) 22:13
- 今後の予定に移動しました --kamichi 2009年6月15日(月) 22:57
u5e23において、旧部品の更新がうまくいっていなかったようです（@2, @3）。KAGEデータが「99:0:0::0:200:155:u20509@1」となっていたのが原因でしょうか
- ありがとうございます。これは投稿時にKAGEデータのチェックをきちんと行うということで対処したいと思います。--kamichi 2009年2月4日(水) 21:49
- 変なデータを作成してしまい、どうもすみませんでしたuchi 2009年2月7日(土) 11:57
- どうぞお気になさらずに。--kamichi 2009年2月7日(土) 22:13
- チェック機構について、手が回らないので今後の予定とします --kamichi 2009年6月15日(月) 22:51
「讠纟马鸟」を基に自動生成されたグリフについて、これらの部分はバラバラの筆画として表現されているようですので、機械的に一律に部品へ差し替えてはいかがでしょうか。また、「车鱼」を偏に持つグリフは自動生成されていないようなので、こちらの生成もできないでしょうか。--mashabow 2009年1月24日(土) 16:27
- まず、過去何回か行った自動生成について、部品ではないグリフについても使ってしまったのは失敗だったと認識しています。先に部品化をやるべきでした。プログラムを直すのが面倒だったのでまだ修正はできていません。--kamichi 2009年1月25日(日) 09:55
- 次に機械的に修正する、というご意見ですが、同意します。プログラムの作成に着手します。--kamichi 2009年1月25日(日) 09:55
- 最後にこれらが完了したら自動生成をもう一回行いたいと思います。--kamichi 2009年1月25日(日) 09:55
- 手が回らないので今後の予定とします --kamichi 2009年6月15日(月) 22:51
ほかの漢字フォント（IPA Mincho, Kochi Mincho）を見れば、「五」や「吾」などの部品では、その上から下までの斜め直線の頭形状は「接続（縦）」にしたほうがいいのではないかと思っています。自分のDrawFontでも試したが、今の「開放」頭形状はあまり合わないと思います。「接続（縦）」に変えたいですが、よく使われている部品なので、ご意見は？ jeroen 2009年1月19日(月) 15:49
- ご指摘ありがとうございます。気がつきませんでした。理由としては（１）デザイン者が縦接続の概念を理解していなかった（２）参考字体がそうなっていた、のどちらかだと思います。平成明朝のデザインにあわせ、平成明朝が縦接続になっていれば影響が大きいとしても直すべきと思います。--kamichi 2009年1月19日(月) 16:01
- 私は平成明朝がないので、確認できませんけど… jeroen 2009年1月19日(月) 22:47
- 平成明朝（＝規格票）も接続しているので修正対象になります。--kamichi 2009年1月22日(木) 11:56
- 一点補足します。デザイナが参考にした字体は離れていました(開放形状)。参考にしているのは「明朝体活字字形一覧」の古いもの（著作権の制約を考慮しなくてよいもの）です。--kamichi 2009年1月23日(金) 10:13
- ありがとうございます。参考になります。立教大学の図書館でもありそうなので、明日ちょっと見に行こうと思っています。jeroen 2009年1月23日(金) 18:27
「おまかせ表示」で「eval137-4」というタイトルだけの項目が表示されました。バグと言うほどではないと思いますが報告させていただきます。--uchi 2009年1月17日(土) 05:52
- ありがとうございます。中身が「0:0:0:0」のグリフを対象外とするのを忘れているようです。修正します。--kamichi 2009年1月17日(土) 11:55
- 修正しました。--kamichi 2009年1月22日(木) 11:56
- 再現しています。uchi 2009年2月7日(土) 17:40
- 原因がわかりました。DBの構造の修正が必要なので少し時間がかかります。--kamichi 2009年2月7日(土) 22:13
- 修正しました。--kamichi 2009年5月28日(木) 16:11
「u22a0b」のようなグリフは珍しいそうですが、ストロークの方向を逆にすると、ウロコなどが変になります。
現在登録されたグリフ：
u22a0b バグ例：
sandbox@115。
これはテストだけですが、直線の場合には：「 http://jeroenhoek.nl/research/gwdftool.png 」こういう風書かれるといいかもしれません。jeroen 2009年1月16日(金) 13:12
KAGEエンジンの理念として、実用的な範囲でなるべく単純化する、というポリシーがあります。それでExt.B集合も含めると、現状のKAGEエンジンで表現できないグリフのタイプが（１）ミラーリング（２）篆刻体の等幅、の2つあります。当初これらは「明朝体の範疇外」として無視するつもり（そのため変になる）でしたが、皆さんが無理やりデザインしてくださっていた（もちろん、ありがたく思っています）のを、そのままにしている、というのが現状です。--kamichi 2009年1月16日(金) 15:32
それで、ミラーリングについては、無理に逆さ字形も対応するのではなく、単純にポリゴンを行列変換で回転させる手法をとるのが理想的と思っています。ですので引用「99」の次に「0」は回転なし、「1」は時計回りに90度、「2」は180度、「3」は270度、という機能を加えることにしたいと思います。対応時期については、まだ優先度が低いです。--kamichi 2009年1月16日(金) 15:32
回転機能について、それは優雅なアプローチだと思います。jeroen 2009年1月16日(金) 20:01
ちょっと手が回らないので今後の予定とします。--kamichi 2009年6月15日(月) 22:51
空グリフの編集モードで専用エディタ起動のボタンが表示されない --kamichi 2009年1月16日(金) 12:28
GlyphWikiによる生産されたSVGファイルは、「width」と「height」という属性がないので、Inkscapeなどで開いたら、ページのサイズが定義されていません。ゆえに、ページはデフォルトのA4になります。SVGのXMLに次のを追加するといいと思います。--jeroen 2009年1月13日(火) 14:05
<svg [...] width="200px" height="200px" viewBox="0 0 200 200">
- SVGファイルは主対象がFontForge向けなので敢えてwidth,heightを定めていないのだと思います。FontForgeでも問題なく読み込めて、Firefoxでの表示や、一般のSVG編集にも支障が出ない組み合わせについて検討してみます。--kamichi 2009年1月13日(火) 16:17
- 「width」と「height」はページのものなので、確かに、FirefoxやFontForgeなどはそういう属性が使いません。ところが、今、FontForgeで試してみましたが、「width」と「height」は無視されたようです。私はKageやGlyphWikiの分析のため、Inkscapeで開くことが多いので、ちょっと気になりましたが、kamichiさんが言った通り、主対象のFontForgeに影響を及ぶと良くないと思います。jeroen 2009年1月13日(火) 16:51
- フォント生成に影響が出ないことを確認しましたので、修正しました。--kamichi 2009年5月28日(木) 16:11
UCS符号位置以外のグリフ名では含まれるグループが出ない --kamichi 2009年1月8日(木) 08:30
- 現象が再現できないのでいったん閉じます。--kamichi 2009年1月16日(金) 15:45
ドキュメントページで1行目をバーベイタム指定できない --kamichi 2008年12月30日(火) 09:04
-
「漢字」ではないので、バグかわざとかわかりませんが、康煕部首のグリフは、関連字が登録できません。 jeroen 2008年12月28日(日) 16:00
- GlyphWikiでは漢字ではないと定義しているため関連字に康煕部首の符号位置を指定できないのは仕様です。--kamichi 2008年12月30日(火) 09:04
-
英語のナビゲーションメニューでは、「おまかせ表示」は今、「Random article」と呼ばれていますが、「Random glyph」のほうがいいかもしれません。 jeroen 2008年12月17日(水) 15:28
- 現状ではドキュメントページやグループページも表示の対象なのでarticleとしていますが、確率的にはほとんどグリフではあります。いっそのことグリフだけにするのも手ですね。検討します。--kamichi 2008年12月18日(木) 14:38
- ということでグリフだけに限定し、メッセージも変更しました。 --kamichi 2008年12月31日(水) 14:47
-
英語をインタフェース言語として使うパソコンでは、GlyphWikiのメインページなどは日本語版と異なることがあります。それはやむを得ないが、自動的に選ばれた英語版から簡単に日本語版へ行くことが出来なさそうのです。確かに、ブラウザーの言語設定を変えると、日本語版が出ますが、ほかのウェブサイトにも影響があるので、ちょっと不便だと思います。ほかの言語のページがあれば、WikiPediaと同じようにそのページへのリンクを生成出来ませんか？ jeroen 2008年12月16日(火) 20:57
- ご意見ありがとうございます。言語ごとにデータが異なるWikipediaと異なり、GlyphWikiでは言語の区別無く同じデータを参照し、インターフェース言語のみを複数用意する予定としています（ただしこれは議論があって、デザイン感覚が異なる地域ごとにデータを分けるべきだという考えもあります。私としては、他の地域では他の人が独立してGlyphWikiクローンを運営してくれれば良く、足りないグリフについては互いに融通しあうようなことができればよいと思っています）。
- それで、言語インターフェースについては、ご指摘のようにブラウザの言語優先度を元に切り替えています。逆に、ブラウザの言語設定というのは利用者の意思ですので、他のページは英語でGlyphWikiだけ日本語が良い、という感覚が残念ながら私には理解できません。現状では言語の切換はWebサーバの機能に任せてしまっているので手動で切り替えるというのが難しいのですが、改善できるよう考えてみます。--kamichi 2008年12月17日(水) 09:32
- 詳しいご返事、ありがとうございます。英語のインターフェースまで用意してくれたのは、見事と思います。もちろん、グリフのデータは同じなのですが、GlyphWikiにある情報ページ、つまり、メインページや「よくある質問」などというページでは、内容が異なっています。例えば、Flashで作ってくれたチュートリアルは英語版からリンクされていないのです。確かに、日本語のできない人にとって、日本語のチュートリアルはあまり使えませんが、日本語も英語もできる人にとって今の状況では、日本語版があるということは英語版から見えません。
- すみません、私はこういう避難ばかりの話だけであまり助からないし、自己紹介せずに失礼いたしました。よかったら、私がこれからヘルプページの内容を少しずつ英語に翻訳してみます。jeroen 2008年12月17日(水) 11:05
- ありがとうございます。そういえば、Web UI部分の英語翻訳は大分できているのですが、肝心のドキュメントページについてはご指摘のように全く進んでおりませんでした。翻訳を手伝っていただけるととても助かります。チュートリアルなども英語(多言語)化が必要ですね。優先度を上げようと思います。加えて、どの作業が必要か、といった一覧を用意するようにします。--kamichi 2008年12月17日(水) 11:32
- 英語のGlyphWiki:FAQを最新の日本語版を踏まえて翻訳しました。最初版なんですが、いかがでしょうか？ jeroen 12:41, 17 December 2008
- ありがとうございます。満足しています。ところでFAQの内容は運用側(私)が勝手に考えているだけなんですが、もっと必要な項目がありましたら提案していただけると幸いです。--kamichi 2008年12月18日(木) 14:38
- ページUIの言語をドメインの区別で行うように変更しました。ただしデータそのものは各言語共通です。 --kamichi 2008年12月30日(火) 19:46
ウィキが使う日付では、１２月は「Decemder」になったが「December」のほうが正しいと思います。（例：ページ歴史で見える、このコメントの後ろに自動的に生成された「名前・日付」もそうなんですが、英語をインタフェース言語として使うパソコンだけかもしれません） jeroen 13:22, 16 December 2008
- プログラム入力ミスでした。修正しました。ご指摘ありがとうございます。
-
グループに存在しない文字を貼るとエラーが起こる（プレビュー時だが、保存してもエラーになるかもしれない。例→［[兛]]）mandel59 2008年11月18日(火) 22:41
-
訂正、存在するしないに関わらず、［[異常な文字]］とするとエラーになる？mandel59 2008年11月18日(火) 22:43
- 修正しました。ご指摘感謝--kamichi 2008年11月19日(水) 18:26
自動生成されたグリフの字形について（バランスはおいておくとして）、以下の点が気になります。--mashabow 2008年11月6日(木) 00:19
u28ef7 など、部品「康」のハネが欠けている
u21f51 など、部品「黽」の中の横画が突き抜けている
u20325 など、「烏」が「鳥」になっている- IDSデータを元に生成するのですが、たまたま採用した部品データに間違いがあるとすべてに反映されてしまいます。当面手作業での修正を考えています。次の段階として一括修正を用意するつもりです。また「検索」機能にキーワードと指定した漢字を部品として含む文字の抽出をできるようにする予定ですので、多少探しやすくなると思います。 --kamichi 2008年11月14日(金) 12:10
- 検索機能を拡張して、上記3種については手作業で直しました --kamichi 2008年12月12日(金) 16:34
エイリアス設定時に余計な改行があるとエイリアスと認識されない--匿名利用者 2008年10月18日(土) 22:45
新規ページなどのメッセージ内でロケールがen固定 --kamichi 2008年7月27日(日) 17:42
- 検索の接頭辞を多言語に対応
- 英語時に編集競合で自分の編集グリフが出ない？
- 今後のスケジュールに移動 --kamichi 2008年12月31日(水) 14:52
sandboxが変。リンクも赤色になる--kamichi 2008年10月15日(水) 20:42
- ファイルのオーナーに不具合。修正。原因不明なので様子見--kamichi 2008年10月15日(水) 20:52
エイリアス設定の際、対象グリフが存在しなければエイリアスを設定しないべきか--kamichi 2008年10月15日(水) 10:37
- 対象グリフがなければエイリアスを設定しないようにした--kamichi 2008年10月15日(水) 15:37
旧部品一括更新で占有グリフ（先頭にユーザー名がつくもの）も他者が更新できる（mandel59さんごめんなさい） --kamichi 2008年9月23日(火) 00:34
- 修正しました--kamichi 2008年10月15日(水) 20:38
ウロコ大きさ調整で上部に対してまたぐものだけを対象にするべき --kamichi 2008年9月6日(土) 01:02
- 修正しました --kamichi 2008年9月6日(土) 23:12
検索でページ名として「グループ」が無視される --kamichi 2008年7月24日(木) 15:08
グループ引用などの表示がenロケール固定 --kamichi 2008年7月27日(日) 15:59
グループページで、他のグループを引用する時に「グループ:」とすると無視される --kamichi 2008年7月24日(木) 14:52
グループ:ごった煮のページにあるフォントのnameテーブルを覗くと、なぜかアラビア語のレコードが入っています。--emk 2008年7月16日(水) 21:59
- 前に生成フォントのOS対応で試行錯誤した時に加えたLCID 0x401がそのまま残っていました。削除します。--kamichi 2008年7月16日(水) 22:26
- 修正しました。 --kamichi 2008年7月24日(木) 16:04
英語版で？署名ができない--kamichi 23:28, 14 July 2008GlyphWiki:MainPageが編集プレビューできない？--23:27, 14 July 2008
- 途中で日本語ロケールを英語ロケールに換えたため、で仕様。署名は勘違いの模様。 --kamichi 2008年7月15日(火) 11:10
SVGやEPSのポリゴンがバラバラすぎる --kamichi 2008年6月6日(金) 08:11
他のグループから引用されているグループの更新をしても、引用先はそのままなので、内容に齟齬が生じる --kamichi 2008年6月6日(金) 08:11
preview画像生成時に同時アクセスの他の画像と混ざっている可能性あり。排他処理ができていないのか --kamichi 2008年6月6日(金) 07:56
- 問題無し。ブラウザのキャッシュが原因か --kamichi 2008年6月7日(土) 11:36
生成されるフォントのサイズが変です。http://f.hatena.ne.jp/mandel59/20080603192432 --mandel59 2008年6月3日(火) 19:26
- 次項のSVG形式のデータ記述を変更したためでした。すみません。ひとまず巨大にならないように修正しました（逆にこころもち小さめになったかもしれません）。フォントの種類によって文字の大きさが微妙に異なるため、どれに合わせるか難しいところですが，大きさの微調整はこれから施します。 --kamichi 2008年6月3日(火) 20:00
- 大きさはそのままとし、位置を修正しました。MS明朝と合わせるようにしています。GlyphWikiの問題点として，グリフのボディサイズがまちまち（デザイン時に明確なガイドを示さない）なのですが、今後の検討課題です。 --kamichi 2008年6月5日(木) 11:21
SVG画像にサイズの情報が含まれていなく、リサイズが不便です。 --匿名利用者 2008年5月29日(木) 14:16
- ご指摘ありがとうございます。サイズ情報というのは<svg>のwidth, height属性のことでしょうか？また、リサイズする、というのはどのアプリケーションでのことでしょうか。現状では私の知識不足で、<svg>のwidth, height属性を追加するぐらいしか対応ができません。 --kamichi 2008年5月29日(木) 14:30
「比率（左を大きく ←→ 右を大きく）」右と左が逆です。--mandel59 2008年5月28日(水) 22:24
グリフのデータエラーがあるとSVGファイル生成においてJavaScriptによりNaNが発生する --192.168.11.2 2008年1月19日(土) 17:51
アカウントの作成に異様に時間がかかる？（トランザクションが失敗している？） --192.168.11.3 2008年2月13日(水) 00:41
アカウント登録が無効になっている。要修正 --192.168.11.3 2008年2月21日(木) 23:17- 修正。--192.168.11.3 2008年2月21日(木) 23:26
グリフエディタの領域選択においてストロークを内接する矩形にかかるだけで選択してしまう？--192.168.11.2 2008年1月19日(土) 23:24
- 修正。--219.165.239.106 2008年2月22日(金) 10:17
Internet Explorerでマルチバイト文字を含むページへのリダイレクトがうまくできない
- 修正 --192.168.11.3 2007年11月28日(水) 00:24
筆画を選択中にテキストボックスのテキストの一部を選択しようとすると、マウスの移動に伴って選択中（青色表示）の筆画が移動してしまう --61.211.150.156 2007年11月26日(月) 20:39
- 修正。本来はテキスト操作時のマウス移動を無効にすべきですが、将来大幅に書き直す予定の部分にかかっているので、今回は単純にマウスカーソルの位置によってマウス移動を無効にしました --192.168.11.3 2007年11月28日(水) 08:51
グリフエディタで部品を筆画に分解したときに入れ子の部品名がNaNになってしまう --192.168.11.3 2007年11月23日(金) 09:01
- 修正 --192.168.11.3 2007年11月23日(金) 09:12
1:22:0の角度が浅いものがまた表示できない。2回目 --192.168.11.3 2007年11月22日(木) 12:15
- ファイル差し替えミス。解決 --58.93.36.201 2007年11月22日(木) 19:29
グリフエディタを通過すると要約が引き継がれない --192.168.11.3 2007年11月22日(木) 10:03
- 通常、要約は編集後に記述するので仕様とする。--219.165.239.106 2008年2月22日(金) 09:38
グリフエディタで筆画種別12番が処理できていない --61.209.168.169 2007年11月21日(水) 16:39
- 12番そのものを廃止 --192.168.11.3 2007年11月22日(木) 10:28
最近の更新の件数リンクは20件はないのか？選択件数はリンクをはずす。本家を確認する。 --192.168.11.3 2007年10月30日(火) 20:58
- 本家に合わせる修正 --219.165.239.106 2008年2月22日(金) 09:44
RSS
u725a http://en.glyphwiki.org/glyph/u725a-g.svg. 
u725a-g. For example in http://en.glyphwiki.org/glyph/u725a-g.svg 
umbreon126_sandbox@33 
sandbox@2317 
sandbox@2318 
sandbox@2319のように。 umbreon126 2015年8月22日(土) 11:57
u2bd95@7 quotes 
u8425 but render differently
kp1-3fb9@2 quotes 
u5705-g02 but render differently
u2aa5b become corrupted after update of 山 only
sawn-f50d1 become corrupted after update of 山 only
u5d0f-g become corrupted after update of 山 only
koseki-365420 become corrupted after update of 艸 only
koseki-365880 become corrupted after update of 艸 only
koseki-364730 become corrupted after update of 艸 only
koseki-364550 become corrupted after update of 艸 only
u9974-g, 
u9974, 
u2159a, 
zihai-146619, 
zihai-143633, 
u29730, which is edited by other users, are also corrupted now.
u2bdacの異体字に
uf53f（private use）があります
u0000の「前の符号位置」に
kokuji-no-jiten-0532しか更新できなくなった（変更履歴をご覧なさい）（って、実はu65e5-01@3はu65e5-01にならなかった）。でも、手動はできる（例え：
nyukan-f098@2）（できなくなった＝Special:Recentchanges?view=50&hideauto=0&user=umbreon126）。おかしすぎる== --umbreon126 2014年9月7日(日) 16:47
umbreon126_u3134は
umbreon126_u3137で引用していますが
umbreon126_u3132も同じ事ようです。）umbreon126 08:29, 13 August 2014
koseki-367230は
koseki-309170@8を引用していますが、行の最後に:0:0:0がついているため、Special:Mustrenewには表示されていません。 --johotogoshinentai 2014年2月25日(火) 21:43
sat_g901765、
koseki-380260、
u2ff0-u66f4-u6587が「このグリフを内部で引用している他のグリフ一覧」に表示されますが、「部品グリフを別のグリフに置き換える」をクリックして部品を一括更新しようとすると、
u9647@5は引用している他のグリフが3グリフありますが、http://glyphwiki.org/wiki/Special:Renewall?view=listup&target=u9647@5 
u24d21-jv@1で
u7530を分解すると
u758b-04-itaiji-002が消滅し，
cdp-8d52を分解すると
sandbox@1145のようになります。--spinda-kkmr 2013年2月10日(日) 10:34
baseparts-ki-btmや
baseparts-u353eの様な削除済みのグリフが検索されます
u6728で、
baseparts-(u353e) は
u72afで出現します。他にも同様な削除済みのグリフがあるようですが、記録していないので具体例を示すことができません。 --uchi 2009年7月15日(水) 20:24
aj1-13523@2, 
u2090e-ue0100@2 --mashabow 2009年5月10日(日) 22:15
u88e6を作成しようとした際に、
u27607は表示されますが
u27607-04は自分で検索しなければ出てきません（Ext B だから？）
baseparts-koromo-btm・
u8863-04・
aj1-13640）の「
u4ea0と
aj1-15319@2 → 
aj1-15319@3, 
aj-13482@2 → 
aj-13482@3 --mashabow 2008年10月12日(日) 18:42
u9acdの上はねが変
u5cb3-g
u5cb3-t
u5c71-t04
u5c71-g04
u10ffff
u4e44
