GlyphWiki logo
导航
帮助
搜索

工具箱
其他语言
文章讨论编辑历史

GlyphWiki:井戸端

字形维基(GlyphWiki), 自由的字形数据库

目录

各種議論の場として用意しました。個々の細かいルールはその都度決めていくということでお願いします。議論が終結したと判断したものはGlyphWiki:井戸端-保存に移動しました。また未解決のまま時間がたってしまったものはGlyphWiki:井戸端-未解決に移動しました。新しい話題の追加は一番上にお願いします。

他のグリフのエイリアスとなっているユーザー占有グリフの実体が他のグリフのエイリアスとなったことに伴う字形変更について

他のグリフのエイリアスとなっているユーザー占有グリフの実体が別のグリフのエイリアスとなった場合、字形を元に戻すことが第三者からは不可能となってしまうことがあります(例えばfzyouhei_u5192、無理矢理戻そうとすると今度はglypc_xe79eの字形が変わってしまう)。

このような問題を解決する方法があれば教えていただけると幸いです。--kesuuko 18:01, 20 February 2024

  • ご指摘ありがとうございます。まずfzyouhei_u5192そのものについてはSPAMユーザー認定しているので特に対処はしない(どちらかというと削除対象)として、将来の同種のトラブルをどうするかですが、(1)ユーザー占有グリフとエイリアスの関係をシステム的に統制する(トラブルのもとになるパターンについて、エイリアスや引用を不可とする)、(2)そもそも自己責任として放置する(トラブルになる可能性を掲示して自分でやらないように努めてもらう)、のいずれかになると思います。その上で、システムにあまり手を入れたくないという意味では(2)ですが、そもそもトラブルになりそうなパターンを全て把握できれば、いつかのタイミングでシステムに手を入れることも考えます。--kamichi 2024年2月21日(水) 10:14

西夏文字について

西夏文字の設定は関連字がないものが多いのですがどうなっているんですか?進まないようであれば西夏文字を調べたりするのですが、進んでいるかわからないので質問させていただきました。--shien-donkama2000 2024年1月21日 14:59
  • 特にどなたかがデータを準備中であるとは思いにくいので、もし関連字がお判りでしたら是非登録していただければと思います。--kamichi 2024年2月3日(土) 15:36
 

新規命名「u****(*)-jn」の提案

私は、UnicodeのJソースの例示字形にデザイン差が存在していると考えています。(例を挙げると、u898d-ju8993-ju5bf4-jでは「見」の目と儿が接触するかどうかが異なります)

このようなデザイン差をそのまま無印UCSグリフの字形に反映させると、グリフセットとしての質が低下してしまいますし、デザイン差を統一して無印UCSグリフの字形にすると、将来的に行われる無印UCS命名の廃止に支障をきたしてしまいます。

このような問題を避けるために、私は「u****(*)-jn」命名を新設して、「-j」命名はデザイン差を忠実に再現して、「-jn」命名はデザイン差を統一したグリフを作成するべきだと思いますが、どうでしょうか。なお、「-jn」のnはnormalizeの頭文字です。--kesuuko 20:42, 8 December 2023

  • ご提案ありがとうございます。基本的に同意です。その上で、これってUniocdeのJソース例示字形特有の問題なのか、平成明朝のデザインの問題が引き継がれているのか、どちらでしょうか。切り分けておいたほうが良い気がします。おそらく後者ですよね。実は何かしらのデザインルールの結果、デザインの不統一と誤解されている可能性もあったりしないでしょうか。このあたり、詳しい方がいらっしゃるといいのですが。ひとまず、今回のjnでカバーする要素を列挙して、その分はjnを新設するということでいかがでしょうか。--kamichi 2023年12月20日(水) 23:16

    • この問題は、UnicodeのJソース例示字形特有の問題と考えた方がいいと思います。なぜなら、UnicodeのJソースのうち、JMJソースの漢字の例示字形は平成明朝でなくIPAmj明朝フォントを使用しているためです。
    • また、この正規化は見た目の差が微細なものに限定するべきです。例えば、筆抑えの有無や「非」がu975e-ju975e-var-001かなどは見た目上の差が比較的大きいため元の字形を尊重するべきだと思います。
    • 以上、--kesuuko 01:23, 21 December 2023
      • 筆押さえ、「非」などについても正規化の対象に追加しました。--kesuuko 21:19, 4 January 2024

      • 現在ガイドラインの草案を作成しているのですが、「見」の字形についてu898b-ju898b-gのどちらを草案に採用するか迷っています。--kesuuko 02:42, 21 December 2023

  • なるほど、情報ありがとうございます。そうするとさらに質問ですが、今回問題となっている不統一はIPAmj明朝の中に閉じて起きていることなのか、IPAmjの中+平成明朝(つまりIPAmj明朝のデザインポリシーと平成明朝のポリシーが違うことも不統一の要因)に起きることなのか、どちらでしょうか。IPAmj明朝だけの問題であれば、それを指摘すれば将来的に修正される余地もあるのかなと思います(ない?)。--kamichi 2023年12月21日(木) 11:58

    • 字形の不統一については、IPAmjの中+平成明朝に起きることだと考えています(むしろ、IPAmj明朝の範囲内でのデザイン揺れはほぼないと考えられます)。--kesuuko 12:46, 21 December 2023

  • “-jn”の導入には賛成いたしますが,ガイドラインには議論の余地が大いにあります。個人的にはjv(仮想J字形)のガイドラインを流用すると考えていました。個人的には画の頭の接触・非接触の不統一が気になります。詳しくはガイドライン草案のノートページに書きます。--spinda-kkmr 2023年12月23日(土) 18:29

サイトマップのようなものの必要性について

  • 現在私自身がそれほど困っていることではないのですが、非漢字の扱いなど今後の方針についての議論ページを設けたいなどと考えているときにふと思ったので書いてみます。
  • GlyphWikiのグループ(会話)ページのなかには、GlyphWikiの運営に不可欠な情報を記載したページや、重要な意思決定が行われているページもあります。例えばGlyphWiki:登録グリフ情報GlyphWiki:削除依頼字表-讨论:花園フォントなどです。これらはメインページから自然に遷移できる場所にありません。またGlyphWiki:ソフトウェアへの要望GlyphWiki:システム変更記録などもGlyphWiki:バグ報告において言及されているだけであるためややたどり着きにくいかもしれません。サイトマップのようなものを設けてこれらのページを一覧できるようになるとより使いやすくなる(そして新しいページも追加しやすくなる)かと思いました。--turgenev 2021年12月15日(水) 22:43

  • おそらく「GlyphWiki:」の検索結果で出てくる一覧が重要なページになるものと思います。すると「Group:」と混同していると思われる「UCSとIVS云々」のページ群を整理する必要があります。あとは言語別に分けられるようにして、Specialページ的に自動生成するか、手動で1ページ用意するか、だと思います。--kamichi 2021年12月15日(水) 23:03
  • 「GlyphWiki:」ページの役割を(GlyphWiki:グループページを使うを読んで)今初めてちゃんと理解しました。ありがとうございます。とりあえず検索でもよさそうですね。ただ、常にサイドバーにあるとやはり便利な気もするので、ページを設ける意義はあるかもしれません。--turgenev 2021年12月16日(木) 00:42

  • 取りあえず「GlyphWiki:」から始まる全てのページを整理してみました : 字表:sayunu_sandbox@22。このような一覧は必要です。自動生成の機能を新たに開発するより、手動で管理するのがいいと思います。なぜなら (1) 一旦ページ群を整備すれば頻繁に変動する物ではないので。(2) 用途の大きく異なるページがあって名称から識別できず、人間が内容を理解して分類しなければ利用しにくいので。(3) 機能開発を待つより早いので。新たなページとして用意するのが単純ですが、そもそも「メインページ」に目次を載せるのも合理的です。(現在の「メインページ」は「グリフサンプル」を削ってもいいような ?)こうやって一覧に集めてみると、品質がバラバラなのと、全体的な説明不足を感じます。追加すべきドキュメントとか思う所がありますが、その話はまた今度にします。 — sayunu 2022年7月30日(土) 17:31
    • 字表:sayunu_sandbox@22に多大なる有用性を感じました。ありがとうございます。内容の粒度に差があることや、足りないであろうページがあることは致し方がないかと思います。逆にこのように整っていると不足分が分かりやすく、埋めやすいかもしれません。当初、一目でこんなグリフもあるんだ、と思ってもらうためにグリフサンプルを置いたわけですが、扱いを小さくしてもいいかもしれません。--kamichi 2022年7月30日(土) 22:30
  • (一番上に移動、新規追加)引き続き、「使用言語登録のお願い」の情報にたどり着けなかったとみられる利用者が多く発生しています。「お知らせ」は一過性のニュースなどを記載する場所であり、恒久的なガイドラインを載せるにはあまり適していないような気がします。一案ですが、「どうやって使うのか」の中に「ユーザー登録をする」というページをたてて、使用言語登録、ユーザー登録のメリット(各ユーザーがお互いの編集内容を認知でき、信頼度が上がる、ユーザー占有グリフを作成できる)などについて書いておくというのはどうでしょうか。異論がなければ自分で編集しようと思います。--turgenev 2023年11月8日(水) 14:02

    • 本件、「サイトマップの作成」「ユーザー登録をする」の両方について強く賛成します。--kesuuko 03:30, 5 December 2023

  • (取り急ぎ部分的な反応だけですが)ありがとうございます。システムメニューへの反映はプログラムの修正が必要になりますが、それ以外の部分は(自己申告)コアメンバーの方にどんどんやっていただいて構わない(嬉しい)と思います。ドキュメントの整備が至ってないのは事実で、できる範囲で進めていくしかないと若干諦めています。
  • kamichiさん、お忙しいところありがとうございます。さっそく、実際に上記の作業を行いました。また、ちょっとしたところですが、 GlyphWiki:どうやって使うのか にある各リンクに短い説明を付けました。他のユーザーの方も、何か思いついたら是非アップデートをお願いします。--turgenev 2023年12月23日(土) 02:05

JMJソースの水平拡張に伴う議論

下記「JMJソースの水平拡張と無印UCSグリフと仮想Jグリフについて」に記載のある通り、Unicode16.0においてJMJソースがUnicodeに大量に追加される見込みです。これに伴って、以下の4件を議論する必要があると思います。--kesuuko 18:18, 26 October 2023

(1) 無印UCSグリフの字形変更の時期

JMJソースによる水平拡張がなされるUnicode16.0が発行されるのは2024年9月の見込みですが、GlyphWikiではそれより早い段階で字形変更を行うことも考えられます。

ただし、現段階ではJMJソースのグリフは未作成のものも一定数存在することには留意が必要です。--kesuuko 18:18, 26 October 2023

(2) 微細なデザイン差を再現することに対する是非

JMJソースは既存のJソースに使われている平成明朝とは異なり、IPAmj明朝フォントが使用されています。そのためJソースのデザインにブレが発生します。

GlyphWikiにおいては、「u****(*)-j」のグリフではデザイン差を再現する必要があると思いますが、「u****(*)」の無印UCSグリフにおいては再現する必要はなく、むしろデザインを統一した方がフォントとしての質が上がると思います。--kesuuko 18:18, 26 October 2023

(3) 既存の仮想Jグリフの扱い

GlyphWiki:仮想J字形のガイドラインでは、Jソースがある符号位置には仮想Jグリフを作成しないこととなっています。しかし、仮想Jグリフが存在する符号位置にJソースが追加された場合については規定がありません。このような場合、仮想Jグリフの白紙化を行うべきでしょうか。

私の意見としては、白紙化は必要だと考えています。--kesuuko 18:18, 26 October 2023

(4) 仮想J字形のガイドラインの改訂

JMJソースには、現在の仮想J字形のガイドラインに適合しない字形が多く存在します。特に4画くさかんむりについては、ガイドラインの改訂を視野に入れた議論が必要だと思います。--kesuuko 18:18, 26 October 2023

(ご意見募集)常時TLS(SSL)化への全体移行について

現在、グリフウィキではTLS(SSL)対応は以下となっています。

  • glyphwiki.org 常時TLS。一部APIやXMLは非TLSもアクセス可
  • {en, ko, zhs, zht}.glyphwiki.org TLS/非TLS双方可
  • non-ssl.glyphwiki.org 非TLS

今後、全てを常時TLSに移行してもよろしいでしょうか?

  • {無印, en, ko, zhs, zht}.glyphwiki.org 常時TLS
  • non-ssl.glyphwiki.org 非TLS

(May I move our glyphwiki access to always TLS/SSL (forced TLS/SSL)? 我可以将对 glyphwiki 的访问改为始终使用TLS/SSL(强制TLS/SSL)吗?)

以上は --kamichi 2023年8月31日(木) 11:57

  • 特に要望等もないので、当面現状のままとします。--kamichi 2024年2月11日(日) 17:56

ka-kc命名について

UnicodeのKCソースはhttps://www.koreanhistory.or.kr/newchar/ に由来していますが、一部の番号の字形はhttps://www.koreanhistory.or.kr/newchar/ と大きく異なります(ka-kc05441など)。このような場合、ka-kc命名のグリフはどのような字形で作字すべきでしょうか。私はka-kc命名のグリフはhttps://www.koreanhistory.or.kr/newchar/ の字形を再現して、UnicodeのKCソースは別の命名(kc-*****)で作成するのがいいと考えています。--kesuuko 04:47, 18 August 2023

Jソースの漢字に見られるデザイン差について

現在、UnicodeのJソースの漢字には一定のデザイン差が存在します(例えばu795d-ju67f7-jにはu5144-02が使われているのに対し、u51b5-ju5cb2-jにはu5144-g02が使われています)。 このような場合、-j命名のグリフはJソースの字形を再現して作字するのですが、無印UCSに関してはそのまま再現するのとデザイン差を統一して片方に合わせるのとどちらが良いのでしょうか。--kesuuko 17:53, 19 July 2023
  • なお、この問題は下記「JMJソースの水平拡張と無印UCSグリフと仮想Jグリフについて」にも大きく関わってきます。--kesuuko 17:53, 19 July 2023

JMJソースの水平拡張と無印UCSグリフと仮想Jグリフについて

現在、UnicodeにJMJソースの水平拡張を行う提案がなされているようです(リンク 、700MB以上あるので注意!)。これによってUnicodeにJソースが追加された場合、無印UCSグリフの字形および-jvグリフの存廃についてはどのようにするべきでしょうか。場合によっては「JIS以外のJソースは無印UCSの字形に反映しない」「-jとは別に-jvを作成する」などの扱いもありうると思うので、このページで他ユーザーの意見を聞きたいです。--kesuuko 06:46, 9 June 2023
  • これは非常に厄介な問題になりそうです。“-jv”と“-j”を同一コード位置で併存させるのは仮想J字形の意義に反するので好ましくないと考えられます。
  • GlyphWikiの方針ではJソースを最優先させるので,Jソースが追加された場合はjvを白紙化したうえでjに移動することになります。但し追加されたJソースがjvと一致しない場合はjvはvarに移動させることになると思います。
  • ですので,対応は,
    • (1)jvと追加されたJソースが一致する場合は単純移動
    • (2)jvと追加されたJソースが一致しない場合は,Jソースを改めて作成したうえでjvはvar等の別命名に移動
  • となると思います。(1)はbot処理で可能でしょうが,(2)は手作業で行うほかないと考えます。
  • 以上,--spinda-kkmr 2023年6月23日(金) 21:07
    • spinda-kkmrさんの意見に賛成します。--kesuuko 05:37, 28 June 2023
    • その他、JMJソースは既存のJソースとデザインの細部が異なる(jmj-026452のひよみのとりの5画目、jmj-037898の日と勹が繋がっているなど)ので、これらによるデザインの不統一も気になるところです。--kesuuko 05:37, 28 June 2023

編集中のデータが「編集」ボタンを押すと失われる

ページの編集を行なっている際に上部の「編集」ボタンを押してしまうと編集中のデータが失われてしまうので、ページの編集中は「編集」ボタンが機能しないようにするべきだと思います。--kesuuko 02:34, 21 May 2023

  • ある意味「編集やり直し」の意味で押すものだと思っていたのですが、現状で実害があるというご認識でしょうか。他に同意見があれば要対応事項と思います。--kamichi 2023年5月21日(日) 12:37

    • 私は「操作ミスで誤って押してしまう」事態を想定しています。また、私は編集中に「編集」ボタンを意図的に押すことはほとんどありません。--kesuuko 15:25, 21 May 2023
    • 私が事態を正しく理解できているかわかりませんが、押すと編集内容が失われてしまうというのは「編集」リンクだけでなく「履歴」「グリフ」や横にある「メインページ」などについても同じなのではないかと思います(慣れない人が間違えて押す可能性は「編集」よりは低いかと思いますが)。また、ブラウザの「戻る」ボタンを押せば多くの場合は編集内容が復元されるのではないかと思います。誤操作の対策として他サイトでもよく見かけるのは、「このページを離れますか?」のような警告ダイアログを表示するもので、これなら間違えてページを閉じることも防げるので有効かもしれません。--turgenev 2023年5月22日(月) 10:05
    • 私も誤操作による消滅防止のための対策に賛成です。turgenevさんの提案のように警告ダイアログを出すのが一番わかりやすく現実的と考えます。--spinda-kkmr 2023年5月25日(木) 13:00

sandboxの自動リセットについて

sandboxを登録後一定期間経過後に自動的に削除する(痕跡なしの白紙化・バージョンは増えていく)機構を検討しています。現状で管理者が中身を確認していないため、解釈によっては不穏当になりかねないグリフ登録が多数見られます。一方でsandboxを他のグリフに引用してしまうケースもあるため、防止措置が必要かもしれません。ご意見ありましたらお願いします。--kamichi 2023年5月19日(金) 23:22
  • 私の意見を書かせていただきます。
    • (1)sandboxの内容の自動削除は賛成(期間は要議論,私は32日間が適切と考えます。32日間は翌月同日までは保証されるという意味)
    • (2a)sandboxへのエイリアスは登録不可にする(ユーザー占有グリフも含む)
    • (2b)sandboxを部品として利用することは禁止にする(システム側ではじく)
    • (3)出典不十分の漢字等,これまでsandboxへの登録を促していたグリフはユーザー占有グリフでの登録を要求する(GlyphWiki:グリフを登録するの「とりあえずsandboxに登録する」を参照)
  • 以上,--spinda-kkmr 2023年5月20日(土) 13:06

  • 再度、悪い状況が発生しましたので、24時間経過後コメントを含め一斉削除の強めの対応を考えることとします。--kamichi 2024年2月15日(木) 15:34

利用者ページにおける使用言語の表明の内容について

  • 諸事未対応の状態で恐縮ですが、表題の件について、現在はDeepLのようなかなり実用的なWeb翻訳もあるため「外国語の読み書きが補助なしでできるのか」と「Web等を活用してできるのか」のどちらを表明するのが望ましいか、そもそも表明(情報)は必要なのか、と根本的な疑問が出てきました。当初の目的を振り返ると、おそらく以下2点の情報を共有したいのだと思います。

1) 議論のために、母語あるいは使用可能な言語を知りたい→意思疎通ができればよいのだから手段は問わない。母語が分かるだけで良いのかもしれない

2) 議論のために、文字コード、文字(集合)に対する背景知識や立場、スキルを知りたい→何を表明すれば情報が共有できるのか、表現が難しい?

ということで、1)は単に母語だけを書いてもらうように変更しますか?2)をどのように表現するかも、ご意見ありましたらお願いします。--kamichi 2023年2月10日(金) 21:53

  • 特に意見が出ず、このままでも良いかと思うに至りました。閉じます。--kamichi 2024年2月11日(日) 17:56

Microsoft Wordにおいて漢字のみ花園明朝に置換する方法

  • 花園明朝の実用を想定するにあたり、非漢字のデザインにはまだ課題があるため、漢字のみ使う(あるいは漢字のみのフォントとしてリリースする)ことが有力な選択肢の一つになります。
  • MS Wordの置換機能(ワイルドカード)を使えば漢字のみフォントを変更することは可能そうだったのですが、範囲指定"[○-○]"においてBMP外の文字を使うとエラーが出てしまっていました。
  • サロゲート文字をVBAで指定することで目的が達成できることがわかったのでここに共有しておきます。
  • 字表:turgenev_ReplaceNonBMPinWord

  • 有用な情報なので独立してページを立てさせていただきました。--kamichi 2024年2月11日(日) 17:48

作成されていないページに表示される注意書き

作成されていないページの上部に表示される注意書きの中で、GlyphWiki:サンドボックスにリンクがされていますが、このページは現在使用されていません。この部分について、私は次のどちらかの手段で解決できると考えていますが、どちらの案を採用する方が望ましいでしょうか。

以上。--kesuuko 19:25, 13 December 2022

    • すみません「作成されていないページの上部に表示される注意書き」が見当たらないのですが、例えばのURLを張っていただけないでしょうか。--kamichi 2023年2月10日(金) 21:56

      • 作成されていないページ(例えばmamimumemo)の編集ページに表示される「投稿のテストをしたい場合、サンドボックスを利用してください。一度作成した項目はあなたが削除することはできません。」の「サンドボックス」の部分にリンクが張られています。--kesuuko 00:23, 20 May 2023

  • やっと確認できました。修正しました。グリフの場合はsandbox、ページの場合は字表:sandboxにリンクを張り替えました。--kamichi 2024年2月11日(日) 17:12

KAGEエンジンに関する議論ページの新設

字表:KAGEエンジン-問題のある漢字グリフの内容などに基づき、GlyphWikiのフォント生成用エンジンであるKAGEエンジンに関して問題点や今後の変更について議論するための専用のページ(グループページまたはGlyphWiki:ページ?)を設けたいと思っております。技術的な詳細に立ち入ることになり、量も多くなりそうなので、全員が見るためのページ(井戸端など)を使うのはふさわしくないと思ったからです。 sayunuさんからの意見なども踏まえて、サイトマップのようなページが新設されることになれば、このページもそこに載せたいと思います。--turgenev 2022年8月12日(金) 20:49
  • 関連のページ名は「KAGEエンジン-」で始まるものに統一しようと思います。「GlyphWiki:」ページにすべきかどうかなど、何か意見があればお願いします。--turgenev 2022年8月18日(木) 21:57

  • 書き込みに対応できずすみません。できればGlyphWiki:ではなくグループページでお願いします。--kamichi 2022年11月26日(土) 20:35

ある漢字の命名法について

https://twitter.com/JUMANJIKYO/status/1270241898205073409 に掲載されている漢字を登録したいのですが、字典ではなくこのような古籍に出ている字の命名法がわかりません。どうすればいいでしょうか。yoshiciv 2022年8月3日(水) 23:14
  • 興味深いです。指示文字としては非常に明快ですが、IDSではやや表現が難しく、文献名に結びつけるのも変な気がします。が、たたき台としてshoutoutouhitsu-50を提案します。異論をお願いします。--kamichi 2022年8月4日(木) 13:19
    • これ1つのためにprefixを新造するよりも「五」あるいは「十」の「-itaiji」として処理し、メタ情報で説明するというのはいかがでしょうか。--kamichi 2022年8月4日(木) 13:21
      • 私は専門家でないので分かりませんが、「五」あるいは「十」の「-itaiji」と言うのは少し違うのではないでしょうか。あくまで50ですしyoshiciv 2022年8月6日(土) 23:05
      • これ話が止まっていますが、このグリフは20,30と同様、10の倍数の概念、あるいはそれが5つ集まっている、の概念ですから、無理やり用意するならば5や10に結びつけても変ではないと思っています。ところで、以下の話で思い出しましたが「misc-」でいいような気がします。ただし算用数字はグリフウィキでは番号のための記述用なので、言葉(goj(zy)u(uu)、fifty)にしてください。--kamichi 2022年11月26日(土) 20:22

  • zihai-001820 というグリフがあるようですが、var や itaiji というのは UCS のグリフ名にしか使わないんでしたっけ ? 右端の縦画が曲がるのは var の範囲かしら…。一般論として現状のルールではこういう単発グリフの命名が難しいですね。字表:prefix-misc は意外と用途が狭く定義されてるんでしょうか。「情報交換ではない別の意味を持った漢字」と言われてしまっているので、こういった実際に使われている物が取り込めない。misc の「情報交換ではない」という要件を外し、適格性の充分条件の一つとして「古籍に一件以上の用例がある」を追加した上で、 misc を使えるとよい気もします。別の接頭辞でもいいけど、〈misc〉(雑多な)という言葉からすれば、雑多に色々取り込める名前空間という役割を持つ方が自然だし。 — sayunu 2022年8月7日(日) 18:22
  • 具体的には zihai-001820-var-001misc-syoutoutouhitu-gozyuu という事です(ローマ字翻字方式は別の問題)。 — sayunu 2022年8月7日(日) 19:30
  • 書き込みに気が付いていませんでした。失礼しました。私は(今は)「var-」は自由でいいと思っています。「itaiji-」はできればもっとポピュラーな親字(つまりUCS)につけてほしいですが、UCSに無いのであれば仕方がないと思います(今回の場合はvarですが、itaijiも仕方がなかった例と思います)。「misc-」は適切な命名ができない、その他雑多なものという認識です。その認識と「prefix-misc」の記述に齟齬があることに気が付いていなかったというのが正直なところなので、方針を変えたいと思います。--kamichi 2022年11月26日(土) 20:23

自己再帰のグリフへの処置

どうも見た感じ、u4e01-j@5 が自分自身を部品として引用した状態になっているらしく、その字自体や、それを引用する他の漢字 k5-02a3@4 のグリフ描画などを妨げています。過去版としてのグリフページは読み込めますが、最新版になっているとページが返って来ないようです。グリフエディターも無限再帰で止まります。私は特に方針がないので単なる話題提起ですが、不正データとして版を削除するなどの対応になるでしょうか ? (それにしても、これらの奇妙な投稿をする利用者は一体何なんでしょう。) — sayunu 2022年7月29日(金) 20:01

  • ご指摘ありがとうございます。悪意がある操作で引き起こされるバグは優先度が低いと思っているのですが、あまりいい状態ではないので対応したいです。ただ自分自身のバージョンをいちいち調べる手間が1つ増えるので、面倒だとは思っています。(この夏休みに固めていろいろやりたいと思っていて、今少し時間的余裕がないので、反応悪いです)--kamichi 2022年7月30日(土) 19:12

  • いろいろとトラブルのもとになったことが判明しました。現状はデータを強制的に手修正し、解消しています。改善が必要と考えます。--kamichi 2022年8月2日(火) 15:41
  • 私は荒らしユーザーではない(つもり)ですが、部品を循環参照にしたらどうなるんだろう?というのはこのトラブルが起こる前から好奇心をそそられるアイデアとして着想していたので、今後もこのようなことは起こる気がします。自分自身を部品として引用していることをグリフ登録時に検出して弾くのがよいかと思います。--turgenev 2022年8月2日(火) 18:14

「旧部品の一括更新」のやり方

初歩的な質問なのですが、「古い部品を引用しているグリフの一括更新」ページ(Special:Mustrenew)へはどのリンクから遷移できるのでしたっけ?https://kurgm.github.io/gwv-view/#/mustrenew/0 から飛べば表示できるので、ページが存在するのはわかるのですが…。今は暫定的に「部品の一括更新」のページ(Special:Renewall)を使っています。--turgenev 2022年7月9日(土) 11:33
  • ページ左メニュー「ツールボックス」の「旧部品引用グリフ」のことでしょうか?--kamichi 2022年7月9日(土) 12:05
  • なるほど、こちらに目が行っていませんでした。ありがとうございます。グリフごとのページから遷移するわけではなくGlyphWikiデータからランダムに選んで表示されるということは、「この(特定の)部品を修正したので更新したい」という目的よりは、「何かグリフを改良する作業をしたいので部品が古くなっているグリフを知りたい」という目的のページという感じでしょうか。ということは、部品を修正した直後にその部品が含まれるグリフの更新を行う場合は引き続きSpecial:Renewallを使用する(ことが想定されている)ということで大丈夫でしょうか?--turgenev 2022年7月9日(土) 13:02
    • 残念ながらグリフウィキの初期の設計思想から抜け落ちていた部分で、あとから実装されたもののため、明確にどの場合はどうすべき、というものはありません。ですので、おっしゃっている想定で続けていただくのが無難かと思います。あるいは(やや記憶があいまいですが)target=グリフ名を付けるだけと考えれば、(元となる部品に相当する)グリフページにリンクを新設すべき、という考え方もあるかもしれません。--kamichi 2022年7月9日(土) 14:35
    • 承知しました。私が最近編集していたときは、不正データの形式的な修正など見た目にはほぼ影響しないものが多く、その部品を使用している全てのグリフを機械的に更新しても問題ない状況でした。あまりそういう場合は多くないかもしれませんが、もし簡単に設置できるようでしたらリンクがあると便利かもしれません。--turgenev 2022年7月9日(土) 15:49
  • 私はグリフページを開いた状態から URL を書き替えて、当該グリフの一括更新ページに直接遷移するという操作を頻繁にしています。リンクがあれば便利だろうとは思います。(「この版への固定リンク」の隣に現れるのが自然そう。) — sayunu 2022年7月30日(土) 03:59

  • 別件と関連するのですが、この1週間、中国大陸からと思われる大量の旧部品更新+自己循環グリフの登録でデータの修正に労力を使いました。そもそも旧部品更新は必要でしょうか?グリフデータに旧部品が入っていても構わないと思えればそれでいいと思うようになりました。いっそのこと機能を外してしまおうかと考えます。まあこれは異論(反対)が多そうですね--kamichi 2022年8月2日(火) 15:39

  • 少なくとも URL が示唆するような「must renew」ではないよなと前から思っています。旧部品を引用していても、単体のグリフとして成り立っていれば悪くはないです。ただ、手段を完全に失うのも惜しいですね。
    • 部品を改良して一括更新する事で多数のグリフの品質を一気に向上できる場合がある
    • フォントとして使う場合や、グリフ画像同士を比較する場合、同じ部品の形が揃っている方がよい
  • 多数のデータを一気に壊せる、影響力の強い操作なので、悪用されにくい障壁を設けられるといいんですが…。 — sayunu 2022年8月2日(火) 16:08
  • 今更ですが、本題に関しては、RequestlyというChromeの拡張機能を使用することで「部品の一括更新」のURLを「旧部品の一括更新」に自動で書き換えるように自分で設定しました。あるいはブックマークレットでも可能かと思います。--turgenev 2022年8月2日(火) 18:14
  • 別件に関して、さらに別件のような話題なのですが、一括更新の対象が「特定のグリフの旧バージョンの引用」だけで、「特定のグリフの旧バージョンのエイリアスの引用」「特定のグリフの旧バージョンを引用しているグリフを部品として引用しているグリフ」等々は含まれないのが不便かなあ、と思うこともあります。ブラックリスト的に検出する方法は手元で整えたので、喫緊の課題というわけではないのですが。--turgenev

  • この議論と直接は関係なかったのですが、この10日間ほど延々と一括更新を機械的に実行するSPAMユーザーがいます。いい加減うんざりしているため、ユーザーにレベルを設け、私が認定したユーザーのみ一括更新の機能が生きるように変更します。--kamichi 2022年8月5日(金) 23:32
    • 私はここ最近、主に見た目に影響のない不正データを排除するために、相当なペースで一括更新を実行していた自覚があるのですが、これは私のことではないのでしょうか?ご迷惑であれば今後は自重します。すみません。--turgenev 2022年8月6日(土) 08:04
    • 失礼しました。私にとってのSPAMユーザーとは「意思疎通ができない状態で、私の運営方針(あるいはグリフウィキにおける慣習と思われる状態)に反した投稿を継続する」ことなので、「匿名利用者」「投稿コメントを書かない」「自身の言語情報を書かない」「呼びかけに反応しない」投稿をされる方になります(また、確実なことは言えませんが、アカウントを停止しても別アカウントを作って同じ行為を継続することが何度も発生しています)。turgenevさんではありません。具体的には「最近更新したページ」で「自動編集を表示する」をONにしてずっと見ていくと現れます。--kamichi 2022年8月6日(土) 08:46
    • ただこれを見て思うのは、投稿行為自体はSPAMのように感じますが、特段問題はない(今回は循環参照で1つのグリフが壊れた状態で、そのグリフを引用したグリフの自動更新がなされて不良グリフが大量発生したので、システム上の問題と言っても良い)ので、もう少しこの状況(大量の引用があるので、グリフ更新で大量の旧部品引用グリフが発生してしまうこと)がどうにかならないものかと思います。--kamichi 2022年8月6日(土) 08:56
    • ありがとうございます。私でないのなら良かったです。確かにSPAMの条件とは合致しない部分も大きいですが、時期がまさにここ数日なのと、更新の量だけで見れば私のほうが多いくらいかとも思いまして…。
    • ただ、別の問題ですが、ここまで思考停止で機械的にやっていると微妙な位置の変化による影響を見逃している可能性は否定できないかとも思い、そこは反省点です…(たとえば@6の不正データを直して@7にしたとして、そこでは見た目の変化が全くなかったとしても、@6から遷移できる「部品の一括更新」のURLを「旧部品の一括更新」のものに書き換えてしまえば、そこでは(見た目の変化があるかもしれない)@1~@5も更新の対象になるのですが、これを途中まであまり意識していませんでした)。
    • とはいえ、不正データのリストを見ていると、部品のコピー→分解の流れで一箇所に由来するミスが複数のグリフにコピーされてしまった例もあるため、一気に片付けてしまおうと思った次第です。引き続き気を付けながら作業します。
    • たしかに自動編集はデフォルトで非表示なので不正の温床になりやすいかもしれません。例えば「一括更新」を単一の操作として手動編集扱いにして見やすくするようなことができればいいんでしょうかね(実装の難易度などは全く考えていませんが)。
    • ここまで turgenev 2022年8月6日(土) 09:30

  • (一行消されていたので復活)なんだか一人で空回りして恐縮ですが、今はじめて原因がわかりました。SPAM投稿排除機構が、旧部品グリフの自動更新機能に反映されていませんでした。なるほど…。--kamichi 2022年8月6日(土) 09:27
    • 申し訳ありません、ログインせずに編集していたことに気づいたので全文コピーしてからログインし直して貼り付けたら、その間にkamichiさんが編集されていたようです。横着してはいけませんね…大変失礼しました。--turgenev 2022年8月6日(土) 10:07
    • お気になさらずに。編集後にログインしていないことに気が付くとショックを受けます。--kamichi 2022年8月6日(土) 10:14

「pinyin-*」について

若干当事者以外の人も含めた編集合戦になりつつあるので、是非を検討しませんか。prefixが用意されているので、登録の手段については適切だと思います。一方で非漢字なので既存の集合であるかと言われると、あるような無いようなです。また、匿名編集者(ピンイングリフの全部か一部については言及しません)を、現状でSPAM投稿者として認定しています。ですので、今後もSPAM投稿が続く(登録失敗して表面上現れなくても)ようであれば、BAN対象として、過去のピンイングリフも一括して削除対象と考えています。--kamichi 2021年7月14日(水) 19:27

  • 私としては、「kumimoji-」命名に統合するのが落とし所だと思います。--kesuuko 20:11, 14 July 2021
  • 字表:漢語拼音音節組み文字にて出典とされている「现代汉语词典」は“中中辞典”(英英辞典の中国語版)のようですが,高額のため購入して確認することは私には難しく,どのようにこれらの拼音グリフが使われているのかはわかりません。ただ,常識的に考えれば拼音はラテン文字として表現できますので,わざわざ専用の組文字グリフを用意する必要性は薄いと考えます。組文字にしてしまうと英字幅が不統一になり,かえって見にくいと考えます。--spinda-kkmr 2021年7月14日(水) 21:57
    • 「现代汉语词典」はおそらく「bán等は実在していない」証拠として使用されていて、「bān等の組文字が存在する」証拠として使用されていない。sz 2021年7月15日(木) 06:30
    • 「现代汉语词典」はただの国語(大陸中国語話者にとっての)辞書で、今回のピンイングリフの出典にはならないと思います。情報の出し方が中途半端になりましたが、私の出典はサンセール社の中国語フォント(簡単電脳)の中に、漢字の上にピンインルビが振ってあるフォントがあり、それのピンインのみ版(そのものがあったかどうかは忘れてしまいました)とみなせば典拠ありかなと思った次第です。ピンインフォントの何が便利かというと、素の中国語の文章があった場合にそれをピンインフォントに切り替えるとそのままピンインに変わるので中国語学習者にとってピンインを調べる手間が省ける、というものです。もちろん多音字などはありますので多少の編集は必要ですが。kumimojiが漢字のため、と考えると本件は特別にprefix「pinyin-」を認めても良いのかなと思います。--kamichi 2021年7月15日(木) 08:15

変体仮名グリフについて

最近、インターネットで変体仮名の手書きや金属活字の資料(Twitterの変体仮名関連アカウントや変体仮名の資料データベースなど)を調べてみたところ、Unicodeの変体仮名の例示字形は癖が強かったり、もとの字と形が違ったりしていることがわかりました。変体仮名は日本の文字であり、Unicodeの例示字形より、民間の変体仮名に基づいて、グリフウィキ内の一般仮名のデザインを踏まえて新しく作字することを提議します。 それでは今後のグリフウィキ内の変体仮名グリフについてみなさんから意見を聞かせていただきたいと思います。
    • 1)varグリフかitaijiグリフとして登録
    • 2)今までのグリフウィキのものを置き換える
    • 3)反対
  • jjanggu2021.3.19(金) 11:23

  • 現状のグリフはUnicode(ISO/IEC 10646)の例示グリフですので、2)はないと思います。できれば1つグループページを作って、例示グリフと提案グリフの対比ができれば、判断できる人にとって有益な情報提供と思います。その結果、規格(標準)側で修正・変更があれば、大変意義のあることだと思います。1)についても、var(itaiji)ではなくて、仮のprefixを用意すると混乱が少ないと思います--kamichi 2021年3月19日(金) 12:32

  • >>わかりました。このままユーザー専用グリフとして作字していきます。なお、prefix字形を検討するほか、自分が例示字形と区別するよう変更した字形はリバートします。ご迷惑をおかけいたしました。--jjanggu2021.3.19(金) 12:47

  • Twitterの例のアカウントの「癖」という判断の根拠は現時点では不明。「日本国の政府の指導の下で文字を国際規格として登録する」に要する資格は「TwitterのBOTの運営」に要する資格とは段違いである。sz 2021年3月19日(金) 15:25

  • 私の意見は「弱い(3)」です。
  • Unicodeの変体仮名字形は,日本の文字規格を参照しているはずなので,ある程度の信頼性があると考えます。とりあえずはUnicode規格票に従っておくのが良いと考えます。
  • なお,私は非漢字グリフ作成があまり得意ではなく,変体仮名にも詳しくないので,詳しい方に比較用のグループページを作っていただけると大変有り難く思います。
  • 以上,--spinda-kkmr 2021年3月19日(金) 17:45

    • すいませんが、主張を180度変えました。改めてIPAグリフとUnicode規格票を確認したところ、IPAの方の変体仮名グリフはデザイン上グリフウィキの一般仮名、または花園明朝と共通点が多くみられたので、一般仮名のデザインを踏まえてUnicode規格に従うのがいいと思います。また、私のユーザー専用グループは「自分好みにデザインしたもの」とし、原則上グリフウィキ内の変体仮名グリフと区別していきます。--jjanggu 2021年3月20日(土) 14:19

U+82B2の字形変更からの議論

kesuukoさんが、U+30C28と区別するために、u82b2@8の字形を、u82b2@9の字形に変更しました。でも、Unicodeの中で、そんな「半重複」の漢字は多くあります。「半重複」っては、ひとつのコードポイントで一部のソースの字形がもうひとつのコードポイントのすべての字形と重複することと指します。U+82B2のJソースとU+30C28のすべてのソースはその一例です。でも、三年半前には、わたしはU+2ACDDと区別するために、u69f1@7の字形を、u69f1@8の字形に変更しましたけど、tweさんがu69f1@9にリバートしました。原因と言えば、「uXXXXのグリフは、日本ソースがあれば日本ソースの字形を優先することになっています」としました。それは今kesuukoさんの編集と矛盾になっていますから議論が必要だと思っています。私の整理によって、Unicodeに既存する「半重複」の漢字は以下の通りの40対(79字)があります(月肉舟に関するものを除く)。

コードソースコード
5668J20F96
56CDK21155
58C4J21428
5C6EJ4DB9
5DFDJ22049
69E9GH3BA3
69F1JK2ACDD
6B04J237EC
7361TK2486F
7422J24968
7468G24A01
7589J24D01
7714J25133
7A3DK25874
7A81J2592E
7AB4K259D1
7BF9J25CBB
7C06HJK25C83
8158T266E2
81EDJ26900
8200J2695D
82B2J30C28
8412T26CC6
8481J26CEF
8641J21582
K27144
8B39J27AF4
9038J284DC
9686J28E93
9819J29460
985EJ29516
34A8G20457
3778J21B6A
418BK9F9D
43DEGJ2669C
4620T889A
48B4G9097
4C17J29C18
23CEBT23D6D
246C9G821D

また、月肉舟に関する「半重複」の漢字は、80A6 80D0 80CA 8101 8127 81A7 4443 268AB 80F6 266E9 4420 80AD 43D9 440B 6721 2667F 813C 26772 26808 26805、20対あります。(上に挙げたコードポイントは肉部、順序は対応する月/舟部の漢字のブロックまたはコードポイントによる)

どう処理すればいいでしょう?--sim-ch 令和3年1月13日(水) 午前1:48(GMT+9:00)

  • 基本的な考え方は、利用者にメリットがある方法にすべきであると思います。字形が重複・半重複している2つ以上のコードポイントがある場合に、(グリフウィキの基本としている)Jの規格で最も優先するコードポイントの字形を最優先に決め、それ以外のコードポイントは、その最優先の字形と区別ができることが利用者にとってのメリットだと私は考えます。ですので、このルールが、本来のルールの上位に来るとすれば解決するのかと思います。もしかしたら論点がずれているかもしれません。他の方のコメントを待ちます。--kamichi 2021年1月13日(水) 09:51

    • でも、kamichiさんの観点によっては、U+82B2はJソースがあるので原則としてJソースの字形が優先ですが… --sim-ch 令和3年1月13日(水) 午後1:32(GMT+9:00)
      • あれ、失礼しました。確かにkesuukoさんの変更は矛盾しますね。私の意見では、u82b2は戻すべきと思います。ただu30c28側をどうするか…あえてu82b2-gにすることを提案します。--kamichi 2021年1月13日(水) 17:27
      • u82b2は花の異体字、u30c28は菕の類推簡化字という解釈ですか…。そうするとu82b2-gは不適切ですね。--kamichi 2021年1月13日(水) 17:33

    • JIS X 0213に存在する漢字(u5668u5dfdなど)は無条件でその字形にすべきだと思います。JIS X 0213になく、JIS X 0212にのみ存在する字は個別検討しても良いでしょう。--kesuuko 2021年1月13日(水) 18:11
      • あれ、kesuukoさん、本件は0213にあるものをkesuukoさんがJ字形からG字形に変更した、という認識です。では、U+82B2をJ字形に戻す部分はOKですね。--kamichi 2021年1月13日(水) 20:06
      • とりあえず全てケースバイケースとするべきだと思います。ただ、常用漢字や人名用漢字、JIS X 0213の互換漢字(u5c6eufa3cとか)あたりは無条件でJ字形にして問題無さそうです。--kesuuko 2021年1月13日(水) 20:40

T用折れの追加について

    • u5340-tの履歴では、Tソースの標準字形(細明體)を再現しようとしたバージョンがボツになっていたのですが、Tソースのために、u5340-t@2のような折れをエディタに追加することができますでしょうか?--jjanggu2020/10/23 17:20
  • そもそものKAGEエンジンの目的が、デザインを抽象化して座標の集合だけで漢字字形を記述するものなので、今回の場合はエディタではなくてKAGEエンジンへの機能追加が本来の筋なのですが、その形状はあくまでもデザインであって字体ではないと思っていて、優先順位としては低いものとした結果、エンジンに追加されていない、ということになります。また漢字グリフをbopomofoや「かな」のように重ね合わせで登録することは機械可読性に問題がありデータの再利用が難しくなるので禁止と考えます。以上によって八方ふさがりになっていると認識しています。--kamichi 2020年10月23日(金) 18:09

    • u5e7a-gみたいに複曲線で曲線をもっと中国風らしくするのはどうでしょうか。
      私の意見は、点と点が繋がっていないため(sandbox@10711)、そして、「抽象化」ではなくデザインの領域であるため、同じく反対。--sz 2020年11月21日(土) 02:35

    • 部品をそれほど伸ばすことはめったにないので、個人的に問題ないと思ってるんですが...-jjanggu

最近の投稿について(長文。方針の変更について提議します)

  • 書くべきか非常に悩んだのですが、最近のグリフウィキの投稿は「(私の主観でいう)学術的な利用」と「表現としての利用」に極端に2分されていると感じます。昔、香港・ベトナムでグリフウィキの発表をしたときに中国圏の方からいただいたコメントとして「何のためにあるのか」という意見が多く、私なりの意義を説明したところ「たぶん創作字にしか使われないだろう」と言われて、意外に思ったのですが、その指摘は正しかったのかもしれません。「表現としての利用」は目的外利用であると思っています。ただ、その文字が定着したり、あるいは時間がたった時に社会性を持ったものとして資料的な価値を見出す可能性があるとしてあえて許容してきたのですが、そろそろ判断を切り替えるときかなと思っています。私としてはグリフウィキが広く発展することよりも、学術的価値を見出してもらうニッチなニーズを重視しています。この方針の変更についてご意見ありましたらお願いします。なお、繰り返しますが根底にあるのは「学術としての価値を追求する」です。具体的には創作漢字を受け付けず、表現の場とすることを否定します。グリフウィキに登録できるのは引用できるグリフ(どこかに掲載されたもの、Webを含む)のみとすることを考えています。またsandboxは「登録の練習」の場とし、(残念ですが)時候の挨拶も含めた表現、交流の場としては認めない方針です。グリフウィキの当初の目的として「交流」もある程度期待することはあったのですが、断念することにします。ただ、おそらくですが、日本の漢字文化と中国の漢字文化はやはり違い、文字を表現手段として活用する、という側面は日本ではあまり見られない(せいぜいCMやデザイン)ので非常に興味深いです。これを否定するつもりはありません。ただグリフウィキをその場とすることは受け入れられないと思っています。--kamichi 2020年10月8日(木) 11:18
    • 大変難しい問題だと考えます。(私自身の感覚では)グリフウィキが学術目的のデータベースであることは登録利用者の間では合意ができていると考えています。しかし,優れた漢字デザインエンジンを用いて明朝体の創作漢字を作ってみたいという人も一定数いると考えます。
    • そこで,
      • (責任を明確にするため)登録利用者に限る
      • 著作権を主張できなくなる(グリフウィキの方針に基づく)
      • ユーザー占有グリフにて登録する
    • という制限を理解してもらった上で,学術目的の妨害をしない範囲で許可するという方針にするのはどうでしょうか。具体的制限についてですが,1人につき「1日1個まで」かつ「30日間に10個まで」程度が適切だと考えます。制限回避目的の複数アカウント取得はスパムと見做すものとします。
    • ここでいう創作漢字とは,利用者自身が思いついた創作漢字に限り,ネット上や街中・書籍上に存在するもの(利用者以外が考えたもの)は含まないものとします。また,書き間違いや作字ミスによる異体字も含まないものとします。これらはデータベースとして収集する価値のあるものと考えられるためです。但し出典は必須とします。
    • なお,交流の場としての利用を禁止することについては賛成いたします。漢字や文字コードに関わる人同士の交流であっても,Twitterなどの然るべき交流の場がある以上,わざわざデータベースを交流の場にする必要は無いと考えるためです。
    • 以上,--spinda-kkmr 2020年10月8日(木) 17:46
    • 追記。別件になるかも知れませんが,sandboxに投稿練習目的で投稿する場合であっても,匿名利用者の投稿回数には制限をかける方が良いと思います。大量の投稿履歴のせいで他の履歴が見づらくなるためです。--spinda-kkmr 2020年10月8日(木) 17:51
    • 私自身の意見では、Glyphwikiで編集する場合は、アカウントを登録する必要があります。そうしないと、sandboxも例外ではなく、編集できなくなります。これにより、これを効果的に防ぐことができるようです。
      なお、中国大陸のユーザーはtwitterを使えません。--fitzgerald 2020年10月10日(星期六) 00:09

  • グリフウィキ13周年の直前にサービス不能となってしまい、若干ショックだったのですが、少し考えてみました。それで前々からも申し上げていますが、表面に見えていない迷惑投稿も踏まえると、やはり匿名ユーザーを排除するのは難しいです(迷惑投稿者が登録ユーザーに移ると面倒なので)。そこで一つ再提案ですが、sandboxの投稿を1IPアドレスおよび1ユーザーごとに一日10グリフまで、とすると、意外と解決するのではないかと思ったのですがいかがでしょうか。もう少し減らしてもいいですが、まずは10個で。--kamichi 2020年10月15日(木) 11:29
  • Fizgeraldさんの意見を支持します。なお、編集回数制限については、10回以上編集したい場合、ユーザーから管理人に自ら申し出て許可を求めることがよさそうだと思います。なぜかというと、私も特定目的で10回以上編集したことがあったからです。(sandbox@8164sandbox@8182jjanggu 2020.10.15
    • あなたは私の名前を間違って入力したようです。--fitzgerald 2020年10月15日(星期四) 23:50

  • すみません、意見を180度変えました(この表現は日本語以外でも通用するでしょうか?)。まず、プログラムを確認したところ、バージョンが5桁になっても問題は起きないことがわかりました。1か所桁あふれの制限があるところがあるのですが、現時点ですでに5桁まで対応する設定になっていました。全く勘違いしていました。それから、最近更新したページ(Special:RecentChanges)からsandboxを外す(自動投稿などと同じようにフラグでON/OFFを切り替える)だけでよく、練習用ページに制限を課す必要はないのではないかと思うに至りました。いかがでしょうか?--kamichi 2020年10月15日(木) 19:32

  • 創作漢字の制限について議論が止まってしまっていますが,
    • 責任を明確にするため登録利用者に限る
    • 著作権を主張できなくなる
    • ユーザー占有グリフにて登録する
  • の3つに加えて
    • 自作の創作漢字であることをメタ情報に明記する
  • という制限を付けて,取り敢えずは「学術目的を妨害しない範囲」という緩めの規制をかけることにし,より明確な規制が必要になったらその時に定める,という事でどうでしょうか。なお,制限対象は利用者が思いついた創作漢字に限り,ネット上や書籍上にある,ユーザー考案でない創作漢字は制限対象外とします。
  • 以上,--spinda-kkmr 2021年3月3日(水) 17:28
  • 上記の補足説明です。「緩めの規制」とは特に具体的なグリフ数制限等をかけないという意味です。仮に一般の方々(漢字や文字コードに関する深い知識の無い人)にグリフウィキが爆発的に知れ渡って創作漢字グリフで溢れかえるようになったら具体的なグリフ数制限が必要になるでしょうが,現状ではそのような心配は無いだろうという意味です。--spinda-kkmr 2021年3月16日(火) 23:22
    • もう1つ補足です。(私の提案で)制限対象外のネット上・書籍上・街中等の「ユーザー考案ではない創作漢字」については,
      • 命名は“sosaku-#####…”(後ろはヘボン式ローマ字)とする
      • メタ情報に出典とIDSを明記する。出典がウェブ上の場合はInternetArchiveやウェブ魚拓を取得して,出典が失われないようにする
    • この2つをルールとして提案いたします。なお,過去に“sousaku-#####…”で命名されているグリフは遡って修正はしませんが,今後新たに作成された場合は命名ルール違反として“sosaku-#####…”に移動するものとします。
    • 以上,--spinda-kkmr 2021年3月24日(水) 17:37
    • 中国(香港、台湾などを含む)ソースの創作漢字の命名は拼音でよろしいでしょうか?--jjanggu2021.3.24(水) 17:45
    • それで良いと考えます。要は「その言語をラテン文字で表記する場合のルール」です。日本語はローマ字のルールが複数あるのでヘボン式と指定しました。なお,英語等の外来語を含む場合は元の綴り優先が妥当と考えます。--spinda-kkmr 2021年3月24日(水) 17:50
  • ユーザー考案の自作の創作漢字の命名について,1つ提案いたします。GlyphWiki側が機械的に創作漢字であることが分かるように,“ユーザー名_sosaku-#####…”での命名をルールとするのはどうでしょうか(ユーザー占有グリフであることには変わりません)。既存不適格命名はユーザーの責任で移行することとします。--spinda-kkmr 2021年3月26日(金) 17:03

  • 提案が錯綜してきたので表形式でまとめます。現時点ではあくまでも私の提案です
ユーザー考案の創作漢字ユーザー考案ではない創作漢字
命名ユーザー名_sosaku-#####…
ユーザー名_#####…
sosaku-#####…
グリフ数制限当面は具体的には定めない
学術目的を妨害しない範囲
出典がある限りは制限無し
その他のルール登録利用者に限る
著作権を主張できなくなる
自作の創作漢字であることをメタ情報に明記する
メタ情報に出典とIDSを明記する
出典がウェブ上の場合はArchiveを取得する
  • いずれの場合も命名の後ろ部分は日本語はヘボン式ローマ字,中国語は拼音とする。英語等の外来語は元の綴りを優先する。また,IDSも許容する(混用は不可)。
  • 以上,--spinda-kkmr 2021年3月26日(金) 17:36

  • spinda-kkmrさん、まとめてくださってありがとうございます。基本的に全賛成です。少しコメントすると、若干ルールが複雑かなという気はします。それとユーザー占有グリフにもsosakuを強制することについて、実質的にルール違反への対応はできないので、状況が改善しなければアカウントBANで対応することになるのかと思います。--kamichi 2021年3月26日(金) 23:58
    • では,ユーザー考案の創作漢字については命名は各自の管理に任せるということでどうでしょうか。メタ情報への創作漢字である旨の表示は,ライトユーザーや検索で偶々GlyphWikiに巡りついた人が実在漢字と誤認しないように必要であると考えます。--spinda-kkmr 2021年3月27日(土) 12:41
    • ユーザー占有グリフは当該ユーザーが覚えやすいことを前提としているので、ユーザー占有グリフで作字する場合、センシティブな字句が使用されていない限り、それぞれ自分の命名ルールと表記に従っていいと思います。--jjanggu 2021年3月27日(土) 13:04

sandboxのエイリアス指定の禁止について

  • つい最近まで、既存のグリフをそのまま編集せずサンドボックスに入れてそのエイリアスにするような投稿が数回あったのですが、そうするとサンドボックスの意味がないので、こういう行為を禁止することができますでしょうか? --jjanggu

  • エイリアスの意味の確認という意味では、禁止まではできないかと思います。数量の制限で解決できると考えています。--kamichi 2020年10月15日(木) 11:24

ハングル集合について

  • sim-chさんが、今度は明朝体相当のハングルグリフセットを作成してくださいました。必要ならデータを提供してくださるとのことで、kesuukoさんなどの意見が欲しいとのことでした。例えば、以下の対応が考えられます。
    • A)今のハングルセットを置き換える
    • B)別名で明朝ハングルセットを置く。花園明朝に(そもそも外す可能性も考えていますが)どちらを入れるかは別議論とする
    • C)既存のハングルグリフセットで満足しているので不要
    • D)その他
  • 皆様のご意見をお願いします。--kamichi 2020年9月13日(日) 22:48
    • 私はB案に賛成し、グリフ名は「uXXXX-var-XXX」とすべきだと思います。--kesuuko 2020年9月13日(日) 23:11

    • C。完全に明朝体(漢字風)のハングルはほとんどの場合でデザインフォントとして認識されており、一般的な場合でのハングルの表示には適さないので、現在のハングルで十分です。--jjanggu 2020.9.13
    • C。jjangguさんのおっしゃる通りと思います。sz 2020年9月18日(金) 10:47
      • 又、伝統と離れた妙な字形が多くあり(𠤎=ㄷ、⿱一八=ㅠ等)、普段用の書体(display font に非ざる物)として扱うのには同意できません。sz 2020年9月18日(金) 13:03
      • 匕はㄷじゃないですよ。ㄷは「匸」です。「匕」は「訓民正音圖解」に現れる혓바닥소리すなわち[ʈ]のような音です。まだUnicodeに含んでいないハングルです。--sim-ch 단기4353년9월19일(토) 오후12:00
      • WindowsのGulimというハングルフォントではㅠは左の丨が丿になりました。今のところ筆劃避讓のため、對稱性を考えて一部のㅠの右の丨を丶になるのはどうして妙でしょう?--sim-ch 단기4353년9월19일(토) 오후12:08
    • でも、北朝鮮の「광명체」(光明体)は多くの場合で使用していますけど…Soonwha(すなわち最近わたしが新しく作ったその明朝体のハングルフォント)は光明体と似ていますが…--sim-ch 단기4353년9월18일(금) 오전11:01
    • また、韓国もそんな風のフォントがあります。HanYangがデサインした「순명조」というフォントです。--sim-ch 단기4353년9월18일(금) 오전11:07
    • Bが好ましいと考えます。花園明朝には既存のハングル文字セットを入れ,明朝ハングルセットはグリフウィキ登録漢字のうちハングル文字圏の主要文字コードの漢字を収録したものとし,韓国語に詳しい人向けのフォントにしてはどうでしょうか(UROに限っては完全収録とし「仮想K字形」の文字も入れる)。名称については別途議論すればよいと思います。--spinda-kkmr 2020年9月19日(土) 21:07
  • まず、sim-chさんにお願いです。署名の年表記は西暦にしてください。各文化圏で自前の年表記を使われると混乱します。いろいろあって楽しいですが。さて、Cの意見も多いですが、Bの意見もありますので、Bでいかがでしょうか。ただ、「-var-」だと後ろの番号が統一できない可能性があること、仮に「-var-001」で統一できたとしても、従来のUCSの「var」の数字の非関連性を考えると混乱しそうなことを踏まえ、「接頭辞」を1つ作って「****-uHHHH」とするのはいかがでしょうか。「****」をどうするかについてはsim-chさん、アイデアをください。--kamichi 2020年9月19日(土) 13:04
    • 「****」を「soon」になるのはどうでしょう?SoonwhaとSoonbonの「soon」(순)です。ところで、一部の部品を組合せたら筆画は細かくなりました。例えばsimch-hangul_u116e-3simch-hangul_u11c0-1を。そんなものは不自然だと思っていますけど…どうやって解決できるかをお教えください、そのうえで字形データを用意してあなたに送ってあげます。--sim-ch 2020/09/19 午後02:49
    • 回復お願いいたしますけど… --sim-ch 2020/09/27 午後10:40
  • 仕事が通常期に入ってしまったので、反応が悪くてすみません。それで、筆画が細くなるのは自動調整機能によるものなのですが、具体的に細くなってしまう例を出していただけないでしょうか。それで、KAGEデータを手で書いて自分で細くすることはできるのですが、細くしない(自動調整させない)ことはできなかったと思います。ですので、解決は難しいかもしれません。--kamichi 2020年9月29日(火) 15:32

IVDグリフにおけるエイリアス・被エイリアスの優先について

  • IVDとAJ1文字集合、戸籍統一文字などの関係において、どちらが主(実体グリフ)となるべきでしょうか。過去に言及された方はいますか?一見後者の方が字形の安定性がありますが、IVDは理論的には全く同じ字形になるので、前者を主としても構わないと思いますし、グリフウィキではUCSをベースに位置づけているのでより適切かと考えます。--kamichi 2013年2月23日(土) 15:30
    • IVSグリフについては、私は現状に反して、IVSを実体とすべきではないのかなと思っていました。公共性も安定性もIVSだと思います。UCS優先なら尚更です。問題はソースがやや不明瞭(?)であることでしょうか?戸籍統一文字やCJK統合漢字のCode Chartsより汚いと思います。--kirikaxfan 2013年3月11日(月) 22:45
    • 私もIVSグリフについて,IVSグリフ“u(2)####-ue01##”を実体とすることには基本的には賛成です。ただし例外として,JIS X 0208:1997字形“j90-####”(以降,旧JISとします)が含まれる場合は,例外としてそちらを優先するのがよいと思います。現在の日本語の情報機器の環境は,WindowsPCの多くはJIS X 0213:2004字形(以降,新JISとします)ですが,携帯電話などのモバイル機器では今でも旧JISがほとんどです。また,印刷物では旧JISと新JISが混在している状況です。ですので,旧JIS・新JISに関わる“j90-####”のうち字表:JIS2004で例示字形が変更された文字に含まれるものについては,こちらを優先して“j90-####”を実体にするのがよいと思います。--spinda-kkmr 2013年3月27日(水) 19:34
    • 追記。Jソースが存在するUnicodeのコード位置については,Jソース字形の無印UCSグリフを優先して実体とすべきと思います。--spinda-kkmr 2013年3月27日(水) 20:21
    • 追記。前言とは意見が少し変わることになりますが,実体になると分かりにくいのは戸籍統一文字“koseki-#####0”や住基ネット統一文字“juki-####”などなので,「その字形が汎用電子にのみ存在する場合はIVSを優先するが,AJ1に存在する字形,またはJISのバージョン間で字形が異なる場合は,無理にIVSを優先しない」でどうでしょうか。「溢」等は,j78-306ej90-306ejx1-2004-306eのようにJISのバージョンによって字形が異なるため,このようなグリフはJISを優先して実体化するほうが望ましいと思います。--spinda-kkmr 2013年4月20日(土) 10:48
    • 追記。ufa5bufa5fのようにCJK互換漢字に存在する字形の場合は,CJK互換漢字コード位置のグリフを優先して実体にすべきと考えます。IVSに比べれば互換漢字のほうが利用できる環境が多いのでより重要と考えるためです。--spinda-kkmr 2013年4月20日(土) 11:01
  • 前言を撤回することになりますが,私はIVSを実体にすることには反対です。IVSのコード位置には規則性が無く,「再」ではu518d-ue0100u518d-ue0101のように旧字体に若いコード位置が割り当てられているのに,「辻」ではu8fbb-ue0100u8fbb-ue0101のように新字体に若いコード位置が割り当てられています。これでは混乱の原因となります。varを用いて命名する方がよいと思います。--spinda-kkmr 2013年8月18日(日) 10:08
  • 別の議論(漢字データベースで提唱している、すべてをvar,itaijiで表現してフォントに取り込む)はここでは考えないという前提としたときに、純粋にIVD(IVS)グリフ名とその実態(現状では全てに別の名前を振る事が可能)のどちらが実体に良いかというときに、AJ1や戸籍統一文字については安定したグリフと考えられるので実態名(AJ1など)を優先してもいいと思っています。ただ住基は「若干」、登記は「割と」、認知度が低いと考えると無尽蔵に実態名に寄せるのも、とは思います。ただし、ルールとして決めた、という合意がとれるのであれば、特にこれ、という意見はありません。--kamichi 2013年8月19日(月) 22:45

  • 古い議論を掘り返すことになりますが,IVD(u(#)####-ue01##)と戸籍統一文字(koseki-#####0)やMJ(jmj-######)等の間にどちらを実体にするかの優先順位が決められていないため,ユーザーによってどちらかに寄せようとする方針が異なると編集合戦になる可能性があります。エイリアス入れ替え実装により実体を寄せることは6年半前よりも容易になっています。GlyphWikiとしての方針(目安程度の緩い規則でもよい)を決めるべきと思います。
  • 私の現在の意見は,
    • AJ1とそのIVDでは優先順序無し(GlyphWiki:prefixに基づく)
    • Hanyo-DenshiコレクションとMoji_JohoコレクションはIVD優先
  • です。GlyphWikiはUnicodeベースのデータベースなのでUnicode由来の命名を優先した方がいいという理由からIVD優先が好ましいと思います。私が過去にIVDに反対してvarを使うべきとしたのはIVD(IVS)を使える環境が少ないためですが,Word等の主要なソフトウェアがIVSに対応しているため,IVD(IVS)を排除する理由が薄れてきたためです。
  • 以上,--spinda-kkmr 2020年4月4日(土) 19:05
  • 追記。既にvarが実体になっている場合は,無理にIVD(IVS)を実体に寄せる必要は無いと考えます。--spinda-kkmr 2020年4月4日(土) 19:13
  • ユーザーごとの方針の違いによるエイリアス入れ替え合戦が起こる可能性が高いので,早急な議論が必要です。議論を深めるため,この項目を先頭にいたします。意見のある方はお願いいたします。--spinda-kkmr 2020年4月29日(水) 18:18
    • 上記に「Hanyo-DenshiコレクションとMoji_JohoコレクションはIVD優先」とありますが,AJ1やUnicodeのJソース,JIS等の命名がある場合はそちらが優先となります。要は「戸籍や住基,登記統一文字はなるべく実体にしない」ということです。--spinda-kkmr 2020年4月29日(水) 18:21
    • なお,参考に私の意見を書いておきますと,「Unicode(J/JV)>JIS90(JIS2000)>AJ1≓JIS83≓JIS78>Unicode(GHTK等の日本以外ソース)>UnicodeIVD(汎用電子・文字情報)>MJ(jmj-######)>戸籍>住基>登記」です。--spinda-kkmr 2020年4月29日(水) 18:42

  • spinda-kkmrさんの最後のご提案を基本ルールとし、編集合戦が起きた場合の解決の根拠にするということでお願いします。ただ、このルール化をもって既存のエイリアスをすべてを整理する、ということではなくまずは問題解決の際に用いるということでお願いします。--kamichi 2020年10月15日(木) 11:22

KAGE engineのリファクタリングについて

何度か言及しながらあまり具体的な成果がありませんでしたが、この度大幅なKAGE engineの内部実装の整理をしてみたので、エンジンのほうに興味のある方、特に作者のkamichiさんにご意見を伺いたいです。量が多くなってしまったのと、今後も頻繁に更新すると思うので、詳細は用户-对话:turgenevに記載しました。--turgenev 2020年3月26日(木) 00:33

「𣇋」的-jv字形

此字是「晚」的異體字,「𠂊」-->「丷」,右邊應該保留從「兑」而不用「兌」。 hkcs 2020年1月10日(金) 01:45

変体仮名の関連字について

変体仮名の関連字について方針が現在ありませんので,GlyphWiki全体としての方針を決めた方がいいと思います。私は「元になっている漢字を関連字にする。関連字無し(〓)にはしない」が好ましいと考えます。GlyphWikiは本来漢字のデータベースなので,漢字を基準にするのが好ましいと思うからです。--spinda-kkmr 2019年12月27日(金) 20:45
  • 私は賛成です。そのようにした方が探しやすいと思われます。通常の仮名文字(u3042u30a2など)も同様にすべきかは別件で議論を行うべきだと思います。--kesuuko 2019年12月27日(金) 20:50
  • 他の同音仮名はメタ情報で見れるわけですし、それで良いと思います。yoshiciv 2019年12月29日(日) 18:51

KAGE/engineの改良について

以前投稿した曲線の近似などを含め、KAGE/engineを改良できればと思っています。機能追加のほかに、いわゆるリファクタリングとして ・関数への切り分け、重複の削除 ・変数・メソッド名の修正 ・コメントの充実 ・誤字の修正 等々も考えていますが、いかがでしょうか。Gitはこれから慣れていく予定です。 --turgenev 2019年8月3日(土) 19:57
    • 誤字の修正はともかく、ストロークの種類を表す数字(4:乙曲線、99:他グリフの引用 など)を数字のまま書かず列挙体(enum)にするなどの変更については、ソースを読み慣れた人にとってはあまりメリットがない(もちろん初めて読む人にはメリットがある)割にコードの量は(少しですが)増えるので考え方次第かとは思います。また、プログラミングの知識のある利用者も一定程度いると期待してこの場に書き込みましたが、もしふさわしくないようであれば場所を(Gitなどに?あるいは会話ページ?)変えます。--turgenev 2019年8月3日(土) 21:04
    • あとは、現在のKAGEエンジンによる曲線部分の太さなどのデザイン・感覚的要素をどれほど重視・維持する必要があるのか(あるいは変更結果についての意見をどこで募るか)についても伺いたいです。ただ単に直線を近似した曲線に変える、というだけの変更ではうまく行かない気がしています。現在の「とめ」「はらい」(というより、書き始めから書き終わりにかけて線の太さが変化するストローク全般)の細くなっている側の処理は、ややアドホックな印象があり、素直に近似するにはおそらく適しません。また、「とめ」の最後は半円ではなく五角形になっています。これを円にするというだけでも字のバランスへの影響はある程度発生すると思います。--turgenev 2019年8月3日(土) 22:03
    • 将来的には、ゴシックへの対応も含め、エンジン(肉付けの方式)が複数あってそれぞれに対応したデザインがGlyphwiki上で編集できるという状態になることも考えられるので、一旦思いついたデザインは捨ててしまわないほうが良いかもしれないですね。--turgenev 2019年8月3日(土) 22:47
    • すみません、夏休みに時間が取れたら検討したいと思いつつ、もうすぐ終わってしまいますね。ご提案ありがとうございます。一つ気になっているのはエンジンを変更すると既存の非漢字データへの影響が大きいと思われることです。ですが、前向きに考えたいです。ただ、KAGEデータのフォーマットはあまりいじらなくてもいいかなと思いつつあります。--kamichi 2019年8月26日(月) 23:44
    • KAGEエンジンやGlyphWikiの今後について、時間を取って議論できたら(あるいは人がいなければ私の頭の中で検討できたら)良いなと思っています。地理的時間的に無理であれば会合ではなく、オンライン討議で構わないと思います。これはどこかページを変えてやりましょうか。コアなユーザーの方を含め、ご相談に乗っていただける余裕は皆様ございますでしょうか?--kamichi 2019年8月26日(月) 23:48
    • データフォーマットではなく内部処理の変更です。紛らわしくてすみません。とりあえずデザイン(というより全体の挙動)を変更しない範囲でもソースコードの改善はできそうなので只今作業中です。曲線部分の処理については、現在のデザインの「変更」よりは「(字体の)追加」というような形でマージできたらと思っています(パラメータを一つ変えれば、変更済のデザインで字形が生成される)。
    • 非漢字についても、一つの符号位置に対して、それぞれのフォント(ゴシック、明朝、変更後の明朝、etc.)に対応した複数のグリフを関連付けることができるようになれば、既存の体系を破壊せずに済むと思います。もちろんこれはすぐにできる変更ではないと思いますが、Glyphwikiの共有・編集・他グリフ引用等々のシステムをたった一つの明朝体デザインだけに使うのは勿体無いのではないかと個人的には思っているところです。議論の活発化を私からも期待します。--turgenev 2019年8月29日(木) 16:38
    • ただいまコードの整理中なのですが、adjust系関数の適用の順序は結果に影響するでしょうか。箇所はkage.jsの11行目の
    • this.adjustKirikuchi(this.adjustUroko2(this.adjustUroko(this.adjustKakato(this.adjustTate(this.adjustMage(this.adjustHane(this.getEachStrokes(data)))))))); です。(私の実力不足でもありますが)解読に苦労しております。できれば、ソースコードにコメントなど増やしていただけるとありがたいです。あとは、動作テスト用に、ソースコードのできるだけ多くの場所を通るようなKAGEデータのセットのようなものがあると今後役に立つと思います。それと、KAGEエンジンに関するページを設けたほうがいいような気もします。(通常はGitHub上でやるのでしょうが、KAGE engineはGlyphwikiの利用者のコミュニティと切り離せるものではないと思うので。)turgenev 2020年3月13日(金) 12:27
    • 特にテストデータのあてがないのであればこちらでやってみます。コメントなども含め、今までの開発中に何かしら役に立ったもの、あるいは構造を明らかにしたものが既にあるのであれば、提供いただけたほうが手間が省けると思った次第です。turgenev 2020年3月13日(金) 12:37
      • ありがとうございます。kage.jsの11行目の関数の呼び出し順序はすべてではないのですが一部この順番が必要なはずです。具体的にはkageデータの1,2,3番目、とくに1番目の筆画種別について、100の位1000の位などに筆画の細さなどの情報が付与されるので、順番が変わるとうまく処理されなくなることが考えられます。それとテストデータセットについては特に想定していませんでした。取り急ぎ回答いたします。--kamichi 2020年3月13日(金) 15:12
      • 早速のお返事ありがとうございます。個人的には、adjust系の関数は一気に適用するのではなく必要に応じて(それぞれの画の描画時に、画の種類に対応して)呼び出されるほうが望ましいと考えていますし、情報を数値として付与するのも見通しが悪い気がします。また、cdDrawCurveやcdDrawLineの処理も、もっと細かく、画の種類ごとに分割したほうがいいと思っています。(機能は変わらないものの)内部実装としてはかなり大きな修正にはなると思いますが、今後も考えるとその方向で作業を進めたいと思っていますがどうでしょうか?turgenev 2020年3月14日(土) 00:08
      • 回転機能については、このページの下のほうにある通り、引用時に回転角度を指定できるようにしたほうが良いと思うのですが、機能的にそうしない理由などは何かありますでしょうか。turgenev 2020年3月21日(土) 22:53

VNPF命名の廃止について

VNPF - Vietnamese Nôm Preservation Foundation(會保存遺産喃) にて配布されているフォントの外字が大きく変更されていて、元データが参照できない為、vnpf-6XXXX命名を廃止すべきではないでしょうか。(なお、現在の外字は字表:prefix-vにてv-fXXXXと命名されることになっています。)--kesuuko 2018年11月25日(日) 17:59
  • “vnpf-6####”の新規作成は停止とし既存分は当面の間存置する,で良いと思います。ちなみに過去分のフォントについては一応InternetArchiveに残っている ようです。--spinda-kkmr 2019年3月20日(水) 17:15

KAGE/engineの曲線の近似について

現在のKAGE/engineでは(kUseCurveをtrueにした時の)曲線部分のベジェ曲線の計算方法は用户-对话:y-iijimaのようになっているかと思いますが、"bezier curve fitting"などのキーワードでいろいろと調べてみたところhttp://www.realtimerendering.com/resources/GraphicsGems/gems/FitCurves.c や、そのjavascript実装であるhttps://github.com/soswow/fit-curve を見つけました。だから何だという感じではありますが参考までに。turgenev 2018年11月10日(土) 01:43
  • 話題提供をありがとうございました。大変興味深いです。やることがたまりすぎていますが、これもキューに入れます。--kamichi 2018年11月11日(日) 14:47
  • 近似したい点の列と両端点での傾きを指定する内部仕様になっているようです。点の列だけを指定すると両端点それぞれの隣(一つ内側)の点から傾きを算出し、近似が悪くて分割する際の分割点での傾きは、その点の両隣の2点間での傾きを使用しているようです。KAGE/engineで使う場合は各点での傾きが予め決まっていますが、分割時にもそれを使用するように改変することは容易だと思います。turgenev 2018年11月17日(土) 22:51

回転機能に関して

↓以下、GlyphWiki:バグ報告-保存@19ゟ引用

  • 「u22a0b」のようなグリフは珍しいそうですが、ストロークの方向を逆にすると、ウロコなどが変になります

現在登録されたグリフ:u22a0b  バグ例:sandbox@115

これはテストだけですが、直線の場合には:「 http://jeroenhoek.nl/research/gwdftool.png 」こういう風書かれるといいかもしれません。jeroen 2009年1月16日(金) 13:12

KAGEエンジンの理念として、実用的な範囲でなるべく単純化する、というポリシーがあります。それでExt.B集合も含めると、現状のKAGEエンジンで表現できないグリフのタイプが(1)ミラーリング(2)篆刻体の等幅、の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さんは9年前に回転機能の追加を予定していましたが、9年程経った今も実装されていません。回転機能の追加をお願いします。--kesuuko 2018年6月3日(日) 01:02

    • ご提案ありがとうございます。KAGEエンジンの現在の作り方に依存して、以下の条件であれば、実装できそうなのですが、いかにもとってつけたような感じでスマートではないのですが、いかがでしょうか。--kamichi 2018年6月3日(日) 09:56

 KAGEデータに「0:999:角度:矩形左上X:Y:矩形右下X:Y」を追加し、その時点までに
 生成したポリゴンの任意の矩形を任意の角度回転させる。矩形が筆画の一部分に
 かかっている場合の影響は考慮しない。エディタでは編集不可のため、最後に
 手作業で付与する。

  • 回転(反転?)にはどのようなバリエーションが考えうるでしょうか。任意の角度としましたが、90,180,270度回転と上下反転、左右反転、などでしょうか。90,270度回転は縦と横の大きさが一致しないとアスペクトが変わりますが、それでもいいですよね。--kamichi 2018年6月3日(日) 10:19
    • それでよいと思います。私は回転は90,180,270度の3種類のみを想定しておりました。回転と反転を組み合わせれば大抵のグリフは作れると思います。現状では例えばobuso-1633-jv@1がかなり不恰好です。Unicode範囲内の漢字でこのように不恰好になっている例はあるのでしょうか? 非漢字グリフの作成まで考えるならば,任意角度の回転もできた方がよりよいことは確かですが… --spinda-kkmr 2018年6月3日(日) 10:37

 0:99:{1|2|3}:矩形左上X:Y:矩形右下X:Y ...回転(1:90度,2:180度,3:270度)
 0:98:0:矩形左上X:Y:矩形右下X:Y ...左右反転
 0:97:0:矩形左上X:Y:矩形右下X:Y ...上下反転

ご意見ありがとうございます。この3つで行きましょうか。--kamichi 2018年6月3日(日) 11:29

  • 第2,3パラメータが3桁になるのは影響が不明なため2桁に変更しました。--kamichi 2018年6月3日(日) 17:47
    • ということで、実装できました。プレビュー用エンジンのみ反映しているため、グリフエディタでは反映されません。近い将来グリフエディタをSWFからJS+Canvasに直しますので、その時まで保留とします。--kamichi 2018年6月3日(日) 19:03
    • なお、バッドノウハウになりますが、矩形が他の筆画と重なってしまう場合は、書き順を無視して回転・反転対象を先に書き、先に処理するやり方で回避できます。--kamichi 2018年6月3日(日) 19:04
    • ああ、部品内で97,98,99を使った場合、その座標が引き継がれないので影響が大きすぎますね。おっとっと…--kamichi 2018年6月3日(日) 19:06
      • そうではなくて回転対象矩形に他の筆画が混じったのでした。先ほどのバッドノウハウで回避はできますが、影響が出そうなので、改良します。--kamichi 2018年6月3日(日) 19:14
      • 回転反転対象の矩形に他筆画が入った場合にポリゴンがすべて入らない場合は回さないように修正しました。ただし、縦筆画の筆初めの右につく三角形のように小さな装飾ポリゴンが矩形に完全に入ってしまって一緒に処理されるのは防げません。--kamichi 2018年6月3日(日) 19:24
  • 45度単位の回転の追加をお願いいたします。45度単位の回転はirg2017-01989の作成の為に必要です(https://hc.jsecs.org/irg/ws2017/app/?find=T13-3378 )。--kesuuko 2019年12月9日(月) 14:22
    • 私も45度単位回転の実装をお願いいたします。u2bccを45度回転させてu2bcdを作成できるなど,非漢字グリフの作成に有用です。--spinda-kkmr 2020年3月13日(金) 18:40

文字幅等を定義するグループ

  • 文字幅等を定義するグループのフォント生成対応は、現在三グループに対応していますが、次のようにするべきだと思っています。--kesuuko 2018年3月26日(月) 15:05
グループ名 左端右端対応状況備考
(いずれにも入っていない)0200対応済み
字表:HalfwidthGlyphs0100対応済みUCSグリフ等のみ
字表:HalfwidthGlyphs-nonUCS0100未対応UCSグリフ等以外
字表:One-thirdwidthGlyphs067未対応
字表:One-quarterwidthGlyphs050未対応
字表:One-sixthwidthGlyphs033未対応
字表:DoublewidthGlyphs0400未対応
字表:TriplewidthGlyphs0600未対応
字表:NonSpacingGlyphs00未対応制御文字
字表:NonSpacingGlyphs-Halfwidth-1000対応済み半角の文字に対して合成
字表:NonSpacingGlyphs-Fullwidth-2000対応済み全角の文字に対して合成
    • 皆様のご意見をお待ちしております。

  • 喫緊で必要なものは追加に賛成ですが、どれでしょうか?--kamichi 2018年4月17日(火) 09:05
    • 最も必要度が高いのは字表:HalfwidthGlyphs-nonUCSです。このままでは非Unicodeの半角文字が利用できません。
    • 次に必要度が高いのは字表:NonSpacingGlyphsです。このグループに登録しておけば自動的にフォント生成対象から除外するようにすれば,制御文字が制御文字の字形そのままで登録されていても(例:u2d7f)いちいち気にせずにフォント生成できるので便利です。
    • 以上,--spinda-kkmr 2018年4月17日(火) 17:50
    • 字表:NonSpacingGlyphsに関して、私は反対です。私は字表:NonSpacingGlyphsの文字はufeffのように幅無しの空白をフォントに入れることを意図して提案したので、私は賛成できません。私は、字表:フォントに含まれるべきでない符号位置として、白紙化された符号位置(u1f620など)も含めてページ化すべきだと思います。字表:HalfwidthGlyphs-nonUCSに関しては、極めて緊急性が高いので、私も賛成します。--kesuuko 2018年4月17日(火) 22:55
    • 字表:HalfwidthGlyphsが容量オーバーになりかかっているようです。上記対応と同時にこのグループを分割し,字表:HalfwidthGlyphs-BMP字表:HalfwidthGlyphs-SMPの2つに分けるのがよいと思います。もちろん半角対応をしたうえでです。
    • あるいは,字表:HalfwidthGlyphsの配下にあるグループはすべて半角グリフになるというシステムに変更し,そのうえでBMP,SMP,nonUCSの3グループをそこに登録するというシステムでもよいと思います。
    • また,字表-讨论:HalfwidthGlyphsにあるように,ユーザー占有の半角グリフを作成したいという需要もあるようです。もし対応するのであれば,nonUCSの末尾に追加してもよいというルールにするか,あるいはuser-exclusiveという4つ目のグループを作るかのいずれかとなると思います。ただ,ユーザー占有の半角グリフを許すかどうかはルール化されていないので,議論が必要と思います。
    • 以上,--spinda-kkmr 2018年6月3日(日) 10:54

  • 取り急ぎ字表:HalfwidthGlyphs字表:HalfwidthGlyphs-BMP字表:HalfwidthGlyphs-SMPに分け、この2つのページをフォント生成時に参照することの作業のみ着手します。--kamichi 2018年6月3日(日) 11:34
    • 分離しました。それで、non-UCSについてですが、現状のグリフウィキのフォント生成は、UCSコードに対するグリフ記述によって収録グリフを指定するので、non-UCSのページを反映させることができません。つまり、「aj1-xxxxx」というグリフがあって、それを「U+00xx」に割り当てる形でフォントを生成しようとした場合、BMPページにある[ [u00xx] ]という記述に基づいてそのグリフが半角扱いとなります。ということで、non-UCSのグリフをどのようにフォント生成に反映させるかについて、イメージをお知らせください。--kamichi 2018年6月3日(日) 15:28
      • 私は、 uf0021(aj1-00033) uf0018(sawn-f0018) とグループページに記述された場合、そのフォントのU+F0021やU+F0018が半角になると考えています。--kesuuko 2018年6月3日(日) 15:37
      • 私もそう考えておりました。非UCSのグリフについてはグリフ単位で半角化されると考えています。なお,UCSグリフについても,例えばu203cはグリフウィキではデフォルトで全角ですが,これを u203c(u203c-halfwidth) とすれば半角化できると考えております。--spinda-kkmr 2018年6月3日(日) 15:47
      • ちょっと混乱してきました。以下の表の半角・全角の認識が一致するかどうか、および(1)と(2)はどちらでしょう?--kamichi 2018年6月3日(日) 19:40

[[ucs(半角記述あり)] ]半角
[[ucs(半角記述なし)] ]全角
[[ucs(半角記述あり) グリフ(記述あり)]]半角
[[ucs(半角記述なし) グリフ(記述あり)]]???(1)
[[ucs(半角記述あり) グリフ(記述なし)]]???(2)
[[ucs(半角記述なし) グリフ(記述なし)]]全角

  • 私の認識では(1)は半角,(2)は全角です。
  • つまり,UCS本来(グリフウィキでのデフォルト)の全角半角をグリフで書き換えられる,という意味です。これが使えないと「これはグリフウィキでは半角規定だが,全角にしたい」(またはその逆)といった利用法ができません。住基文字“juki-####”の非漢字グリフではUCSで半角の文字も大部分が全角になっているので,これができないとかなり困ります。
  • 以上,--spinda-kkmr 2018年6月3日(日) 19:53
  • 字表:spinda-kkmr_test0@42でテストしたところ,上記の2つの例は私の想定通りになっていました。 ue000(aj1-00632) だけが全角のままでした。現状では「UCSの半角全角の指定に関わらず,グリフの半角全角の指定を優先する」ようになっているようです。ですので字表:HalfwidthGlyphs-nonUCSに収録されるグリフも,フォント生成時に指定されるUnicodeコード位置に関わらず半角にする,でよいと思います。
  • 以上,--spinda-kkmr 2018年6月7日(木) 18:02
  • 字表:HalfwidthGlyphs-nonUCSが機能していないようです。このままですとAJ1等に含まれる半角グリフが利用できませんので,なるべく早くの対応をお願いいたします。現状ではグリフを半角指定するとコード位置に関わらず半角グリフになる仕様のようですので,それで良いと思います。--spinda-kkmr 2019年3月6日(水) 19:21

  • 議論が長期間停止してしまっていますが,字表:spinda-kkmr_test0@46で再テストしたところ,やはり字表:HalfwidthGlyphs-nonUCSは機能していないです。このグループにはAJ1に収録されている「半角ひらがな」や「半角濁点付きカタカナ」などの有用グリフがありますが現状では正常に利用できません。
  • 現状ではGlyphWikiでのデフォルトにかかわらずグリフがHalfwidthGlyphsに収録されていれば半角,無ければ全角になる仕様のようなので,単純に字表:HalfwidthGlyphs-nonUCSのグリフ幅を半角にするようにすれば特に問題ないと思われます。早急なご対応をお願いいたします。
  • 以上,--spinda-kkmr 2019年11月4日(月) 13:13

  • 字表:HalfwidthGlyphs-nonUCSの対応を早期にお願いいたします。繰り返しとなりますが,ここには「半角ひらがな」や「半角濁点付きカタカナ」などの有用グリフがあります。--spinda-kkmr 2020年3月13日(金) 18:40
    • 再度のお願いとなりますが,「半角ひらがな」「半角濁点付きカタカナ」等を利用したいので,早期に字表:HalfwidthGlyphs-nonUCSへのご対応をお願いいたします。
    • また,これを機にユーザー占有グリフの半角を許すかどうか,許すのであればどのグループに記述するのか(nonUCSに含めるのか,第4のグループを設定するか)も決めるべきと考えます。--spinda-kkmr 2021年3月3日(水) 17:33

接尾詞無しCJK統合漢字のグリフページのガイドページ化について

接尾詞無しのCJK統合漢字のガイドページ化の提案があります。

私は、このように考えております。

まず最初にu****(*)のグリフを5種類に分けます。

  • 1.非漢字及び互換漢字
  • 2.Jソースの存在する漢字
  • 3.Jソースの存在しない漢字
  • 4.簡体字特有の字形が含まれ、Gソースが存在する漢字
  • 5.簡体字特有の字形が含まれ、Gソースが存在しない漢字

その後、種類ごとに処理を行います。

種類処理
非漢字及び互換漢字何も行いません。
Jソースの存在する漢字u****(*)のデータをu****(*)-jにコピーして、u****(*)をu****(*)-jのエイリアスにします。
Jソースの存在しない漢字u****(*)のデータをu****(*)-jvにコピーして、u****(*)をu****(*)-jvのエイリアスにします。
簡体字特有の字形が含まれ、Gソースが存在する漢字u****(*)のデータをu****(*)-gにコピーして、u****(*)をu****(*)-gのエイリアスにします。
簡体字特有の字形が含まれ、Gソースが存在しない漢字u****(*)のデータをu****(*)-jvにコピーして、u****(*)をu****(*)-jvのエイリアスにします。

その後、次のような順番でシステムの改修などを行います。

1u****(*)からu****(*)-j、u****(*)-jv、u****(*)-gに部品の一括更新をする。
2接尾詞無しのCJK統合漢字をガイドページになるようにする
3接尾詞無しのCJK統合漢字を白紙化して実際にガイドページにする。
4接尾詞無しのCJK統合漢字を編集できないようにする。

以上です。--kesuuko 2018年2月10日(土) 19:05

  • ご提案ありがとうございます。最終的にはガイドページ化が想定されていて、時期尚早ということで見送られてきた経緯があります。提案に対しては(1)「簡体字特有」の字形とは何か、あるいはそれが含まれているからGソースとみなしていいのか(字形衝突、あるいは簡体字的字形の他地域での受容は考えないのか)(2)無印グリフ(ページではなくpngの直接参照)を参照すると何が表示されるか、それは妥当か、という2点が懸念されます。少し広く意見を欲しいところです。--kamichi 2018年2月12日(月) 15:03

    • 御回答ありがとうございます。(1)に関しては、字形衝突が起きないようにすれば問題ないと思います。(例えば、u22016は簡体字特有の字形だが、u5723は簡体字特有の字形ではない。)また(2)に関しては、Gソースの有無を確認するため問題ないと考えております。--kesuuko 2018年2月17日(土) 11:51

    • 「簡体字特有の字形」という言葉はGlyphWiki:仮想J字形のガイドラインに出てきますが、現状「簡体字特有の字形を含まない漢字の無印グリフは(仮想)J字形にして、そうでない(=簡体字特有の字形を含む)漢字の無印グリフはそのソースの字形(大概はGソース)にする」というルールで運用されているので、統合漢字の無印グリフu(X)XXXXは上の表にしたがって実質的にu(X)XXXX-j/jv/gと読み替えられる状況になりつつあると思います。そういうわけでu(X)XXXXをガイドページにするとき、現在u(X)XXXXにあるデータの行き場としてu(X)XXXX-j/jv/gを上の表にしたがって選ぶのは妥当と思います。―twe 2018年2月22日(木) 17:16
    • (2)については「花園明朝にどのグリフを収録するのか」としても同じ問題があると思いますが、現状の無印グリフの優先順位(JIS X 0213:2004 > JIS X 0212 > J欄字形 > AJ1 > 仮想J字形 > 簡体字 でしょうか?)で決定するのが字形が変わらなくて無難と思いますが、複雑過ぎますかね。―twe 2018年2月22日(木) 17:16
      • 花園明朝についてはこれを機にSource Han Sans/Serifのように地域ごとに別のフォントにするというのもアリかもしれません。(話が飛んでしまいました)―twe 2018年2月22日(木) 17:16
      • Noto フォントでもそうですが、GSUB loclフィーチャを使えば複数国語の書体を同一フォントに入れることは可能です。 golconda 2018年3月6日(火) 22:59
  • 賛成です。考えるとすれば次のような感じでしょうか。--kesuuko 2018年2月25日(日) 01:31
※他にもUソースが存在しますが、ここでは省略します。
フォント名内容
1花園明朝JA現在の花園明朝Aと同じ
2花園明朝JB現在の花園明朝Bと同じ
3花園明朝GA花園明朝JAのグリフをG字形+仮想G字形に置き換えたもの
4花園明朝GB花園明朝JBのグリフをG字形+仮想G字形に置き換えたもの
5花園明朝KA花園明朝JAのグリフをK字形+仮想K字形に置き換えたもの
6花園明朝KB花園明朝JBのグリフをK字形+仮想K字形に置き換えたもの
7花園明朝VA花園明朝JAのグリフをV字形+仮想V字形に置き換えたもの
8花園明朝VB花園明朝JBのグリフをV字形+仮想V字形に置き換えたもの
9花園明朝TA花園明朝JAのグリフをT字形+仮想T字形に置き換えたもの
10花園明朝TB花園明朝JBのグリフをT字形+仮想T字形に置き換えたもの
11花園明朝HA花園明朝JAのグリフをH字形+仮想H字形に置き換えたもの
12花園明朝HB花園明朝JBのグリフをH字形+仮想H字形に置き換えたもの
13花園明朝MA花園明朝JAのグリフをM字形+仮想M字形に置き換えたもの
14花園明朝MB花園明朝JBのグリフをM字形+仮想M字形に置き換えたもの
15花園明朝KPA花園明朝JAのグリフをKP字形+仮想KP字形に置き換えたもの
16花園明朝KPB花園明朝JBのグリフをKP字形+仮想KP字形に置き換えたもの

  • (1)については,とりあえず「簡体字特有」を「“Gソースのみ”または“GソースとHソースのみ”」(Jソースは存在しない前提で)と解釈していったん機械的に処理し,その後で面倒ですが1つ1つ目視点検して調整するしかないと思います。
  • (2)については,tweさんの意見に賛成です。CHISEでどの文字集合に存在するのかがUnicodeコード位置から検索できるので,処理は比較的容易だと思います。
  • kesuukoさんの花園明朝ソース分割についてですが,Jソース版のフォント名は変更すると混乱するので現状維持がよいと思います。ソースごとのフォントは作成作業に相当時間がかかると思いますがアイデアとしては良いと思うので,まずはGソース版とKソース版を優先して作れると良いと思います。Kソース版は2点之繞や旧字体の食偏などを異体字セレクタに頼らずに表示できるようになるので,日本人にも利用価値が高いと思われます。
  • 以上,--spinda-kkmr 2018年2月25日(日) 10:52

  • では、spinda-kkmrさんの意見の通りに実行することとしてよろしいでしょうか。--kesuuko 2018年3月4日(日) 16:40
    • ここ数週間、議論が進展していません。皆様に最終確認を行います。spinda-kkmrさんの意見の通りに実行することとしてよろしいでしょうか。--kesuuko 2018年3月26日(月) 15:05

  • 時間がないのでspinda-kkmrさんのご意見に絞って部分的に書きます。(2)についてKソースは反対です。なぜなら「Kソース」の字形を韓国の人は少なくとも一般的と思っていない事例があるからです。我々にとって「伝統字体」が使えて便利というのであればそれは「K」ではなく「伝統字体」というラベルで切り出すべきと思います。Gソースは問題ないと思います。とくに(1)については決定しても着手できるのかという大きな問題があります。積み上がり過ぎている諸問題に優先順位をつけて取り組みたいと思います。--kamichi 2018年3月29日(木) 21:49

  • 別の話題でGoogle FontsにようやくHanaMinが取り込まれるという話題があります。個人的にはまだ時間がかかるのではないかと思っているのですが、そうであるなら今後各規格票字形フォントを一般のHanaMinと切り離した形で個別実装しても良いと思います。HanaもMinも日本語なので、もう少しユニバーサルな名称で独立させるとかいかがでしょうか。ただしそうなると必然的に話が大きくなってしまうので、それとは別に当初の議題である無印UCSの扱いについては別途詰めないといけません。問題がゼロとは言いませんが、無理やり分離して、ぼちぼち直していく形で着手しましょうか。--kamichi 2018年4月17日(火) 09:10

簡体字のUソース

簡体字にはUソースとGソースが存在しますが、UソースとGソースでu9485のように、一部異なる字形が存在します。このような文字の場合、どのような字形を仮想J字形とするのが望ましいでしょうか。--kesuuko 2018年1月5日(金) 17:57
  • 簡体字のUソースというのはどれのことでしょうか。ちょっと混乱しています。--kamichi 2018年2月2日(金) 12:54
    • 簡体字のUソースとは、ここではUソースの文字のうち、簡体字特有の字形を含むものをいいます。--kesuuko 2018年2月6日(火) 20:35

JV source shaping for ancient Chinese characters

One case is the left hand and right hand. The character is 𠬞 (or 廾 / 大 when as component in modern words, such as 樊、與), which means to push up. The original character is composed of left hand and right hand. (The flipped character, composed of right hand and left hand, is 𠬜.)
The left hand component in the Unicode sources are shaped inconsistently. Left hand is usually written as 𠂇 in modern text, such as 左. In the Extension B, sometimes it is written as 𠂈, with second stroke sometimes protruding third stroke. Sometimes it is written as 丩, with protrusion and without. However, 𠂈 and 丩 and 𠂇 are of completely different origin, so it would be better to differentiate and be consistent.
For left foot and right foot, the characters are currently 𡕒 and 夊. it just so happens that the if we remove the first stroke, we get 丩 with left protrusion. I think it is better to unify it that way? chanhenryfaihang 19:36, 23 May 2015

どなたか,上記英文を日本語に翻訳してください。--spinda-kkmr 2015年5月24日(日) 10:06

Propose unify characters containing u20b1e@5 (left hand 𠂇 + right hand 又). Inconsistencies in the left hand component:

By etymology, left hand (𠂇) =/= u20088 (殄) =/= u4e29 (丩) Therefore, propose using u20087-01-itaiji-001: u20b1e-03, u20b1e-04

above -- hkcs 2016年9月30日(金) 20:39