GlyphWiki logo
導航
幫助
搜索

工具箱
其他語言
文章討論編輯歷史

GlyphWiki:バグ報告

字形維基(GlyphWiki), 自由的字形數據庫

目錄

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

記述は、新しい項目を上にして、項目ごとに1行空行を入れ、見出しを立ててください。（見出し冒頭の凡例…（【】未記述）：未着手、問題再発生　【修正済】：管理者により修正済）

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

アーカイブしたものはバグ報告-保存を参照してください。

たまにGlyphWikiののサーバーにアクセスできなくなる

ここ数日、GlyphWikiにアクセスしようとするとたまに「サーバーの応答が停止しています」と出てページが表示されないことがあるようです。--kesuuko 11:02, 9 November 2023

一部UCSソースに関連字が自動入力されない

UnicodeのSソースやKPソースのグリフを作成する際、関連字がデフォルトで入力されません。--kesuuko 10:26, 23 September 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)

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

(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年

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

  • 「部品の一括更新」（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

    • 先ほど↑の行をこのページに書き込んだのですが、「最近更新したページ」に表示されていないようです。--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

2021年

  • 自分所有のユーザー専用グリフのあいだのエイリアス交換ができません。--jjanggu2021.09.11 16:19
    • まだチェックしていないのですが、これはニーズとして必要でしょうか。ちなみにユーザー占有グリフ同士だけができないのか、片方でもユーザー占有だとできないのか、どちらか判明していれば教えて欲しいです。--kamichi 2021年9月25日(土) 19:48
    • 失礼しました。交換対象は双方ともユーザー占有グリフで自分所有です。--jjanggu2021年9月25日(土) 20:17

  • kage-editor を少しだけ改良しました。翻訳ミスなどがあればお知らせください。Pull Request --graphemecluster 2021年4月14日(水) 17:06

  • u5317-h01のpng画像で、2画目が何故か3画目の下に飛び出ているかのように表示される。--kesuuko 2021年2月11日(木) 23:27

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@6199）。また、SVG画像を拡大してよく見ないと分からない程度ですが左ハネ付近で太さが揃っておらず段差が生じています（u9725@12の下などは段差が見えやすいでしょうか）。―twe 2020年8月30日(日) 00:22

  • 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

  • バグとまでは言えませんが、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

  • 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年以前

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

  • 半角のグリフを異体字セレクタを使用してフォントに入れようとすると全角になってしまう。(字表: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
      • ここまでの分は解決済みとして閉じます。--kamichi 2023年8月31日(木) 15:05
  • (インデント戾る)フォント生成では、 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@1とextf-06495@1が一時的に「最近更新したページ」で赤い×印になっていました。いったん白紙化してその後復旧したところ@1が遡って正常化しました。--spinda-kkmr 2016年8月3日(水) 19:32
  • ご指摘ありがとうございます。KAGEデータに問題がない場合の「赤い×」は投稿時のサーバ負荷が高く、タイムアウトした結果、最後まで登録作業ができなかったものと推測します。現状でデータ投稿時の負荷が非常に高いので（いままで閲覧時の負荷低下にしか注力してこなかったため）どうにかしないといけないとは認識しています。--kamichi 2016年8月3日(水) 21:38
  • 閉じます。--kamichi 2023年8月31日(木) 15:06

  • １字フォントでグリフの右に余計な隙間ができる。グループページでは問題なし。両者の生成過程を比較して修正すべき。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
    • UTF-8に移行済みのため、閉じます。--kamichi 2023年8月31日(木) 10:50

  • RSSを更新したときの投稿者が利用していた言語でページprefixが記述される。仕様をどうするか。--kamichi 2016年3月11日(金) 00:06
    • 正直なところRSSのニーズは低いと思われるため、このままとして閉じます。--kamichi 2023年8月31日(木) 15:50

  • ユーザー専有グリフ 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

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


最後修訂於2023年11月9日(星期四) 11:02. 著作權與許可協議 隱私政策 關於字形維基 免責聲明