GlyphWiki logo
ナビゲーション
ヘルプ
検索
ツールボックス
他の言語
利用者ページノート編集履歴

利用者-会話:twe

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

GlyphWiki dump 検証 に関するバグ報告など

  • GlyphWiki dump 検証 の「命名」で、最近定義された命名が不正な命名とみなされてしまっています。具体的には、次の命名が挙げられます。
t##-####CNS11643の16字面以降
irg2017-#####CJK統合漢字拡張候補IRG Collection 2017
u####-sans-var-###サンセリフ体
u1####-us旧規格票字形(SMP)
  • 以上。--kesuuko 2018年8月13日(月) 03:13
    • ご報告ありがとうございます。c11-XXXX, c13-XXXX, irg2017-#####を規則に追加しました。u(X)XXXX-sans-(var/itaiji)-###が違反にならないようにしました。
    • 「u1XXXX-us:旧規格票字形(SMP)」は定義されているでしょうか? -usは「現在の複数表記になる前の1欄表記の字形」という定義はあります(GlyphWiki:prefix)が「旧規格票字形」という定義は無いようです。―twe 2018年9月17日(月) 14:24
      • 「u1XXXX-us:旧規格票字形(SMP)」の定義はu301c-usゟ類推したものです。もし仮にこれが不適切な命名なら、u301c-usも不適切な命名だと思います。--kesuuko 2018年9月17日(月) 23:07
      • 現状u301c-usも不適切なグリフ名だと思っています。―twe 2018年9月23日(日) 00:20

  • グループ:HalfwidthGlyphsの分離が反映されていません。修正をお願いします。--kesuuko 2018年6月29日(金) 16:18
    • 修正しました。ご報告ありがとうございます。―twe 2018年6月29日(金) 21:54

  • 適切な命名のグリフの条件に含まれていないからか、unstable-nishiki-e290や、u30f0-sansue0078などが不適切な命名扱いされてしまいます。次のような命名を適切な命名扱いしてください。
unstable-nishiki-####にしき的フォントの外字
unstable-nishiki-f####にしき的フォントの外字
unstable-nishiki-10####にしき的フォントの外字
u####-sansサンセリフ体
u#####-sansサンセリフ体
ue00##UnicodeのTagsの文字
    • GlyphWiki dump 検証 の「命名」についてですよね。さきほど修正しました。ご報告ありがとうございます。―twe 2018年4月23日(月) 19:50

  • 「UCSの複数欄指定のグリフがその無印グリフのエイリアスになっています」は仮想日本ソース(-jv)のみ対象にすべきだと思います。なぜなら、同じ字形なのでエイリアスにされたグリフが含まれてしまうからです。--kesuuko 2017年12月9日(土) 20:33
    • GlyphWiki dump 検証 の「UCSと別名」についてですね。
    • 無印グリフは字形の自由度が(原理上)UCSで包摂されるのと同じだけあるのに対して、複数欄指定のグリフの字形は仕様書を参照すれば一意に決まります。(例えばu22aecの字形はkoseki-135210@2であってもutc-00049@6であってもおかしくないけれど、u22aec-uの字形はutc-00049@6でしかありえないわけです。)言い換えると、包摂される字形の範囲は「無印グリフ ⊇ 複数欄指定グリフ」になります。
    • グリフ名で包摂される字形の範囲が広いほうが実体で狭いほうがエイリアス(別名)となっていると、広い包摂範囲内で変更をしたつもりが知らない間に別名側が包摂されなくなっていた等の問題が生じる可能性があります。(例えば、u22aec-u(@2)は現在u22aec(@8)のエイリアスになっています。この状態でu22aecの字形をu22aec@8からkoseki-135210@2に変更するとします。どちらの字形もU+22AECに包摂されるためその編集には問題は無いと思うかもしれません。「最近更新されたページ」でも初期設定では自動編集は表示されないため、u22aecの変更しか表示されないので、誰も気にかけないかもしれません。しかし実はu22aec-uの字形はu22aec@8からkoseki-135210@2に変わってしまっています。)
    • 「UCSの複数欄指定のグリフがその無印グリフのエイリアスになっています」のメッセージを出しているのはこういう問題が起こる可能性からです。もっとも、グリフウィキではグリフ名が包摂する字形の範囲はそこまで厳密に意識されていない気がするのであまり気にする必要は無いかもしれません。
    • ところで、5000個超の中から-jvを探すとなるとかなり大変だというのは確かに分かります……。検索機能の追加を検討します。
    • ここまでtwe 2017年12月9日(土) 23:57

  • 接尾jaグリフは,GlyphWiki:命名ガイドラインには「JIS X 0213の字形が反映される前のJ欄(Ext.AのJAソース)」と書かれています。これだとJIS X 0213で字形変更がないJAソースは作成する必要はないように思えます。WG2N4620にある,字形変更された7字のjaグリフは,すべて作成されています。ただし私も確証はないので,JAソースはすべてjaグリフを作成するのかもしれません(作成しても接尾jグリフと重複するだけですが)。 --ziyang 2014年11月30日(日) 17:01
    • 私はUnicodeの規格票でJAソースのあるグリフのうち,JIS X 0213に無いものについて“-ja”を作成していますが,特にこだわりなくJAソースに対しては“-ja”を作成しても問題ないと思います。JAソースとJIS X 0213の両方に存在し,字形が同じものについては無印または“-j”を実体グリフとし,“-ja”はそのエイリアスとするのがよいと思います。--spinda-kkmr 2014年11月30日(日) 17:23
    • ISO/IEC 10646 の仕様書の J 欄は、現行では J 欄には「JIS X 0213の字形が反映され」ておらず(例:U+4105 の J 欄は JA-2537 u4105-ue0101であり、JIS X 0213 の字形u4105-ue0102ではない)、命名ガイドラインのこの記述は変だなあと思っていながら「JA ソースは-ja」として作業していたのですが、Amendment 2 では JIS X 0213 の字形が反映される方向だと今日初めて知りました。ということで、-ja は 7 字だけということになりますね……。7 字以外の JA ソースは -j にするのか -ja か両方かについては、-js(補助漢字)を含め議論が必要と考えます。―twe 2014年11月30日(日) 21:04
      • なお、個人的には JA ソースは ja-####、補助漢字は jsp-XXXX とし、uXXXX-ja, uXXXX-js を廃止するのがよいと思います(-js のグリフは 1 つも登録されていませんし)。―twe 2014年11月30日(日) 21:04

  • GlyphWiki dump 検証 の「削除された部品」でdump_newest_only.txtの終わりの方のグリフが最新版の部品が存在しないグリフと誤って認識されています。
  • また,「IDSとの不一致」の「上下型のIDSですが、最初の部品が縦長に配置されているようです。」にある「u2ff1-u2ff0-u5200-cdp-89ca-u4e00-var-002(⿱⿰刀一): 上下型のIDSですが、最初の部品u5200(刀)が縦長に配置されているようです。」は別に問題はありません。部品の直前のIDCで判断するのではなく,最初のIDCで判断しているので,不具合が生じているように見えます。 --ziyang 2016年3月16日(水) 01:12
    • ご報告ありがとうございます。
    • 「削除された部品」で終わりの方のグリフが存在しないグリフと誤って認識されていることについて
    • 今年の1月17日ごろから、突然 dump データがうまく読み込めなくなったようです。原因はまだつかめていません。具体的には終わりの方のデータ(今日は zihai-139535 以降 4431 グリフでしたが、毎日変わります)が読み込んだデータから消えているようです(元の dump_newest_only.txt には何も問題ありません)。この影響で、終わりの方のグリフが「削除された部品」で存在しないことになるほか、終わりの方のグリフが検証されずエラーが出ないなどの問題が出ています。申し訳ありませんが解決までは今しばらくお待ちください。
    • 「IDSとの不一致」の縦長・横長の不具合について
    • 今の判定アルゴリズムはあまり良くないので本当は改良したいところですが、とりあえずグリフ名の最初が「u2ff0-u2ff1-」「u2ff1-u2ff0-」のような場合に「最初の部品が横長・縦長に配置されているようです」とならないようにしました。
    • 以上 twe 2016年3月16日(水) 15:53
      • すでにお気づきでご検討中でしたら余計なことを申し上げました。よろしくお願いします。 --ziyang 2016年3月17日(木) 00:02
      • いえいえ、後者は気づいておりませんでした。こちらこそよろしくお願いします。―twe 2016年3月17日(木) 13:56
      • 読み込みの不具合も直りました。―twe 2016年3月20日(日) 10:35
  • 私はコードチャートと字源を考えて一部の間違ったグリフを修正した。例えば「槱」、若し此れは⿱⿰木酉灬であれば、「𪳝」と重複しました。また、「𡵌」の中国語読みはyi4ではなくcha1ですが、あの旁は「叉」が正しいと思います。この頁をご覧ください:https://zhuanlan.zhihu.com/p/27005748
  • どうも有難う。--井利阿牟(利用者:wiriamu) 2017年7月19日(水) 12:12
    • 興味深い資料のご提示、ありがとうございます。wiriamuさんの編集の一部を説明も無くリバートしてしまい、申し訳ありません。以下にその理由を説明します。
    • 1. uXXXX のグリフは、現在、日本ソースがあれば日本ソースの字形を優先することになっています。u69f1, u7589, u7bf9は、元の字形が日本ソースの字形と同じだったので、元の字形に戻しました。
    • 2. グリフウィキにはエイリアス(別名)という機能があります。たとえばu69f1-ue0101u69f1-ue0100u69f1-ku69f1-ju2acddkoseki-173990juki-69f1aj1-19465は、すべてu69f1のエイリアスとして登録されています。このとき実体グリフをu69f1@7u69f1@8のように変更すると、エイリアスグリフも自動的にu69f1-ue0100@2u69f1-ue0100@3, u69f1-j@1u69f1-j@2, ……のように更新されます。しかしエイリアスグリフにとっては前の字形が正しかったので、以前の字形に戻しました。
      u7589, u7bf9, u20c6c, u2a6c0も同じ理由です。
    • 3. u21f2cu21d4cは UCS2003 の字形を見て戻しましたが、これは戻さないほうがよいのかもしれません。
    • 包摂バグや仕様書字形に誤りがある場合に uXXXX の字形をどうするかは、その場合ごとに議論が必要と感じますが、今回のwiriamuさんの編集はその良い契機になったと思います。感謝します。―twe 2017年7月19日(水) 14:04

koseki-298310@8の白紙化の件

すみません、SPAM対策で間違えて削除してしまいました。今復旧しました。ご指摘ありがとうございます。--kamichi 2017年8月1日(火) 19:19

  • なるほどです。対応ありがとうございます。―twe 2017年8月1日(火) 20:19

変体仮名について

私は貴方が最近多くの変体仮名のグリフを作ったのを見ましたら、UnicodeのKana SupplementとKana Extended-Aにエイリアスを増やしましょう。有難う。--井利阿牟(利用者:wiriamu) 平成29年8月3日(木) 18:42

  • そうですね。グループ:twe_サンドボックス2@69に一覧があるので、機械的にエイリアスを作成することもできますが、koseki-XXXXXXとは字形が大きく違うものもあるので、確認しながらが良いかなと思います。―twe 2017年8月3日(木) 20:33

KAGE Engine修正のポストについて

ご提供いただきありがとうございました。今月中に反映させたいと思います。取り急ぎ御礼申し上げます。--kamichi 2017年8月14日(月) 10:30

  • どういたしまして&確認していただいてありがとうございます。他にも修正可能な箇所があったらpull requestをしたいと思うのでよろしくお願いします。―twe 2017年8月14日(月) 21:34

諸橋大漢和関連字の修正につきまして

字形崩れや関連字設定漏れなどでお手数おかけしており申し訳ありません。修正ありがとうございました。 ―mtnest 2018年9月21日(金) 10:59

  • どういたしまして。大漢和辞典グリフの大半が作成されたのは、グリフウィキにとって良いことだと思います。登録作業お疲れ様です!👏―twe 2018年9月23日(日) 00:20