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

GlyphWiki:井戸端

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

目次

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

台湾語の文字について

台湾語の文字を見つけたのですがグループってどうやって作ればよいのでしょうか?命名方法とかに疎いので。作っていただければ登録に協力します。勝手なお願いで申し訳ありません。 http://olddoc.tmu.edu.tw/Taiwanese-6/T-C-J-E-word-1000.htm

  • 面白いですね。新規となるのは10数ぐらいでしょうか。前頭辞+発音がいいと思いますが、注音字母では読めない人もいますし、ローマナイズするにもどの方式か迷います。bopomofoのローマナイズって標準的なものはありましたっけ。--kamichi 2017年6月25日(日) 14:05

  • 有難うございます。おそらく今一番有力なのは「臺灣閩南語羅馬字拼音方案」でしょうか。二番目が教会ローマ字です。yoshiciv 2017年6月26日(月) 09:27

サンドボックス

グリフのサンドボックスはsandboxで問題ないと思いますが、同名を避けるためグループページのサンドボックスはグループ:サンドボックスとしました。しかし別言語で問題があります。別言語は別に設けるか、英名を考えて共通化するための方針再変更をするか検討中です。なお「GlyphWiki:」は許容しない方針のままとします。--kamichi 2017年5月31日(水) 22:50

Unicode 10.0の変体仮名の収録について

Unicode 10.0では変体仮名がKana SupplementとKana Extended-Aに収録されるようです。グリフ自体は“jmj-######”に作成済みですが,Unicodeとの対応表を今のうちに作成しておく必要があります。グループ-ノート:PipelineTableも参考にしてください。--spinda-kkmr 2017年5月5日(金) 19:24

  • 1つ勘違いしていました。変体仮名の“jmj-09####”は現時点では未完成でした。MJ番号と他のグリフの対応表はグループ:tsuruki-work-testに存在します。--spinda-kkmr 2017年5月7日(日) 10:15
  • MJ文字情報一覧表と戸籍統一文字では字形が違うものが多数確認できました。Unicode 10.0にはMJの字形で登録されるようです。また,戸籍統一文字や住基統一文字に無いMJ独自の変体仮名も多数存在します。そこで,可能な対応としては以下になります。太字が長所,斜体が短所です。
    • (1)MJ文字情報一覧表の変体仮名“jmj-09####”を全て作字するUnicodeに沿ったものになるので最も好ましい対応ですが,大量(300グリフ弱。MJと戸籍統一が一致するものも少数あるので実際はもっと少ない)の変体仮名を作成する必要があります
    • (2)MJ独自の変体仮名は先送りして,戸籍統一文字に存在する分だけ(既にグリフが存在するものだけ)を戸籍統一文字の字形で収録する既存グリフを流用するだけなので新たな作成の必要がありませんが,Unicode表で見ると歯抜け状態の収録になります。
    • (3)MJ文字情報一覧表の変体仮名“jmj-09####”のみを新たに作字し,それ以外は戸籍統一文字のグリフを流用する。(1)と(2)の折衷案であり,作字の手間と字形の正確さは上二案の中間程度です。戸籍統一文字に収録されている分については戸籍統一と同字形になるという意外な利点がありますが,Unicodeという視点で見ると字形が忠実なグリフと忠実でないグリフが混在します。
  • Ext.Fの正式収録が6月に迫っておりこの時には更新の必要があると思います。変体仮名に固執して漢字の更新が遅れては本末転倒なので,私は(1)案を理想としつつも(2)案に賛成しようと思います。
  • 以上,--spinda-kkmr 2017年5月7日(日) 10:58

上記,グループ-ノート:花園フォントよりコピーしました。コピーの際にインデントを1つ減らしました。--spinda-kkmr 2017年5月7日(日) 11:03

  • Ext.Fに合わせた花園明朝の更新を行いますが、正直なところ、少し時間がかかると思います。(2)→(3)→(1)の順で更新時点で間に合う範囲の収録でいかがでしょうか。--kamichi 2017年5月7日(日) 11:16

  • それでよいと思います。フライングとなりますが,(2)を実行するためのグループ:変体仮名Unicode-戸籍統一文字代替を作成しておきました。変体仮名作成が間に合わない場合は,このグループを花園明朝に引用すればよいと思います。--spinda-kkmr 2017年5月13日(土) 10:26

ユーザ名(ID)の変更について

今使っているIDを、ldx0からglizzyへ変えたいと思います。もしそれができない場合、新しいアカウントを作らないとならないのですか。--ldx0 2017年4月7日(金) 13:18
  • 遅いレスですみません。設計上、ID変更を想定していなかったので、どのような影響が発生するか不明です。新しいアカウントを作成していただく方法でお願いします。--kamichi 2017年5月7日(日) 11:16

JSON for Metadata

Can we have a JSON endpoint to query the character metadata? e.g. http://glyphwiki.org/json-meta?name=hkcs_m61b2
It should return each separate item as a key-value pair. --hkcs 20:07, 7 January 2017

  • こういう意味でしょうか?--kamichi 2017年1月9日(月) 18:21
 http://glyphwiki.org/json-meta?name=u2ff5-u20628-u21fee
 →{"出典":"孟孝琚碑"}

  • Yes. --hkcs 03:32, 11 January 2017


CNS 11643ソースのグリフのprefixについて

経緯を忘れてしまいましたが、CNS 11643ソースのprefixについて、現在「c#-####」と「t#-####」が混在していて、かつ「t#-####」はたまたま(?)tc,td,teの3つになっています。これは統一した方がいい気もします。「c#」の方はCHISE projectの記法で、「t#」はUCSの記法と認識していますが、どちらがいいでしょうか。グリフ量から言うと「c#」1774の方が多いです(「t#」252)。--kamichi 2016年12月18日(日) 11:49

  • 事情はともかくとして,私は“c#-####”に統一するほうがよいと思います。UCSと一致しませんが,補助漢字もUCSでは“J1-####”,グリフウィキでは“jsp-####”と異なっています。UCSと表現が異なるのはある程度やむを得ないと思います。グリフウィキ内で同一ソースの命名の統一がされていない方が問題が大きいと思います。--spinda-kkmr 2016年12月19日(月) 20:57

  • 全字庫には,明体,楷体,宋体のグリフがあり,明体と宋体を区別せずに接頭辞を一本化することは無理のように思います。また,「c#(#)-####」が何を参照するのかが不明確です。
  • 例えば,ce-3242は明体,te-3242は宋体であることが,全字庫 で確認できます。ところが,cc-3972は宋体です。この字を全字庫 で見ると,明体と宋体はUnicodeでは分離されるほどの違いがあります。 --ziyang 2016年12月20日(火) 23:10

    • ご指摘ありがとうございます。であるならば、いずれにしても「c#(#)-####」または「t#(#)-####」が何を示すかを定義して、かつ仮に全字庫が対象となるのであれば書体を区別して名前を付ける必要があるのだと理解しました。--kamichi 2016年12月24日(土) 20:15

  • The CNS11643 glyphs sometimes differ from that on the UCS code chart. Also, the CNS11643 currently regards the Songti form as the canonical one.
    My proposal:
    • c#(#)-s####: CNS11643 宋體
    • c#(#)-m####: CNS11643 明體
    • t#(#)-####: UCS T-source 宋體
    • ~ hkcs 20:12, 7 January 2017

    • ありがとうございます。以上の方針で他の方に異論ないようでしたら、変更しましょう。今までの「c#-####」が宋體なのか明體なのかは一つ一つチェックが必要でしょうか。--kamichi 2017年1月9日(月) 18:21


Vandalism

  • User ygyfontyw and smartisan are making counterfeit trademarked fonts with Glyphwiki again.
  • User seems to be illiterate in Japanese, Chinese or English
  • Suggested immediate IP banning on encounter of creating Group pages with these keywords:
    • 叶根友
    • 西瓜霜
    • XIGUASHUANG
    • 感冒片
  • Also recommend permanently suspend and removal of existing pages by accounts such as fz098, ygynonghei, to prevent their reuse.
  • \-- above hkcs 18:25, 5 December 2016

    • 賛成です。今大変忙しいので、近いうちに対応したいと思います。ちなみに当該SPAMユーザーのIPアドレスは、いつも中国大陸のISPからです。--kamichi 2016年12月5日(月) 23:53


Stroke Thinning

Is it possible to adjust the stroke thinning parameter? I used a manual overshoot at the glyph hkcs_m898b-02, top right stroke which also caused the bottom right stroke thin out. Is it possible to change the stroke thinning behavior, e.g. any glyphs inside グループ:NoStrokeThinning will not have the automatic thinning? hkcs 2016年6月22日(水) 00:05

  • 現在は、手動で調節する機能は用意していません。今、忙しくて改良は難しいです。あまりお勧めできませんが、hkcsさんの要求を満たす方法を紹介します。線種(1st parameter)を1(直線)ではなく101とすると、直線であっても、細くなりません。sandbox@2549 ただし、グリフエディタで101は認識されないので、一番最後に手でデータを書き換える方法になります。--kamichi 2016年6月23日(木) 23:21

    • Thank you very much! hkcs 01:34, 17 September 2016

  • Is it possible to enable stroke thinning for 6:22:5? This is to avoid too-thick strokes like in koseki-496700. --hkcs 2016年9月29日(木) 12:46

  • Also can we specify the amount of stroke thinning as an override, e.g. 10x always use the most thick, 20x thinner, 30x more thinner, 40x thinnest? hkcs 2016年9月29日(木) 12:54

Vandalism

Recently a lot of vandalism occurs. It is quite annoying when I need to use the correct glyph and find it is changed. I think it is better to require that user *must* supply a valid email instead of *optional*. Also suggest consider IP Address blocking. hkcs 2016年5月21日(土) 06:06

  • I think that a feature similar to Wikipedia's autopatrolling would be helpful: edits by new (unapproved) users and anonymous users must be reviewed and approved. (Also, a feature to automatically renew all glyphs if revisions are the same, like when vandalism is reverted.) umbreon126 2016年5月21日(土) 07:07

  • ご提案ありがとうございます。当該SPAMユーザーはかなり昔からの活動で、このユーザーだけに労力を使うのもナンセンスとは思いますが、優先順位を上げます。なお、IPアドレスブロッキングはすでに実施中です。当該SPAMユーザーのおかげで中国本土のアドレスが大量に登録済みです。--kamichi 2016年5月21日(土) 11:32

  • 一つシステム変更の提案をします。現在匿名利用者は「匿名利用者」という表示としていますが、少し後退して、IPアドレスをハッシュ化文字列したものを追記しようかと思います。イメージとしては「2ちゃんねる」などのそれと同じです。この意図は、時間の近い匿名投稿について、同一投稿者かどうかの判断の材料の提供です(完全なものではありませんが)。--kamichi 2016年5月26日(木) 10:19

  • なお、上記とは別に、SPAM投稿とみなした場合に、その対象グリフと同一投稿者による過去一定時間の投稿をすべてリバートする「自動rvv」ボタンを検討中です。濫用されると困るので、はじめは管理者のみの機能とします。--kamichi 2016年5月26日(木) 10:19
    • 【お願い】第一段階としてリバート作業を容易にするリンクページを表示する機能(admin向け)を作成しました。チェックのため、SPAM投稿のリバートについて、急ぐような内容でなければ、皆様方にはそのまま放置していただければ幸いです。--kamichi 2016年5月26日(木) 14:17
      • 新機能の有効性が確認できました。放置のお願いは撤回します。第二段階に作業を進めます。--kamichi 2016年5月26日(木) 22:00

      • Sorry I am using Google Translate for Japanese which gives me not very good translation. I want to confirm: for vandalism, unless the glyph necessary very soon, we should just leave the glyph there so admin may use auto revert? Thank you in advance! hkcs 2016年5月26日(木) 19:05

      • hkcsさんの書いた内容で正しいです。ただ、すでにチェックが終わりました。ですので撤回します。--kamichi 2016年5月26日(木) 22:00

ISO/IEC 10646:2014/Amd 2:2016

ISO/IEC 10646:2014/Amd 2:2016 が4月21日に発行されましたので,新規に符号化された字の作字が可能だと思います。文字コード表は現在,N4694 で見られます。 --ziyang 2016年4月27日(水) 23:45

  • ISOのFreely Available Standardsのページから,ダウンロード できるようになりました。 --ziyang 2016年5月21日(土) 19:57

グループ:IVDの編集について

グループ:IVDを編集するにあたって、私の一存では決めかねる事がありましたので、皆さんのご意見をお聴きしたく投稿いたします。既に決定事項がありましたらお手数ですがご教授願います。

  • 1.汎用電子コレクションの典拠グリフのリンクにあたって、グループ:IVD-20101114の「汎用電子文字のグリフウィキ変換について」に従って追加予定です。しかし、これらを全て追加するのか、それともX0208:1978固有+α(ft-####)や表外漢字不足(hg-####)などの現在登録が全くないものに関しては省くのか、どちらがよいでしょうか。私としては省かずに全てのリンクを登録した方がよいのではないかと考えています。

  • 2.汎用電子コレクションの中には典拠のコードの末尾に「S」か「SS」が付いたものがあります、漢字データベースさんによるとSが付いたものは改良版グリフだそうです。SSはわかりませんでした。これらにどのような違いがあるのか私の知識不足でわかりませんが、無視して元のグリフをリンクするのか、元とは別のグリフとして扱うのか、どちらがよいでしょうか。また、別のグリフとした場合にどのような命名をすればよいでしょうか。なお、グループ:IVD-20101114では元のグリフをリンクし、アスタリスクを付与してわかるようにしてあります。

また、グループ:IVDの私の編集等に関して、お気付きの点やご意見などがありましたらそちらもお聞かせ下さい。--wonderful-heaven 2016年4月26日(火) 01:14

  • 正しいグリフ名は,heisei-hgxxxx(表外漢字不足),heisei-iaxxxx(ISO/IEC 10646拡充対応1),heisei-ibxxxx(ISO/IEC 10646拡充対応2),heisei-ipxxxx(IPA向け漢字)となっています。現在作字されているのは合計で39字ですが,IVSと同じ字形なので,積極的には作字されていないと思います。
  • グリフ名には,「S」,「SS」はつけません。「S」,「SS」のついた平成明朝を参照して,それらがつかないグリフ名で作字することになります。 --ziyang 2016年4月28日(木) 22:49
  • 失礼しました。heisei-ftxxxx(X0208:1978固有+α)が抜けていました。これを含めて39字です。 --ziyang 2016年4月29日(金) 07:52

    • ご意見有難う御座います。そのように内容を修正致します。ところでグループ:prefixを見ると挙げて頂いたプレフィックス以外にも戸籍統一文字用のheisei-ksNNNNNNなんかも定義されていますね。グループ:IVDの汎用電子コレクションの典拠は全てheisei-をリンクして、heisei-ksNNNNNNなんかはエイリアスを登録していく方法も考えられますね。--wonderful-heaven 2016年4月29日(金) 14:18

    • 訂正します。グループ:prefixでの定義に基づき「S」「SS」はつけないと上に書きましたが,グループ:汎用電子ではつけているのに気づきました。矛盾を解消するには前者の定義の修正が必要なように思います。 --ziyang 2016年5月3日(火) 13:56

ご意見を元に再考した修正案を提示致します。

  • 1.汎用電子コレクションの典拠グリフは平成明朝グリフのプレフィックス「heisei-」を典拠元の文字集合に関わらず使用する。

  • 2.1の内容を受けて小文字でグリフ名に含める。

1については平成明朝グリフとその典拠元グリフに差がある登録が既にあるため。(例:heisei-tk01098690toki-01098690

2は1を受けて典拠元グリフではなく平成明朝グリフにリンクするため。また、グループ:汎用電子で付加されているため。

ご意見ありましたらお願い致します。--wonderful-heaven 2016年5月1日(日) 20:01

GlyphWikiの編集ショートカットキーについて

GlyphWikiを編集していると、いろいろとマウス操作でちょっと面倒がかかってしまいます。そのためにショートカットキーを必要とするようですが、自分もこれについてご存じておらず、こちらを利用していただいている皆様はマウスだけで編集をなさっているのかがちょっと気になります。これについてお返事いただければよろしいと思います。 --ldx0 2016年3月22日(火) 11:41

康煕字典グリフの命名規則の問題

現在GlyphWiki:prefixには以下のように書かれています。

kx-######康煕字典(同文書局影印本)字形。頭4桁はページ番号、下2桁はページ内番号

しかし、この命名規則だとページ内番号が100以上になる場合に対応できません。これに対して解決法が3つ考えられます。

  • (1) ページ内番号が100以上の場合、ページ内番号の十の位以上を一つの英字に置き換える。すなわち、01→02→…→97→98→99→a0→a1→…→a8→a9→b0→…といった形です。最大でz9=359番目まで表現できます。
    • 例:1591ページの104番目の場合、104の10をaに置き換え、ページ内番号を「a4」と表記する。結果としてグリフ名はkx-1591a4となる。(現在この規則を使っている康煕字典グリフはこれだけです)
    • 長所:既存のグリフの移動が必要無い。グリフ名で辞書順ソートした時に順番に並ぶ。
    • 短所:直感的に分かりづらい。

  • (2) ページ内番号が3桁の場合、kx-の後に7桁を続ける。すなわち、…→kx-####99→kx-####100→kx-####101→…
    • 例:1591ページの104番目の場合、グリフ名はkx-1591104となる。
    • 長所:既存のグリフの移動がほとんど必要無い(kx-1591a4だけ)。
    • 短所:グリフ名で辞書順ソートした時に順番がグチャグチャになる。

  • (3) 新しい命名規則に移行する。
    • 例A:kx-####-###(####はページ番号、###はページ内番号)。1591ページの104番目の場合、グリフ名はkx-1591-104となる。
    • 例B:kx-#######(上4桁はページ番号、下3桁はページ内番号)。1591ページの104番目の場合、グリフ名はkx-1591104となる。
    • 長所:直感的に分かりやすい。グリフ名で辞書順ソートした時に順番に並ぶ。
    • 短所:既存のグリフの移動が必要。

どれを採用するか、または他の方法など、皆様の意見をよろしくお願いします。

参考までに、康煕字典グリフは現時点でkx-1591a4を入れて1588個あるようです。―twe 2016年3月21日(月) 14:33

  • グリフ名は直感的にわかりやすいほうがよいので,(3)B“kx-ppppnnn”(pはページ番号,nはページ内番号)が望ましいと思います(ppppnnnとするのは中華字海グリフの命名“zihai-ppppnn”と合わせるため)。1500以上あるグリフを移動するのが大変そうですが,管理人のkamichiさんにお願いすればbotによるグリフの移動は機械的にできそうです。--spinda-kkmr 2016年3月21日(月) 14:52

  • この字は,CJK Ext.Dでの「K1591.a4」ですが,U+2B8CBに符号化されて「GKX-1591.104」になりました。漢字データベースプロジェクト(KDP)では,本来は「KX1591.104」になります(現在のデータは番号が間違っています)。中国が(1),IRGが(2),KDPが(3)に沿っていることになります。
  • IRGはもともと1ページ100字未満の本文を対象にして2桁の番号を採用したのでしょうが,100字以上のページがある補遺・備考も対象にするなら(3)案Bがすっきりすると思います。
    じつは「K1591.a4」はGlyphWikiで最初,「g-k1591-a4」として作字されていました。2桁の接尾辞が偏化変形部品コードと衝突する一方,GKソースは康煕字典ではないので,どこに移してよいのかわからず,いったんkxグリフに避難させました。Unicodeのグリフと原典の字体が違うと,これではうまくいかないので,結局,グループ:prefix-gでは「g-kx1591a4」に動かせるように(1)に沿って,定義しています。こちらの定義変更も考えられますが,この字形は「u2b8cb-g」に納まるので,緊急の課題ではないです。 --ziyang 2016年3月21日(月) 22:46

  • ご意見・経緯のご説明ありがとうございます。
  • まずg-kxグリフについて、調べてみたところ中国はIRGN1830への1回目のフィードバックで「G_K1591.104 rather than G_K1591.A4」とコメントし、上でいう(1)から(2)に変更(修正?)したようですし、定義変更をしてもよいと思います。が、いずれにせよ現時点でg-kxグリフは存在せず需要も少ないと思われるのですぐに決定する必要は無いと思います。
    次にkxグリフについて、お二人とも(3)案B kx-ppppnnn に賛成ということですが、命名規則の変更は多くのグリフのほかに他のプロジェクトにも影響する可能性がありますし、管理人のkamichiさんの意見もお聞きしたいと思っています。―twe 2016年3月28日(月) 16:11

  • 反応悪くて済みません。私は(1)案がすっきりすると思っていました。たしか別の集合でもこの方式を使っていませんでしたっけ?厳密には私は99の次からは16進数表記に切り替える方式(99,a0,a1,a2...a8,a9,aa,ab,ac,ad,ae,af,b0,...,ff)と勘違いしていました。
  • が、お二人の意見を聞いて(3)Bでいいのかな、と傾きました。そのあと、tweさんの「他プロジェクトへの影響」を聞いて、また少し戻った感じです。幸い(3)B案は新旧が命名上重なりませんので、(3)B案を採用し、しばらく旧命名はエイリアスで残す、というのはいかがでしょうか。--kamichi 2016年3月29日(火) 12:17

  • それで当面問題ないと思います。それと、99の次以降の最終桁が16進数かどうかは kx-1591a4 だけでは判断できないのですが、より合理的と思った方を選びました。―twe 2016年3月31日(木) 20:06

    • 大きな変更がない方が実態に合いそうなので,別方式として(2)と(3)の折衷案を提案します。「ページ内の漢字数が3桁の場合、そのページのページ内番号は3桁としてkx-の後に7桁を続ける。」
    • ページ内の漢字数が2桁の場合は,従来通り6桁です。(2)の長所を引き継ぎ,(2)の短所であるソートが乱れる問題はありません。加えて,現在のKGXソースで使われている番号と一致します(GKX-1595.80のみ一致しませんでした。訂正します)。いずれにせよ,(1)の支持がないので,kx-1591a4は白紙化になるでしょう。 --ziyang 2016年12月11日(日) 23:57
      • 反対です。この方式ですと該当ページに100字以上存在するかどうかをいちいち数えなければならないので,逆に厄介なことになりそうです。やはり(3)B案がよいと思います。管理人のkamichiさんにお願いすればbotによる新命名グリフの生成はできます。TRONコードの旧命名が残っているように,現状の“kx-ppppnn”グリフは新規作成停止で当面残しておけばよいと思います。--spinda-kkmr 2016年12月12日(月) 17:32
      • 参考までに,漢字データベースプロジェクト(https://github.com/cjkvi/cjkvi-dict にあるkx2ucs.txt)によれば,100以上の親字のあるページは本文にはなく,補遺と備考での以下の23ページになります。
      • 1570,1589,1590,1591,1592,1593,1595,1597,1598,1599,
        1605,1606,1608,1609,1610,1613,1617,1619,1620,1622,
        1624,1625,1628。
        1570が補遺で,後はすべて備考です。
        なお,私の提案では1595ページで現状のGKXソースと一致しなくなることを見落としていました。この利点がないと,あまり良い提案ではなかったようです。 --ziyang 2016年12月14日(水) 20:13
  • 少し説明不足のところがあったので補足説明します。「100字以上あるページだけ3桁にする方式」の問題点は,「康熙字典という同一の出典なのに表現方式が複数になってしまい,しかも機械的に判定する手段が無く,例えば上記の一覧のようなものをいちいち参照しなければならない」という点です。「該当ページに100字以上存在するかどうかをいちいち数えなければならない」というのはそれを言いたかったものです。台湾教育部異体字字典“twedu-######-###(-#)”のように元の出典で統一されていないものはやむを得ないとして,そうでないものは可能な限り1つの命名ルールで運用するほうがよいと考えます。私が(3)B案を支持するのはそのような理由からです。--spinda-kkmr 2016年12月16日(金) 17:53

    • 私も説明不足だったかと思いますが,(3)案に反対ではありません。(2)と(3)の得失の評価は人それぞれだと思いますので,IRGが採る(2)とKDPが採る(3)のどちらでも構いません。ただし,3月末に(3)で意見がまとまったように見えますが,移行作業が始まっていないので,現状のままだと結果的に(2)で進んでしまいます。そうなったときのソートの問題を解消する別案を出したのですが,早々に(3)に移行すれば,それでいいかと思います。 --ziyang 2016年12月18日(日) 00:16

    • すみません。「なるはや」で移行するということで(3)で行きましょう。異論がなければ年末かつ年内に作業したいと思います。--kamichi 2016年12月18日(日) 11:49
      • 現在登録されているグリフはすべて100未満の番号なので、"kx-nnnnNN"を"kx-nnnn0NN"にコピーし、"kx-nnnnNN"はエイリアスとして貼りなおす、という作業にします。"kx-nnnnNN"をルールから外せばデータ更新はできなくなるので、混乱は少ないかと思います。--kamichi 2016年12月18日(日) 12:14

    • ところで、ここで書くのは不適切かもしれませんが、3A案ではなく3B案である理由はなんだったでしょうか。前4桁と後ろ3桁は意味の異なる番号なのでハイフンで区切った方がいいのではないかと思うようになっています。3A案はグリフ名が現状より2文字多くなるので、グルーページでの列挙の際の文字制限に引っかかりやすくなるというデメリットはあります。従来、既存ソースの命名記法になるべく近づける方針でやってきましたが、そういったものがないものについて、意味が違うものを分離するかどうか、あまり考えてきませんでした。ご意見あればよろしくお願いします。--kamichi 2016年12月18日(日) 12:21

      • 私が(3)B案を支持したのは,康熙字典命名の現状での命名,および中華字海命名“zihai-nnnnNN”にハイフンが無いことから,一連番号の無い字書ではページ番号とページ内番号を連結したものを番号にする,という慣習ができているものと判断してのことです。私はハイフンが無い方が短い命名になりグリフページの制限に引っかかりにくくなるという利点に賛成できるので(3)B案を支持しますが,(3)A案支持者が多数派であればそれに従います。--spinda-kkmr 2016年12月19日(月) 20:27

  • なるほど、ではやはり3B案でグリフ名変更作業を実施したいと思います。--kamichi 2016年12月24日(土) 20:15

仮想K字形の適切な名称について

ただいま韓国式字形を作っております。それにしてもUnicodeのKSourceがない場合(中国のGかTだけ)、韓国式字形を「仮想K字形」に置きたいと思います。詳しくはこちら

それに加えて、spinda-kkmrさんから指摘 した通り、仮想K字形のことを新しく命名ガイドラインへ追加したいのです。--ldx0 2016年3月18日(金) 13:55

  • 他地域に伝播することを許容することになりますが、賛成です。Jに倣うと「-kv」でしょうか。--kamichi 2016年3月18日(金) 15:01

    • その通りです。「-kv」のようにすれば仮想字形に対する問題も避けられますし、中国などの字形についてもそれぞれ「-gv」「-hv」「-tv」「-vv」などが用いられます。 --ldx0 2016年3月18日(金) 16:18

      • 仮想K字形を“-kv”とすることに賛成です。とりあえず“-kv”だけを運用開始し,他の地域の仮想字形(“-gv”等)については利用したいという要望があったら改めて追加すればよいと思います。--spinda-kkmr 2016年3月18日(金) 18:29

      • 仮想K字形「-kv」の件、賛成です。ちなみに「-gv」「-tv」「-vv」についても、
      • 「-gv」→中華字海、「-tv」→教育部異体字字典(台湾教育)、「-vv」→會保存遺産喃 (VNPF外字)
        での出現も有りますので(部品利用レベル含む)、命名ガイドラインに追加して頂けるとありがたいです。--kamiyo 2016年3月18日(金) 22:48

      • ご意見通り、グループ:IRGSourceを作ってみました。ご興味のある方はどうぞ。--ldx0 2016年3月22日(火) 11:45

データベースの高速化について(旧見出し:バックエンドのデータベースのテーブル構造について)

最近ページ表示がさらに遅くなっている気がしたので、ページ生成のどこに時間がかかっているかを確認しました。大きな要素としては(A)「このグリフを内部で引用している他のグリフ一覧」および(B)「このグリフを収録するグループおよび引用するドキュメント一覧」でした。(A)はおよそ1.2秒、(B)は2.5秒ほど費やしています。(B)については対象をグループページに絞ると1.8秒ほどに短くなります。ただしこの情報はデフォルトで表示する内容ではないとも考えましたので、デフォルトは非表示とし、リンクを開いたときに表示するように変更しました。(A)については現状では改善する方策が見出せません。おそらく1年ほど前に書いた下記の記述のとおり、大きな変更が必要なのではないかと考えます。ひとまず現状を記します。--kamichi 2016年2月27日(土) 17:59

  • 現在のグリフウィキではwikiのページを種別(グリフとドキュメント)関係なく1テーブルで扱っています。グリフ(KAGEデータ)は最大1000字、ドキュメントは最大10万字です。これがデータベースに非効率をもたらし、スピードが遅いのかと考えています。
  • そこで思い切ってグリフとドキュメントをテーブル上分割しようと考えていますが、そのコストとメリットどちらが大きいのか不明のため躊躇しています。もしDB設計等詳しいかがいらっしゃったらアドバイスをお願いします。
  • まずは別サーバを立ててテストしてみようと思っています。--kamichi 2014年10月26日(日) 12:30

  • When font generation is in progress, viewing the Revision history is very slow. (Maybe take over 15 seconds). Maybe the database queries can be more optimized? I can have a look at the source code if the latest vers of the engine is on github. hkcs 17:03, 28 February 2016

Server Errors

These days often have (suspected Chinese) anonymous user that create font pages with names of copyrighted fonts and include lots of glyph. Also, the server keep returning "500 Server Error" when pressing "Edit" or "Submit Glyph", and "504 Gateway Time-out" when pressing "History" of the group page. chanhenryfaihang 2016年1月18日(月) 02:43

  • いたずらによるサーバへの高負荷が原因でした。サービスを一旦止めて復帰させました。匿名利用者の1000グリフを越えるフォント生成に制限を設けることを検討しています。--kamichi 2016年1月18日(月) 13:32

  • Agree limit to 1000 glyphs per execution if execution carried out by anonymous user. Or can also limit anonymous user from creating group pages. chanhenryfaihang 2016年1月18日(月) 17:52

  • 一般グループページは登録ユーザー・匿名ユーザーにかかわらず1000グリフまでという制限を付けました。占有グループページには制限がありません。--kamichi 2016年1月29日(金) 22:41

中国語とGlyphWikiのインタフェース

最近は中国語が母語のユーザーの数が増えていますが、GlyphWikiは中国語の翻訳がありません。この問題を対処しなければなりませんと思います。umbreon126 2015年12月23日(水) 19:24
  • すみません、実はすでに翻訳データを有志の方からいただいているのですが、反映できていません。この1,2ヶ月中にハングルも合わせて運用を始めたいと考えています。--kamichi 2015年12月23日(水) 20:04

  • ということで開始しました。--kamichi 2016年1月29日(金) 22:41

Batch localed variant creation?

I have created u5782-g and u5782-g02 which are different from u5782 and u5782-02. However there are already tens of entries created with u5782-02. i wonder if there is a batch function to duplicate and create uxxxx-g from all uxxxx who referenced u5782-02 with each replaced by u5782-g02, without affecting uxxxx themselves (which should be J standard)? or do i have to create them manually one by one?

Sorry for writing in English. farter 2015年8月26日(水) 23:33

  • これは自動的にはできないと考えます。ダンプしたデータを利用して半自動登録するリンクを作成するか、管理者(私)に内容と意図を説明して代理で実行を依頼するかのどちらかだと思います。ただ問題は、生成するuxxxx-gが単にu5782-02u5782-g02への置き換えだけでなく、別の部品もgデザインに変えなければいけない場合には、手修正が必要、ということです。このチェックはfarterさんにお願いしてもいいですか?それなら私が代理でやってもいいです。--kamichi 2015年12月23日(水) 20:04

    • i think the difference is small enough, direct replacement will just work perfect. in fact it's just "batch creation" instead of changing the original ones, similarly, the feature of having all coordinates slightly moved (as in current batch replace/update) is capable of solving most cases.

    • Seems i've misunderstood something. About other parts which may be not -g, yes, some of them need manual work; but without batch creation, they all need manual work... Always, finally a small part left will need manual adjustment. Let's do that together. Batch functions are just intended to save time of repeated work, not necessarily all (in fact not that possible).farter 2016年1月18日(月) 23:18

    • I have a script which can batch generate the glyph source by substitution, however it is not available online and need to press submit for every additional glyph... If there are any batch items I can create for you. For the u5782-g02, I have ported them already. hkcs 02:40, 19 January 2016

SAWN外字について

sawnグリフはグループ:SAWN外字で規定されているように電子方塊壮字 からダウンロードできるフォント(sawndip.ttf)を参照しています。このフォントを提供する 方块壮字资料库 では新しいフォント(HuanZhuangziSong.otf)がダウンロード できます。
この2つで異同があるようです。sawn-f63be@1は(当然)古いフォントの字形,sawn-uf63be@4は新しいフォントの字形で作字されています。後者の命名は規則上,不正なのですが,白紙化する前にGlyphWikiとしてどちらのフォントで作字を目指すかを考えないといけないと思います。他に,sawn-f3793@1は新しいフォントを参照して作字され,古いフォントにない理由で白紙化sawn-f3793@3されていたりします。また,グループ:SawndipSawdenjは新しいフォントを参照しているように見受けられ,グループ:古壮字一覧グループ:SAWN外字等と齟齬が生じます。
対策はいくつか考えられると思いますが,たたき台として,収録字数の多い新しいフォントは無視できないので,sawnは新しいフォントを参照するように変更して,古いフォントの字体が違う場合には古い字形には"var-001"をつけるか,CDP外字方式でsawnoの接頭辞を与えるかして残すことが考えられます。 --ziyang 2015年7月12日(日) 15:35

  • 私は、古い字形(Sawndip.ttf)は「sawno-f####」、新しい字形(HuanZhuangziSong.otf)は「sawn-f####」とグリフの二本立てに賛成です。古いフォントはGソース風の字形を基礎に作成されており、新しいフォントは多分GlyphWikiのグループ:Sawndipの字形そのままのようですので、CDP外字同様、グリフ名称を分ける事が良いかと思います。---kamiyo 2015年7月12日(日) 22:15

  • HuanZhuangziSong.otfのグリフがGlyphWiki製だとすると,元の場所の真正のデータを,良かれと思って消していたことになるわけですね。真正のデータを適当な接頭辞のもとで復元するのが良いのではないかと思います。上の私のたたき台はHuanZhuangzi.otfを参照して作字する作業を念頭に置いていましたが,グループ:Sawndip以下のデータを復元する作業として考えないといけません。すると,そちらを新しい接頭辞に収容した方が手間は少ないかもしれません。 --ziyang 2015年7月12日(日) 23:13

    • 作業手順を少し考えました。グループ:Sawndipにつながるページのなかにある情報をもとに,新しいグリフを作成することになると思います。例えば uf3420(u2ff0-u5973-u4e70) なら,u2ff0-u5973-u4e70が白紙ですから,更新履歴から適当な字形を探して,U+F3420の位置に新しいグリフを作ります。命名のことだけ考えれば新フォントsawn,旧フォントsawnoが良いかと思いますが,手作業で進行すると,新フォント(HuanZhuangziSong.otf)に更新したのか,旧フォント(Sawndip.ttf)のままなのかがわかりにくくなり,間違いの種になります。何か工夫しないと,sawn-sawnoの命名組み合わせは難しく,新フォントには新しいグリフ名が必要になるかと思います。 --ziyang 2015年7月13日(月) 23:07

    • 新フォントの符号位置とGlyphWikiのグリフ名の対応表があれば,新フォントsawn,旧フォントsawnoの実現を比較的スムーズにできる手順を思いつきました。新フォントのグリフは,(1)同じ符号位置の旧フォント(現在のsawnグリフ)を使うものと,(2)そうでないものに分類できます。この情報を用いて,すでに作字されているsawnグリフは,(1)新フォントと同じ字形のもの,(2)新フォントでは違う字形のもの,に分類できます。後者のリストを作って,これをsawnoに写し,sawnを白紙化する処理をbotにしてもらえれば,後は,白紙化・未作成のグリフの作字作業になります。vunzndiさんかkamiyoさんがそのような対応表をお持ちだったら話は早いのですが,新しく作成した場合でも全体の手間はこちらが少なくなるような気がします。 --ziyang 2015年7月14日(火) 20:34

    • 利用者:tweさん,SAWNデータ(グループ:twe_サンドボックス2@55)お見事です。感服いたしました。sawnoの作成だけでなく,新しいsawn作成のbot処理も可能にするデータになると思います。bot処理についてご意見,ご提案もありましたら,よろしくお願いいたします。 --ziyang 2015年7月17日(金) 08:21

    • 皆さんに使っていただけるような作業用ページその1(グループ:Working-SawnNewBuild-01)その2(グループ:Working-SawnNewBuild-02)を用意しました。後は,sawnグリフは新フォントを指すと宣言すれば,移行作業に入れるかと思います。私一人で宣言するのは気が引けますので,どなたか賛同者がいて異論がなければ,移行することでいかがでしょうか。また,私が手作業とした部分の自動化のアイデアがありましたら歓迎します。 --ziyang 2015年7月18日(土) 12:20

      • 拡張Eグリフとの対応を追加したデータをグループ:twe_SAWNデータに投稿しました。【06】 指示が白紙化されている文字(317字)のうちの一部の検討に役立つと思います。(というか、Note欄に書き込んだほうがいいのでしょうか)―twe 2015年7月19日(日) 01:05

      • ありがとうございます。追加情報(グループ:twe_サンドボックス2@57)をざっと見たところ,(1)Sawndipグループにないグリフの由来,と(2)白紙化されたIVSに代わる拡張Eのコード,がわかるようですね。(1)は作業範囲外としていましたので,いま組み立ててた作業には影響しません。後で追加作業とすることが考えられます。(2)は拡張Eのグリフを使用していることに確証がもてれば手作業(【06】指示が白紙化されている文字)から機械処理(【08】単独の指示がある文字)に移すことが考えられますが,おそらく確証にはならないでしょう。すると,白紙化されたグリフの方を確認する手間は必要であり,個別検討のままではないでしょうか。その場合でも拡張Eの情報がNoteに入っていれば,関連字をつける助けになりますので,書き込んでいただけませんでしょうか。Note欄は,複数の人間が手作業に関わる場合の連絡用として使う(例えば,作業済なら「済」と入れる)ことを想定していました。 --ziyang 2015年7月19日(日) 09:26

      • 分かりました。ということでNote欄に情報を入れてみました。―twe 2015年7月19日(日) 11:39

    • kamichi様,かような次第ですので,かなり量がありますが,sawnグリフ作成の機械処理をお願いしたく存じます。工程とデータの詳細は,グループ-ノート:Working-SawnNewBuildに書きます。 --ziyang 2015年7月19日(日) 21:23

合成用(non-spacing)グリフについて

GlyphWikiで作られたフォントで合成ができるかどうかをチェックするため、グループ:johotogoshinentai_サンドボックス@16でフォントを生成し、「q̉」、「鿌⃝」をMS Wordなどで入力し、そのグループで生成されたフォントを適用してみました。合成には問題がありませんでした。

現在、GlyphWikiには、u20ddu20deu3099u309aのように、いくつかの合成用グリフが作成されています。これらが現状ではspacingグリフとして実装されますが、合成用文字が合成できないのは望ましくないと思われます。ということで、このようなグリフをグループ:NonSpacingGlyphsに集めました。そのグループに記述されているグリフの幅を0にセットするように変更するのが良いと思います。 --johotogoshinentai 2013年3月31日(日) 19:10

  • グリフの幅を0にするだけでは(前ではなく)後の文字に重なってしまいそうなんですが、その辺はどうなんでしょう。 --hanubeki 2013年4月1日(月) 16:21
    • グループ:johotogoshinentai_サンドボックス@16の合字用グリフでは0:0:200:200より左側の範囲に配置されているようですね。しかし、これではGlyphWiki上での表示が真っ白になってしまいます。 --hanubeki 2013年4月1日(月) 16:27
      • その問題には、2つの対策があります。一般のグリフは横の始点が0、終点が200だとしたら、
      • 1) 合成用グリフは始点も終点も0にする:u0020-u####やu3000-u####に0:0:200:200内のグリフを作成します。そして、u####にはu0020-u####やu3000-u####を引用し、それを左に100pxや200pxシフトします。こうするとu####は真っ白でも、u0020-u####やu3000-u####を見ると元のグリフを見ることができます。
      • 2) 合成用グリフは始点も終点も200にする:こうするとu####が真っ白にならないので、u0020-u####やu3000-u####を作成する必要がありません。ただし、半角文字の上に重なる合成用グリフは右寄せにする必要があります。 --johotogoshinentai 2013年4月1日(月) 16:52
      • 3) 2+グループ:HalfwidthGlyphsグループ:NonSpacingGlyphsの両方に定義されているグリフは始点も終点も100にする、というのも考えてみましたが、処理が複雑になりそうですね。 --hanubeki 2013年4月1日(月) 17:54
  • HalfwidthGlyphsとNonSpacingGlyphsの両方に定義されているグリフは存在しないので、それは実現できないと思います。半角でありながら合成用であるグリフは存在できません。 --johotogoshinentai 2013年4月1日(月) 17:57

ちょっと考えてみて、まとめてみました。始点・終点の位置により、次のようになります。

符号位置始点も終点も0始点も終点も100始点も終点も200
̀(u0300) sandbox@1756u0060sandbox@1754
͡(u0361) sandbox@1757u2040sandbox@1755
⃞(u20de) sandbox@1758sandbox@1759square

始点も終点も100のほうがほかの場合よりはマシだと思われますが、いかがでしょうか。 --johotogoshinentai 2014年1月22日(水) 19:42

  • u0300は前の文字が半角となる状況を想定したデザインのようですが、u20deは前の文字が全角となる状況を想定しています。
  • u0300のように半角文字に重なるデザインのグリフをグループ:HalfwidthGlyphsグループ:NonSpacingGlyphsの両方に定義し、そのようなグリフは始点も終点も100にして、
  • 対してu20deのように全角文字に重なるデザインのグリフをグループ:NonSpacingGlyphsだけに定義し、そのようなグリフは始点も終点も200にすれば(つまりhanubekiさんの意見と同じになります)、
  • u0300u20deはそれぞれu0060squareのエイリアスにするだけでよく、新たに100ずらしたグリフを作成せずに済みます。
    • ただし、半角文字の合成用グリフか全角文字の合成用グリフかの区別にグループ:HalfwidthGlyphsを使うのは混乱を招きかねないので、新しいグループを作って区別してもよいと思います。
  • そうはいっても、現状グループ:NonSpacingGlyphsに定義されているグリフはほとんどが半角文字の合成用グリフなので、始点・終点を100に統一し、全角用の一部のグリフがsandbox@1759のようになるだけ(johotogoshinentaiさんの意見)でも十分かもしれません。―twe 2014年1月22日(水) 23:46

反転グリフも作れるようになりましたし、合成グリフも作れるようにするのもどうでしょうか?グループ:HalfwidthGlyphsに属しているグリフは始点0、終点100に設定されているように、グループ:NonSpacingGlyphs-Halfwidthに属しているグリフは始点も終点も100、グループ:NonSpacingGlyphs-Fullwidthに属しているグリフは始点も終点も200にすれば良いでしょう。 --johotogoshinentai 2014年10月14日(火) 10:31

  • 私も合成用グリフの早期実現に賛成です。多くのフォントにて実装されているので,花園明朝も対応するほうがよいと思います。--spinda-kkmr 2014年11月1日(土) 12:10

  • 合成用グリフと合成済みグリフと頭の中でごっちゃになっています。合成用グリフの方はspacingなど(?)のメタ情報をいじるだけでできるという理解でいいでしょうか。--kamichi 2014年11月1日(土) 12:58

    • あるグリフにメタ情報が入っているかどうかをチェックするためにはグリフをいちいちチェックするしかありませんが、合成用グリフもHalfwidthGlyphsのようにグループで管理すると、どのグリフがグループに入っていてどのグリフが抜けているかをチェックするのが便利です。というわけで、私は合成用グリフもHalfwidthGlyphsのようにグループで管理するほうが良いと思います。 --johotogoshinentai 2014年11月1日(土) 13:14

    • たぶんkamichiさんのご質問は,「グループ:NonSpacingGlyphs-Halfwidthに属しているグリフは始点も終点も100、グループ:NonSpacingGlyphs-Fullwidthに属しているグリフは始点も終点も200にする」を実装するだけでOKか? という趣旨のように思えます。ここでの議論に参加されている皆さんはそれでOKと認識されているようです。JIS X 0213,住民基本台帳ネットワーク統一文字,Adobe Latin Extendedの全文字作成を実現させる意義深い実装ですので,ぜひよろしくお願いいたします。--ziyang 2014年11月1日(土) 22:17

    • ziyangさんありがとうございます。まさにおっしゃる通りの意味でした。ですが、まだよく理解できていないかもしれません。合成用グリフを用意するならばおそらくhmtxテーブルを操作するものと思います。合成済みグリフを用意するならばおそらくgposテーブルを用意するものと思います。どっちでしょうか?hmtxテーブルをいじってみたのですがosxとwindowsでずれ方が違うので合わせて混乱しています。--kamichi 2014年11月2日(日) 14:09

      • 合成用グリフはHalfwidthGlyphsのように始点と終点を調整するだけで済むと思います。合成済みグリフの準備・実装は(複雑になる可能性が高いと思うので)見合わせましょう。つまり、とりあえず「「グループ:NonSpacingGlyphs-Halfwidthに属しているグリフは始点も終点も100、グループ:NonSpacingGlyphs-Fullwidthに属しているグリフは始点も終点も200にする」を実装するだけでOK」です(私は合成済みグリフの準備・実装については考えていませんでした)。 --johotogoshinentai 2014年11月2日(日) 14:34

      • 合成用グリフの経験がないので,頭の中でadvanceWidthを0にしてOKと思っていました。OS XとWindowsでずれ方は違うのは,何か深い闇があるのでしょうか。私の手に余るので,より詳しい方のご意見があれば有難いです。--ziyang 2014年11月2日(日) 15:22

      • グループ:JISX0213合成文字のうち˩˥u02e9-u02e5と˥˩u02e5-u02e9は単に˩u02e9と˥u02e5を重ねるだけでは表現できません。JIS X 0213を全て収録するには,少なくともこの2文字だけは合成済みグリフとして搭載する必要があります。ちなみに,u02e5u02e9の文字は単独でも機能し,2つ以上を並べれば合成文字としても機能する,厄介な文字です。--spinda-kkmr 2014年11月2日(日) 15:33

      • 合成済みグリフの実装は合成用グリフの実装より難しいようなので、とりあえず合成用グリフだけを実装しましょう、と言ったのです。合成用グリフは始点と終点を調整するだけで済むと思いますが、合成済みグリフの実装はそれより複雑な処理が必要なようなので。 --johotogoshinentai 2014年11月2日(日) 19:19

      • u02e9-u02e5u02e5-u02e9を実装するには,Adobe-Japan1のようにGSUBのグリフ置換 で行くのでしょうか(まだhmtxの問題が決着してないようで,Nonspacingではない話題は本来は分けた方がいいところですが)。--ziyang 2014年11月3日(月) 22:32

      • 合成用グリフについてですが、(とりあえず横書きについては)グリフを原点より左側に配置する必要があります(つまり、グループ:NonSpacingGlyphs-Halfwidthのグリフは512、グループ:NonSpacingGlyphs-Fullwidthのグリフは1024だけ左に平行移動する必要があります)。それから送り幅を0にすればよいと思います。―twe 2014年11月8日(土) 15:25

    • とりあえず重ね打ちによる合成だけでも早期に対応してほしいです。そうすればグループ:JISX0213合成文字の25文字のうち23文字は表現可能になります。
    • この議論は井戸端にコピーしてよいでしょうか? これはグリフウィキ全体に関することなので,利用者全員の目に届きやすいところにあるほうがよいと思います。
    • 以上,--spinda-kkmr 2015年5月23日(土) 12:48

上記,利用者-会話:kamichiよりコピーしました。--spinda-kkmr 2015年6月4日(木) 18:32

合成用グリフの実装は、(普通のグリフの始点が0、終点が200なら)

  • グループ:NonSpacingGlyphs-Halfwidthにあるものは始点も100、終点も100
  • グループ:NonSpacingGlyphs-Fullwidthにあるものは始点も200、終点も200
  • で十分だと思います。これは、グループ:HalfwidthGlyphsにあるグリフが始点が0、終点が100に設定されるのと同じ原理です。半角グリフの実装と同じ原理なのに、なぜ合成用グリフの実装はまだ実現されていないのか、それがよくわかりません(もし、すべてのグリフの始点が0で固定されており変更できないなら別の問題になりますが)。花園明朝の新しいバージョンが公開される前に、合成用グリフの実装も実現されたらいいな、と思います。 --johotogoshinentai 2016年1月2日(土) 19:09
  • (上記の私の叙述は、u0300u20deのような、直前の文字と合成されるグリフのみに適用される話で、 ˩˥(u02e9-u02e5) ˥˩(u02e5-u02e9) のような、まったく別のグリフになるものとは関係ありません。) --johotogoshinentai 2016年1月2日(土) 19:22

もし始点を0以外にするのが不可能であれば、半角グリフのように終点だけを変える方法で決定してください。つまり、グループ:NonSpacingGlyphsにあるグリフはすべて始点も終点も0で実装されるようにしてください。(GlyphWiki上では真っ白に見えますが、それは仕方ありません。) --johotogoshinentai 2016年6月28日(火) 09:16

Gitリポジトリ

ここに書くべきかどうか迷いましたが一応。 最近KAGEエンジンが更新(中台字形用の左下・右下の追加、ストレッチの実装など)されましたが、Gitリポジトリ が未だ更新されていません。最新のソースはどこにあるのでしょうか。--mihail-jp 2015年5月31日(日) 19:37

  • 申し訳ございません。開発頻度が低くなり、バージョン管理システムの操作に疎くなったため、更新できなくなってしまいました。バージョン管理よりも公開のほうが重要と考えますので、Dropboxの公開フォルダ機能を利用しての公開に切り替えたいと考えています。暫定的にGlyphWiki:高度な活用方法にリンクを置きましたのでご活用願います。--kamichi 2016年1月4日(月) 23:07

IDSエディタ

不具合が起こりました。「⿱𦥒开」を変換したら「u2ff1-ud85a-udd52-u5f00」になりました。(BMP外の文字がHigh Surrogatesに分解されます)。最近のFirefox 38やOpera 12.17(Prestoエンジン)ではこの状態です。umbreon126 2015年5月27日(水) 11:00
  • ご指摘ありがとうございました。サロゲートペアに未対応でした。改良しました。--kamichi 2015年8月30日(日) 21:38

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


古代文字の字形の基準について

最近,Unicode第1面の古代文字が多く登録されていますが,各利用者ごとの字形の解釈の差のため,Unicode規格票と離れた字形のグリフが登録されていることがあります。
そこで,解釈のばらつきを回避するために,以下の基準を提案いたします。

1.古代文字は,原則としてUnicode規格票に倣った字形とする。
2.ただし,ある文字グループについて,別の基準(典拠がはっきりしており,かつ,Unicodeコード位置と明確に対応できるものに限る)に従って作成することについて複数(3名以上)の利用者が合意した場合は,それに従う。

上記のとおりです。意見をお願いいたします。--spinda-kkmr 2015年5月23日(土) 12:36

  • 自分が現在作っている古ペルム文字のように、規格表が非常にガタガタで判別が難しい場合には、2の案を適用させるべきだと思います。地域差、書き癖により、明らかに別の字と捉えられるもの(ロシア、ブルガリア、セルビアのキリル文字の差とか)に関しては-var-bgのように区分したらいいのではないかと思います。

データのライセンスについて

クリエイティブ・コモンズのCC0が発表されました。これをグリフウィキのグリフデータおよびドキュメントデータに適用(ライセンスの変更)することはいかがでしょうか。いままでグリフウィキのデータに関するライセンスの問い合わせを受けたことは無かったと思いますが、より明確になるかと思います。デメリットがあるかどうか、現時点で思いつきません。--kamichi 2015年5月8日(金) 08:09

  • 賛成です。今までのライセンスと実質的にできることが変わるわけではないので、独自ライセンスより望ましいと思います。--emk 2015年9月1日(火) 21:45

接尾コードの追加について

「宀」「冖」などの字形を用いたグリフを作成する際、現在接尾コード「-04」の字形では横棒が長過ぎで、「-14」の字形では横棒が短すぎるので、「-04-var-###」にて「宀」「冖」に対応する偏化変形グリフの作成を行っております。
ですので、「-04-var-###」が乱立して見にくくなる可能性があるため、「-14」が三角屋根形状用偏化変形グリフであるように、例えば「-24」を宀冖冠用の偏化変形グリフの接尾コードと定めるのは如何でしょうか。
ご検討のほど、よろしくお願いします。 --kamiyo 2015年4月13日(月) 22:46

  • 賛成です。現状ではシステム上は特に変更点はなく、取り決め上、新しい番号が増える、ということになると思います。--kamichi 2015年4月18日(土) 23:45
  • 私も賛成です。番号は“-24”でよいと思います。名称は「上下結合の下,上中下結合の下で,-04と-14の中間程度の形状のもの」でどうでしょうか。--spinda-kkmr 2015年7月18日(土) 09:58

返信が大変遅くなりました。ご意見ありがとうございます。
名称の件、私も賛成です。以下にGlyphWiki:グリフを登録するの「既存グリフの偏化変形部品とする」の表の一部(「-24」)を作成致しました。

接尾コード意味
-24上下結合の下,上中下結合の下で,-04と-14の中間程度の形状のもの
    • kamiyo 2016年2月7日(日) 15:02

データ損失(GlyphWiki:お知らせ)に関係すると思われる動作不備

画像が表示されないようです。 編集中のプレビューでも表示されませんでした。 u6534-09 --pyrite 2015年3月22日(日) 18:54

  • 大変失礼しました。復旧しました。--kamichi 2015年3月22日(日) 19:38

匿名利用者の若干の非匿名化について(2015/01/07:一番上に移動)

以前、匿名利用者はアクセス元IPアドレスを表示していましたが、これをやめて「匿名利用者」以上の情報を出さないようにしました。これに関して、スパム投稿の前後の匿名利用者の投稿が真面目なものかそうでないものかの判断が難しく(管理者以外の一般ユーザーは)混乱すると思います。そこで、そのIPアドレスが昨日までに投稿の実績があるか/ないかで、新規匿名利用者、ベテラン匿名利用者と、2つに分別して表示するようにするのはどうか(新規はスパム率が高いのでより注意して投稿を見守るという目安になる)と思いますが、いかがでしょうか。なお、これはポリシーの大きな変更なので強い賛同がない場合は実施しません。また「GlyphWiki:」ページは匿名利用者は投稿できませんのでそのことも踏まえて結論をつけたいと思います。ご意見よろしくお願いします。--kamichi 2012年5月15日(火) 20:31

  • 賛成です。新規匿名利用者については,“-var”,“-itaiji-”による異体字の作成に制限を設け,根拠を示しておらず,他の利用者も根拠を確認できない場合は,信頼性が無いと判断して白紙化する,というのはどうでしょうか。匿名利用者による異体字は,信頼性が低いと考えます。--spinda-kkmr 2012年5月19日(土) 11:47

  • これは別のものかもしれませんが、UCSグリフを匿名利用者が編集できないように制限するのはいかがでしょうか。UCSグリフは引用度が高く、荒らされると大変不便になります。 --johotogoshinentai 2012年5月21日(月) 09:41
    • 今朝は匿名利用者によってu9759u975c-ue0102のエイリアスになってしまって、u9759をエイリアス先としていたエイリアスグリフは全部u975c-ue0102のエイリアスになってしまいました。(今は私がすべて直しておきました。) このような場合ではエイリアス関係も複雑になってしまいます。UCSグリフを匿名利用者が編集できないように制限する必要があると思います。 --johotogoshinentai 2012年5月23日(水) 11:49

    • 難しいですね。2つコメントがあります。(1)あまり複雑な制限のかけ方は混乱すると思うので、わかりやすい制限を。(2)匿名者への制限はカジュアルないたずらには対応可能だが、本気を出されたら登録ユーザーに移って同じことをされるだけなので、根本的な解決にはならないかもしれないこと。現実に長期にわたっての匿名スパムユーザーが実在しています。

  • 匿名の人はsandboxおよびguest-001~100の編集のみに閉じるという制限も検討の1つかと思います。既存データへの編集協力はユーザーになってもらい、一方でちょっとグリフが必要というニーズにも対応できるかと思います。あとは、ユーザー認証をするけれどもユーザー名を出さないで編集する、という半匿名という概念があっても良いのかもしれません。--kamichi 2012年5月24日(木) 08:04

  • 悩ましいところですが、匿名利用者が投稿した場合は、強制(自動)的にsandboxに登録する、というのも1つのやり方かと思います。要旨に真っ当な記述があれば登録ユーザーが適切な命名にコピーする、というものです。--kamichi 2013年2月18日(月) 08:35
    • 賛成です。やや厳しいですが,やむを得ないと思います。--spinda-kkmr 2013年2月22日(金) 20:23
    • 正直あまりやりたくない(登録者spamユーザーが増える可能性が高い)のですが、匿名利用者の投稿は全てsandboxGlyphWiki:サンドボックスに登録する方向で検討しています。--kamichi 2013年3月2日(土) 14:32

  • 本日(2015/01/07)朝,かなり大規模な荒らしが発生しました。匿名利用者への制限を厳しくするほうがよいと考えます。
    • (1)グループページの新規作成は1日3ページまで,編集は(新規作成と合わせて)1日10ページまで
    • (2)グリフの新規作成は1日30グリフまで,編集は(新規作成と合わせて)1日100グリフまで
  • やや厳しいですが,この程度の規制は行わないと荒らしは無くならないと思います。
  • あるいは,上記のkamichiさんの提案通り,sandbox以外の登録は匿名利用者には認めないというのも方法としてはあると思いますが,そうすると「少しだけ」グリフウィキを利用したい人までいちいちアカウントを取らなければならなくなるので,利便性がやや損なわれてしまうと思います。
  • 以上,--spinda-kkmr 2015年1月7日(水) 18:29

  • 本件、そろそろ結論を出してもいいとは思っているのですが、その前提として、実態がどうなっているかをみなさんに把握してもらった上でないと無意味と思います。というのはすでにいくつかの予防策により日々投稿されるスパムデータは9割がた(直感)弾いているからです。かといって、スパマー相手に手の内を見せたくはないと考えます。それも踏まえてちょっと情報を整理して提示しますのでお待ちください。でもあくまで感覚的なものですが、スパマーは3、4名程度に限られていると思います。現状で、それほど悪質とは思っていません。すぐ復旧できる仕組みの新設で乗り切れるほうがいいかなとも思います。--kamichi 2015年1月7日(水) 23:50

  • 議論を抜かす形になり恐縮ですが、当座の対処として、グループページのみ匿名希望者に対してはグループ:sandboxのみ編集可とする方向で考えます。なお、他言語対応をふまえ、種別が違うことを明示する意味でカタカナを使っていたGlyphWiki:サンドボックスからサンドボックスページとしての位置付けを移行します。以上の対応を検討中です。--kamichi 2015年1月8日(木) 08:49

CJK互換漢字Standardized Variantについて

グループ:互換漢字IVD(グループ名が変ですが)が花園明朝に含まれていないのは意図的なものですか? 文字情報基盤は一部の異体字をCJK互換漢字Standardized Variantで表すことを前提にしていて、IPAmj明朝にも実装されているので、採用を検討していただきたいです。--emk 2015年1月2日(金) 16:23

  • 理由はなく入れ忘れていました。入れるべきと考えます。--kamichi 2015年1月2日(金) 17:03
  • 「互換漢字IVD」の名称は不正確な上,グループ:IVD互換漢字(こちらは正当なグループ名)と紛らわしいのが,気になっていました。この際,内容をグループ:互換漢字SVSに移動します。--ziyang 2015年1月2日(金) 20:19

香港標準字形のための接頭辞

香港が香港の標準字形をIVDに登録する準備をしています。 http://www.iso10646hk.net/ivd/1/ この香港標準字形コレクションのグリフをhka-####で作成してもよろしいでしょうか?
  • 新参者の私が言うのも何ですが,常識的な提案であれば,命名規則を定義してグリフを作成し始めても構わないようです。グリフを定義するグループ:prefix-hkaを作ってみました。 --ziyang 2014年12月28日(日) 18:23
  • 韓国ソースの“ka-kc#####”もガイドラインにはありませんが登録されているので,典拠がはっきりしていれば大丈夫だと思います。--spinda-kkmr 2014年12月28日(日) 19:00

「非」明朝体漢字の登録制限について

グリフウィキはもともと明朝体漢字のデータベースを想定していましたが、多分にそれ以外の漢字が登録されています。個人占有グリフに登録する分には何とも思いませんが、一般グリフにどんどん異体字扱いで増えていくのはどうかと思います。次のような縛りを考えています。

  • 明朝体が見出し字となっている辞書に、非明朝体だが見出し字として掲載されている字形はOKとする
  • 翻刻された非明朝体字形の明朝体化字形は論文などとして公開されているもの(自分でこれから公開するなどを含む)
  • 他の公的な明朝体文字集合に含まれるもの

以上ご意見をお願いします。--kamichi 2014年12月3日(水) 15:20

  • 草書の明朝体化字形が“-itaiji-”を用いて登録されているのには私も違和感があります。上記の条件を満たせば可,それ以外は不可(ユーザー占有で登録する)でよいと思います。--spinda-kkmr 2014年12月28日(日) 19:05
  • 賛成です --pyrite 2014年12月28日(日) 20:06

少し考え方を軟化させたというか、明朝体化してある分に関しては、別の接尾辞で独立するならば制限しなくてもいいかなと思うようになりました。接尾辞をどうするか悩みますが。--kamichi 2014年12月28日(日) 20:29

  • 前段の非明朝体異体字扱いの件賛成です。また草書などの崩し字系は、別の接尾辞があるといいと思います。
    ※出典元がハッキリしていればOKとの条件を付与し、「u####-sosho-###」「u####-##-sosho-###」(sosho=草書)
     もしくは、「u####-fude-###」「u####-##-fude-###」(fude=筆書き。「-fude-」なら行楷書もOK?)などの接尾辞を新設。

    以前、大字典𡨸喃(字形は基本楷書、一部草書または草書楷書交じり)の字形登録(daitudien-013119)で悩んだ末、
    個人占有グリフkamiyo_creas-u975e-itaiji-001kamiyo_creas-u8863-itaiji-001で設定したと言う事がありました。
  • ※無理やりIDS表記しても、直ぐに64文字越えしてしまいますので…--kamiyo 2014年12月29日(月) 00:50

匿名利用者によって大量に白紙化されましたが、まだ結論を出していなかったのに作業されてしまったという意味で抗議したいと思います。ですが、上記の試案に従って、復活はしないという方針でお願いします。再登録はprefixとして「sosho-u####(-var-###)」という命名を想定しています。--kamichi 2015年2月23日(月) 16:53

その種の字体を大量に登録していたものですが、単にUSER名付きグリフを激増させたくないという理由でitaijiにしていただけなので、他に接尾詞を作るなら白紙化OKです。なので残りも気にせず消して下さい。--yoshiciv 2015年2月23日(月) 18:58

  • 「sosho-」は複数の解釈が想定されるので「sosho-u####(-var-###)」ではなくyoshicivさんが作られたように「sosho-u####-###」でいきたいと思います。

CDP外字の「古」「新」の命名について

CDP外字はグリフウィキでは「旧」版のもの(http://fonts.jp/glyphwiki/cdp3vers.pdf の中央のもの)をベースに作成されていますが,「古」「新」のグリフを作成したいという需要もあるようです(ノート:cdp-9daf参照)。以下に,案を示します。

利点欠点
案1(現状)cdp-####-kocdp-####cdp-####-shin直感的に
わかりやすい
検索がしにくい※
案2
(spinda-kkmr提案)
cdpo-####cdp-####cdpn-####検索がしやすい直感的に
わかりにくい
案3
(pyriteさん提案)
cdp-####-oldcdp-####cdp-####-new

※検索がしにくいとは,例えば「古」版のCDP外字だけを検索したくても難しい,ということです。また,先頭一致検索で“cdp-”を検索すると3つのバージョンのCDP外字が交ざってしまいます。
個人的には案2が望ましいと思いますが,皆様のご意見をお願いいたします。
以上,--spinda-kkmr 2014年11月29日(土) 10:37

  • CDP外字はこれ以上バージョンが増える可能性はありませんか?(shinshinとか出る羽目になったらイヤなだなぁ)
  • ないのなら上記のような感じでいいと思うのですが、個人的にはko/無印/shinよりはold/無印/newがよいです。
    あと検索は正規表現使えないんでしたっけ。使えるなら便利なのですが。--pyrite 2014年11月29日(土) 11:54
  • 表にpyriteさんの案を追加しました。私は案2を支持する理由としては,CDP外字は「古」「旧」「新」では全く字形が違う場合があるので,基本的に同一の文字がベースであるUnicodeのソースを表す“-g”“-k”のように接尾語で表現するのは好ましくないと考えるからです。--spinda-kkmr 2014年11月29日(土) 12:04
  • 「古」版と「旧」版で字形が異なる例としては,「古」版のcdp-8b7dsandbox@2062に対し,「旧」版のcdp-8b7dなどがあります。--spinda-kkmr 2014年11月29日(土) 12:17
  • ワイルドカード[_][%]が使えるようです。また、デフォルトの検索にはキーの末尾に[%]を付与して検索しているようです。[cdp%-8555]で検索するとcdp-8555cdpo-8555cdp-8555-koがヒットします。好みとしては接尾語をつけるスタイルのほうがいいのですが、特にこだわりはありません。 --tsuruki 2014年11月29日(土) 14:19
  • 私は最初、案3の「cdp-####-old」「cdp-####-new」(私も同じ事を考えていました)がいいかな、と思いましたが新旧で字形が全く異なる観点、かつ直感的に解りやすいと言う事を考えると、「cdp-old-####」「cdp-####」「cdp-new-####」が良いかと思います。
    あとバージョンが増える事を考えた場合であれば、「cdp-v1-####」「cdp-v2-####」「cdp-v3-####」として無印「cdp-####」をいずれかのバージョンにエイリアス化するのも有りかと思います。--kamiyo 2014年12月29日(月) 10:12

  • ずいぶん昔の話になってしまいますが、また、どれが旧でどれが新かという議論もありますが、案2でいきたいと思います。理由は上記にあるように、3バージョンでまったく異なる字形が入っているケースがあり、「別集合」を強調するためです。--kamichi 2015年5月6日(水) 21:29

Ext F2グループの生成

Ext F2が追加される予定であることを案じて、ExtF2仮というグループ(グループ:ExtF2仮)を作っておきました。それに伴い、まだ追加していない漢字を補えば幸いだと思います。--ldx0 2014年10月22日(水) 10:19

補正して欲しい字に関して

教育部異体字事典の様な楷書のソースから転写しようとしたけれど上手く再現できないといった場合のための「グループ:請補正字」のようなものはあるのですか?今の自分の場合はu7fb9-itaiji-002なのですが。 --yoshiciv

  • 現状では残念ながらありません。積極的に請うという意味ではグループを作成した方がよいと思います。それと、できれば署名の際、「〜〜〜」に加えてもう一つ「〜」を入力していただけると(つまり「〜」4つ)、投稿日時も自動的に入ります。--kamichi 2014年10月17日(金) 08:36

  • 一般の「問題のあるグリフ」の様なグループもよいと思います。u2ff0-u5200-u524a(⿰刀削、IDSは字形と違います)などの為に作るのはどうですか?--umbreon126 2014年10月20日(月) 10:38
    • 賛成です。また、問題のあるグリフ以外にも「翻訳を手伝ってほしいドキュメント」「作業中」などのタグをつけて、そのタグが付いている一覧を特別ページで出せるといいかなと思います。wikipediaがどのような方式かを知らないので、調べてみます。--kamichi 2014年10月20日(月) 10:53

外国語の記事の見分けについて、およびグリフウィキの多言語UIについて

今のグリフウィキのなかで外国語への翻訳が進んでおり、それを見分けやすくためにグループを作る必要がございます。それにつれ、まず韓国語からなる記事を含むグループ(グループ:韓国語対応ページ)を作っておきました。外国語の記事を同定しやすくためな提案なので、皆様からのご意見をお伺いしたいです。--ldx0 2014年10月15日(水) 11:35

  • (一番上に持ってきました)ありがとうございます。韓国語のUIはすでにデータをいただいていること、および中国語のUI、韓国語のページについて、翻訳を協力していただけるという申し出を受けていること、もありますので、早急に翻訳についての作業場を整備しなければなりません。--kamichi 2014年10月15日(水) 12:39

  • 翻訳プロジェクトの件について、メールを送りました。ご確認お願いいたします。--ldx0 2014年10月15日(水) 13:00
    • 確認しました。ご協力ありがとうございます。--kamichi 2014年10月17日(金) 08:43

見出しを勝手に分岐してしまいますが、現在日本語と英語の2言語が用意されているグリフウィキのUIについて、韓国語と簡体字中国語を増やしたいと思います。これは純粋に利用者(登録および活用のいずれも)を増やしたいという意図もありますが、将来的に科研費などの研究費を申請するにあたってのアピールの側面もあります。現在韓国語が50%程度、簡体字中国語は始めたばかりです。これら2言語について、ある程度完成してから実運用に入ろうと考えていましたが、逆に運用を始めてしまい、「翻訳が足りないな」と思ってもらう方がいいのかと思うようになりました。どちらがよいと考えますでしょうか。なお、当然ですがUI言語を増やすことにより、今までの価値観でいうノイズは増えると思いますが、これは受け入れざるを得ないと考えます。--kamichi 2014年10月17日(金) 08:43

  • 別件のいたずらのこともあり、日本語以外のUIはROM(閲覧)のみの機能にするということもちょっと考えています。やや極端すぎるでしょうか。--kamichi 2015年1月7日(水) 23:40

新しい接頭辞の決定について

(すでにこの意見は出されているかもしれませんが)緩やかな運用の方法として、今後、新しい接頭辞を使いたいという場合に、「グループ:接頭辞」というページを作り、そこにその出典情報やグリフ名の命名法を書く形で明示するという運用はいかがでしょうか。たとえばすでにガイドラインに入っている「koseki-######」については「グループ:koseki」のページを作るという方法です。うまく統一できれば機械的に「koseki-######」のページに「グループ:koseki」へのリンクを張る形にしても良いと思います。一部の文字コード(CNS 11643)についてはページが乱立してしまいますが。--kamichi 2014年9月30日(火) 14:01

  • 微修正します。単に接頭辞の名前のページだとバッティングする可能性があるので「グループ:prefix-(接頭辞)」にしようかと思います。長いでしょうか?--kamichi 2014年10月8日(水) 08:39

  • 賛成です。「グループ:」の後ろに「prefix-」のように何らかの接頭辞のグリフか、その他のグループか判りやすいと思います。ちなみに名称の長さは、グループ名ですので気にならない範囲だと思います。--kamiyo 2014年10月13日(月) 19:43

  • 異論が出ていないようですので,試みに香港のIVD提案のためのグループ:prefix-hkaを作りました。kamiyoさんの作成されたページを真似ています。共通して必要な情報があれば,テンプレートを定義していただくと,グループの作成者が助かると思います。 --ziyang 2014年12月28日(日) 18:23

GTコード(GT書体)の字形について

下記の「GやTやVソースの字形を忠実に再現することに関して」でも言及しましたが,GTコード(GT書体)は画数を明確にするために故意に不自然な字形を作成していることがあります。

  • 例 「好」u597dに対しsandbox@996 (gt-07641) (女偏の形が違う),「行」u884cに対しu884c-g (gt-45899) (左側の行人偏の縦棒の頭が接続)など。

私はこれを厳密に再現する必要はないと考えます。その理由としては,

  • (1)CHISE-wikiでは,GTコードと他の文字コードをGT書体独特の字形を考慮せずに対応付けている。
  • (2)厳密に再現しようとすると女偏や人偏,行人偏のグリフを既存のグリフとは別に作らなければならず,結果として“gt-#####”グリフの登録の妨げになる。

の2つです。試案として,以下の2つを提案いたします。

1.以下の字形を許容する。

GT書体での字形グリフウィキ上で許容する字形
人偏u4ebb-01-var-001u4ebb-01
行人偏u5f73-g01u5f73-01
女偏u5973-01-var-002u5973-01

※行人偏には行構えの左側を含む

2.画数を明確にするための不自然な字形(例:gt-00700@2の中央下の折れなど)を厳密には再現しなくてよい。

以上,--spinda-kkmr 2014年9月15日(月) 17:45

  • 上記許容に賛成です。
  • あまりGT書体は確認しておりませんでしたが、結構癖のある字形が多いですね。(ExtFのz-sat#####もGT書体由来?)
    上記2.と重複している可能性がある気もしますが、現状判明している分を念の為以下表を追加致します。
糸偏u7cf8-01-var-002u7cf8-01
u53b6-gu53b6
口、日、目など四角形の字形または
左下、右下縦棒の終筆部アクセント有無
sandbox@1962u53e3
  • --kamiyo 2014年9月19日(金) 22:55

  • 反対です。
  • グリフ名の対象となる字形が明確な物(対象がフォントや大きな画像情報)の文字に対してはなるべくオリジナルと同じようにするべきだと思います。 --tsuruki 2014年9月21日(日) 11:23

  • (口(や糸の「厶」)は こんな(umbreon126_sandbox@31) 字形でしょう。)私は今反対も賛成もない。でも、私の意見では、要項は筆画の字形ではなくて漢字の字形(??)です。例:厶の鱗の有無は重要ではない、口はどうでも良い(Gソースのような字形はどうでしょう?GT書体は中国の字形を基にするようです)、人偏は(中華字海と同様に)u4ebb-01-var-001とする--umbreon126 2014年9月21日(日) 12:02

  • この問題は結論が出にくいと思います。GT書体は抽象字形ではなくフォントなので、忠実に再現するべきという意見に私も同意しますが、では忠実とは何か、という部分では人によって字形差の認識に差が出ると思います。台湾の「口」もそうですが、GTの「口」を忠実に再現すべきかと聞かれれば個人的意見としては同意しにくいです。ですので、面倒ではありますがやはりガイドラインというか個々の特徴的部品について、○×で意見をまとめるしかないのではないでしょうか。--kamichi 2014年9月21日(日) 19:39

  • GTコードの実装はGT書体だけではありません。Tフォントの3書体もGTコードを実装していますが、これらの字形は(Tゴシック、T楷書はもちろんのことT明朝も)必ずしも上記のような字形を再現していません。ですからGT書体のデザインを忠実に再現する理由はないと思います。むしろT明朝を参照したほうがいいのでは。--emk 2014年9月21日(日) 21:15
    • なるほど、それもおっしゃる通りですね。ただ、おそらく当初はグリフウィキにおける「gt-」はGT書体を想定していたと私は思います。GT書体とGTコードを別に考えるとしてグリフ名も分けて考える必要がありそうです。これはデータの登録者・利用者の意向が優先されると思いますが、実際問題としてGTフォントとT明朝、いまはどちらのシェアが高いでしょうか。私の周りではやはりまだGTフォントを使っている人がちらほらで、T明朝利用者は聞いた事がありません。--kamichi 2014年9月21日(日) 22:53
    • T明朝のほうがいいでのはないかと思ったのは、より一般的な明朝体のデザインに近いので、より仮想J字形と整合性のとれたデザインになる可能性が高いと思ったからです。GT書体のグリフそのものがほしければGT書体をそのまま使えばいいのではないでしょうかと思いましたが、ライセンス上の理由(商用利用不可)から自由でGT書体のデザインに忠実なグリフへの需要があるのでしょうか。--emk 2015年1月2日(金) 16:17

  • 議論が止まってしまっていますが,あくまでも「許容」であって仮想J字形のような「強制」ではないので,これで運用してもかまわないと思います。“忠実に再現したい場合にそれを禁止するものではない”というやや緩めのガイドラインで運用すればよいと思います。--spinda-kkmr 2015年12月27日(日) 11:52
  • とりあえず,上記のガイドラインで試運用してはどうでしょうか。--spinda-kkmr 2015年12月27日(日) 12:17
    • 試運用に賛成です。というのは、グリフウィキは字体差と書体差の線引きがあくまでもユーザーの主観によるので、結論は出せないと思います。区別したい人に禁止を強制できない、という形になると思います。--kamichi 2015年12月29日(火) 14:38
  • グループ-ノート:GTコードに上記ガイドラインを追加しました。--spinda-kkmr 2015年12月31日(木) 12:56

手書き検索について

出やすい文字と出にくい文字の差が激しいと感じていましたが、どうやら書き順が重要なようです。ちょっと困りますね。--kamichi 2014年8月13日(水) 15:21

IDS名称ミスのグリフについて

現在,u2ff1-u52d7-u65e5@3(⿱勗日,正しくはu2ff3-u8279-u7530-u65e5)のような誤ったIDSのグリフがいくつか存在するようです。これらは残しておく必要性が低いと思うので,白紙化したほうがよいと思います。--spinda-kkmr 2014年3月22日(土) 12:54

  • ツイッターで呼ばれたので来ました。
  • ①については白紙化すべきだと思います。白紙化を避けるのは、基本的に、一つのグリフに対して正しい命名が複数ある場合なので、間違った命名は対象にならない筈です。(長期間放置された間違いなのでサイト外から参照されている可能性があるとかいう問題は、「白紙化の抑制について」の議論で私が書いたようにシステム側で対応してほしい所です。)
    ②は余力があればやりましょうか。数が多くて面倒な時とかはdo-not-useを付けるだけでもいいですよね。元々do-not-useの付加は恒久的な状態ではなく、「いつか消すべきだし、今すぐにでも消したいけど、ほかの専有グリフに部品として引用されてるのでシステム上消させてくれない」という意味で使っていたので、グループの問題が解消した時点で誰かが消せばよい、という事で。— sayunu 2014年6月21日(土) 13:05

TRONコードの命名について

現在,TRONコードの命名は“tron-#-####”となっていますが,TRONコードは現時点で第31面まで予約されており,第10,16,17,22,23面には既に文字が割り当てられているようです。したがって現在の命名ではこれらに対応できません。解決法として,次の2つが考えられますが,どちらが望ましいでしょうか。

  • (1)“tron-##-####”に変更する。
  • 例えばtron-9-8023@5tron-09-8023に変更する。わかりやすいというメリットはありますが,既に存在する“tron-#-####”のグリフを移動・白紙化しなければなりません。

  • (2)第10面以降を英字で表現する。
  • つまり第10面は“tron-a-####”,第11面は“tron-b-####”とし,第31面を“tron-v-####”とする。第10,16,17,22,23面はそれぞれa,g,h,m,nとなる。既に存在するグリフ名を変更しなくてよいというメリットはありますが,第10面以降が直感的にわかりにくくなります。

私は(1)が望ましいと考えますが,皆様の意見をお願いいたします。
参考ですが,2014年1月1日時点の“tron-#-####”のグリフ数は383です。
以上,--spinda-kkmr 2014年1月25日(土) 11:11

現状 CNS 11643 が36進(10+アルファベット)になっているので、(2)の1桁でいいのではないでしょうか。 --tsuruki 2014年1月25日(土) 14:17

  • 私も(2)の名称はCNSの「TA-####(10面) TB-####(11面) TC-####(12面) ...」を連想しました。
  • またTRON自体31面を超える事が無さそうですし、現状の名称を崩す事をせずにすみますので、(2)で良いかと思います。---kamiyo 2014年3月1日(土) 10:26

  • すみません、意思表明していませんでした。大変申し訳ないのですが、私は(1)案を支持します。移行グリフ数もそれほど多くなく、脳内での読み替えが不要になるためです。移行は機械的にやっても構いません。--kamichi 2014年3月1日(土) 17:06

    • 私は(1)案支持です。今後TRONコード(TRON文字収録センター)の活動が再度活発化すれば第32面以降に拡張される可能性もありますし,グループのほうは比較的楽に修正できるので,グリフの置き換えを行っていただければありがたいです。--spinda-kkmr 2014年3月1日(土) 18:31
    • 移行が正式に決まるまでは,“tron-#-####”グリフの新規作成は控えさせていただきます。--spinda-kkmr 2014年3月2日(日) 11:11
    • 余談となりますが,TRONコードの第11面から第15面まではかつて〓〓〓〓〓が使用していたので,“tron-11-####”~“tron-15-####”はライセンス上作成できないと命名ガイドラインに明記しておかなければいけませんね。--spinda-kkmr 2014年3月2日(日) 13:41

  • 半年前で議論が止まってしまっていますが,個人的にはTRONコードを利用したいので,なるべく早くグリフ名の移行を行っていただければありがたいです。グループは利用者側で比較的楽に修正できると思います。--spinda-kkmr 2014年9月21日(日) 11:28

  • 議論が長期間止まってしまっているために,TRONコードのグリフの新規登録が事実上できない状況が続いています。グループ:TRONコード序数記号に収録されている記号など,TRONコードでしか表現できないものもあります。できる範囲内で,早期のグリフ名移行をお願いいたします。グループは利用者側で修正できると思います。--spinda-kkmr 2015年1月30日(金) 17:18

  • 催促するようで申し訳ありませんが,時間のある時でよいので,なるべく早くグリフ名の移行をお願いいたします。グループ側は各利用者で修正できると思います。現状ではbotの利用はkamichiさんに限られていますし,私はプログラミングができませんのでbotの作成ができません。自力では何百もあるグリフを手動で移動しなければなりません。--spinda-kkmr 2015年3月28日(土) 19:10

  • 催促ありがとうございます。今から開始します。以下の手順を想定しています。--kamichi 2015年3月28日(土) 21:15
    • 新グリフ名を旧グリフ名のエイリアスとする完了
    • エイリアスの向きを逆転完了
    • 1日置いて、旧グリフを白紙化

質問

すいません。Exta日本提案字って何ですか?こんな質問ですみません。

  • 質問の意図が分かりませんが、1つの意味はExt.A集合の審議の際、日本代表から提出された追加希望集合のことです。各国・地域からそれぞれ提出のあった集合について審議し、1つにまとめていきます。--kamichi 2013年12月3日(火) 08:23
    • ちなみにその集合はUCSでは「Unified Japanese IT Vendors Contemporary Ideographs」(略称JA)と呼んでいますので、この名称で検索するといろいろでてくると思います。--kamichi 2013年12月3日(火) 08:27

MJ文字図形名“jmj-######”の命名ガイドライン追加について

“jmj-######”を命名ガイドラインに追加することを提案いたします。現在,Ext-FにおけるJソースとしてこの命名が出現し,グリフが作成されていますが,

という理由から,命名ガイドラインに追加するに足るものと考えます。ご意見をお願いいたします。--spinda-kkmr 2013年7月5日(金) 20:56

  • “jmj-######”ですが、命名ガイドラインに追加賛成です。mjの文字収録数が6万字近く存在する上、現在提示されているExtF(v1.0)に存在する“jmj-######”も1800字超存在しますので追加すべきと思います。--kamiyo 2013年7月5日(金) 22:47

  • 賛成です。簡単ですが取り急ぎ。--kamichi 2013年7月6日(土) 09:55

    • “jmj-######”を命名ガイドラインに追加しました。--spinda-kkmr 2013年7月6日(土) 11:50

Jソースが存在するExt-Fの字形について

extf-07257(jmj-058846)のように,Jソースが存在するExt-Fの字形については,GlyphWiki:仮想J字形のガイドラインを適用せず,1点之繞などの新字体的な字形もそのまま作成する,ということでよいでしょうか。--spinda-kkmr 2013年5月25日(土) 19:27
  • その方針でよいと思います。GlyphWiki:仮想J字形のガイドラインの「仮想J字形が適用されるグリフ」の節に、そのようなグリフを除外する旨を書き足すべきと考えます。―twe 2013年5月25日(土) 20:15
  • 提案ありがとうございます。賛成です。若干気になっているのは、昔Ext.Cの資料で平成明朝ではない日本提出のグリフが最終的に若干変化した記憶があります。Ext-FのJソースというのは字体として固まっている物なのでしょうか。--kamichi 2013年5月26日(日) 08:47
    • 現在のExt-Fの資料では,Jソースはほとんど(全て?)が“jmj-0#####”となっており,これは文字情報基盤文字情報一覧表 のMJ文字図形名と一致します。ですので,字形としては安定していると思われます。--spinda-kkmr 2013年5月26日(日) 10:01
  • 遅くなりましたが,GlyphWiki:仮想J字形のガイドラインにExt-Fのグリフに関する記述を追加しました。--spinda-kkmr 2014年2月9日(日) 18:27

Unicodeにない戸籍統一文字等のIDS表現について

  • Unicodeに存在しない戸籍統一文字(koseki-#####0),住基ネット統一文字(juki-####),登記統一文字(toki-0######0),GTコード(gt-#####)について(以下,「戸籍統一文字等」とします),私はIDS表現によるグリフを実体とし,これらUnicodeに存在しない戸籍統一文字等のグリフをそのエイリアスとするのが望ましい(例:u2ffa-u8fb6-u9ce5を実体とし,gt-52573をそのエイリアスとする)と考えますが,どうでしょうか。
  • 私がIDSを優先すべきと考えるのは,IDSを用いればUnicodeに無い文字をUnicodeで疑似的に表現できるので望ましいと考えるからです。
  • 以上,--spinda-kkmr 2013年4月19日(金) 18:29

    • 亀レスで恐縮です。いまIDSグリフが大量に登録されていますが、そこで懸念しているのがUCSコードが抽象字形を指しているため、そのうちG風とJ風でバッティングしてしまうのではないかと思っています。この場合「IDS-var-###」になると思いますが、そう考えると挙げられた「戸籍統一文字等」の方が字形が安定しているのではないかと考えます。いかがでしょうか。--kamichi 2013年6月3日(月) 12:01
    • 私はJ字形を基本にIDS表現していたので,例えばu8fb6は2点之繞,ufa66は1点之繞というようにしていましたが,確かに他のソースのことを考えると(u8fb6-gは1点之繞)字形の衝突が起こりえますね… 最近大量に登録されているG風のIDSグリフについては私はよくわかりませんが,戸籍統一文字は文字情報基盤文字情報を経由してUnicodeに登録される可能性が高いので,無理にIDS表現にこだわる必要も無いかもしれませんね。--spinda-kkmr 2013年6月3日(月) 20:02

    • 私もIDSを実体とし、koseki-######などをエイリアス化する方向に賛成です。
    • IDSの無印を仮想J字形(または左下GTなどを使用しないJ字形に近い形状)にした上で、仮想J字形以外の字形と偏化変形を全て「IDS-var-###」に字形を割り当てるのも有りなのかとも思います。
      当方も中華字海、台湾教育部異体字字典、會保存遺産喃の字喃など、G,T,V字形に該当する物を多数作成しておりますが、文字によって字形に差異のあるものが多々見受けられます。
    • また、現状関連字はCJK統合漢字1字を割り当てることが可能ですが、関連字にIDS(3字以上)が使用できれば、さらに見やすくなる気もします。
    • 例えば、仮想J字形にu2ff1-u8002-u2ffa-u200ca-u53ea(壽・寿の異体字の一つ)を作成し、(現在の関連字:寿) u2ff1-u8002-u2ffa-u200ca-u53ea-var-001(zihai-117106) (zihai-...をエイリアスとする)、(現在の関連字:壽) u2ff1-u8002-u2ffa-u200ca-u53ea-var-002(twedu-a00836-069) (twedu-...をエイリアスとする)をそれぞれ関連字に「⿱耂⿺𠃊只」を割り当てて、異体字関連グリフに「壽(台湾教育)」「寿(中華字海)」を割り当てる。--kamiyo 2013年6月10日(月) 15:34

JIS規格になくAdobe-Japan1だけに存在する漢字について

1年前、ノート:u26c9eに書きましたが、返事がなくて井戸端で議論したいと思います。

𦲞(u26c9e) のように、JIS規格になくAdobe-Japan1だけに存在し、AJ1の字形がUnicode/ISOと異なると、AJ1の字形を優先するのはいかがでしょうか。AJ1は日本語表記に使われている文字を集めている集合なので、準JISみたいなものだと思われます。ちなみに、メイリオもそんな実装をしているようです。 --johotogoshinentai 2013年3月26日(火) 10:48

  • 気が付かずすみません。賛成です。--kamichi 2013年3月26日(火) 11:00
  • 賛成です。--spinda-kkmr 2013年3月27日(水) 19:25

    • ちょっと考えてみましたが、Jソース(JA、JHソースなど)とAJ1の字形異なると、JソースとAJ1のどっちを優先するほうが良いでしょうか。 --johotogoshinentai 2013年3月31日(日) 00:34

    • JA,JHの場合悩ましいですが、原則論は国内規格字形優先が妥当かと思います。--kamichi 2013年6月3日(月) 12:04

CJK互換漢字の字形の扱いについて

CJK互換漢字の無印グリフ(ないし、無印廃止後に花園フォントにおいて採用されるグリフ)の字形の扱いはどうなっているのですか?

互換漢字は統合されないにも拘らず一つのコードポイントに複数のソースが与えられています。無印グリフにjv字形を適用しないとしたら、いずれのソースを典拠にするのかを決めなければなりません。そもそも、互換漢字の無印グリフはそれがどこのソースに基づくものかすらグリフページからは分からないわけですから、いずれにしても現時点で統合漢字より、地域ソースグリフ作成の必要性が高いと思います。

現状の互換漢字は、無印グリフが無秩序な状況になっていると思います。たとえばu2f88bはjvでもUCSソース(tとkp)でもない中途半端な字形です。またこの字について、UCSソースにあたる字形を持つグリフは現在存在していません。あるいはu2f9bcは、TソースとHソースがある中でTソースが“恣意的に”採用されている状態です(Hソースは「ヨ」の中の棒が飛び出ません)。それともこれにはHソースではなくTソースを選ぶ特別の理由があるのでしょうか。

互換漢字の字形はどのようなものにするのかを決めてガイドラインに示すこと、そして全互換漢字について地域ソースグリフを作成していくことが必要だと思いますが、どうでしょうか。--kirikaxfan 2013年3月23日(土) 13:13

  • ちょっと説明(解明?)します。互換漢字は、「その互換漢字がどんな字形の違いを目的としてエンコードされたか」をde factoの原則(?)としてきました。たとえばu2f88bは、u5eb0-tとは「并」と「幷」の違いでエンコードされているものです。ですので、「并」と「幷」の違いを反映し、それ以外の違い(この字の場合、u5e7f-05u5e7f-t05の違い)は反映しません(u5e7f-t05を使うと、ほかのグリフとのデザインが一貫性がなくなることもあります)。
  • u2f9bcにTソースの字形が反映されているのは、もともと「CJK互換漢字補助」領域の文字は、複数欄ではなく、Tソースの字形しかなかったからです。ですのでTソースの字形に合わせられています。
  • 互換漢字について地域ソースグリフを作成していくのは全く問題ないと思います。 --johotogoshinentai 2013年3月23日(土) 14:00

    • まず、ここで使われている「エンコード」という言葉の意味が分かりません。「符号化」=「コードポイントを与える」という意味ですか?
    • であれば、之繞はどうです?KS X 1001用互換漢字は、統合先との間に字形の差を与えないものです。しかしその一つであるuf99aは、u9023に統合される互換漢字であるにも拘らず、統合先とは異なり二点之繞になっています。これはどういう理窟ですか。
    • またu2f9bcについては、理由は分かりましたが、私が言いたいのはそういうことではなく、では現時点にあって、それでいいのですか?ということです。「理由」ではなく「根拠」の問題として、歴史的にではなく論理的に、今TソースとHソースが対等の立場なのであれば、今Tソースが選ばれていることは“恣意的な状態”ではないですか、ということです。もし今、このグリフをTソースにしたい人とHソースにしたい人が現れて編集合戦を繰り広げたとしたら、どちらに決着させるのですか、ということです。もし現時点でそれに答えがないのだとすれば、これは普遍的な問題ですから、新たにルールを定めて解決する必要があるはずです。
    • どうでしょうか。--kirikaxfan 2013年3月23日(土) 15:01

      • 「符号化」のことです。
      • 字形の差について、ちょっと補充します。「その互換漢字がどんな字形の違いを目的として符号化されたか。(仮想)J字形で使われているデザインなら、その差も反映する。使われていないと、その差は反映しない。」つまり、「なるべく元の字形を反映し、(仮想)J字形と合わない差は反映しない」ということです。2点之繞はJ字形でも使われているので、問題ないと思います。実際、メイリオなどもuf99aは2点之繞にしています。
      • それについてはちょっと考える必要がありますね。 --johotogoshinentai 2013年3月23日(土) 15:59

  • (インデント戻る)だからそもそもuf99au9023には「差」がないんでしょう!韓国ではu9023も二点之繞でしょう。K0-5627は確かに二点之繞になってますよ。GlyphWikiにグリフもありますよ(u9023-k)。このグリフはuf99aと互いにエイリアスですよ!そりゃそうですよ“読み方”が違うだけなんですから。意図された字形の差なんてあるはずがない。差がないのに、「差として反映される」って、一体どういう理窟なのですか。johotogoshinentaiさんは韓国の方でしたよね。韓国のフォントではそうなっていないのですか?
  • すみませんが、私はこの辺りでひとまずこの議論を離脱します。好んで編集合戦をする気はありませんが、当面この一連の問題について独断的にリバートを通告されても関知しませんので、編集内容に問題があるとお考えならば皆さんで議論して結論を出し、ガイドラインに成文化してください。私の編集のやり方はその段階で考えます。これがGlyphWikiに相応しくないと判断されるならばBANしてもらっても結構です。
  • ノート:ufa5eにおける議論も収束はしていませんが、まとめてここで離脱を宣言します。ただ最後に最低限はっきりさせておくべきことは、互換漢字をエイリアス実体とすること、特に“排他的に”そのようにすることには私は複数のレベルで違和感を持っているということです。議論に集中していて曖昧なままになっていたのでここに記しました。以上です。--kirikaxfan 2013年3月24日(日) 19:45

    • ご指摘ありがとうございます。私の中途半端な説明で気分が悪くなりましたら本当に申し訳ありません… 私は慣習や慣用などを規則として定立しようとすると、見落としが発見されることが多いので…
    • 離脱を宣言しましたが、いったん改定案(?)を書いておきます。
    • 意図した字形に違いがあると:「その互換漢字がどんな字形の違いを目的として符号化されたかを重点にする。(仮想)J字形で使われているデザインなら、その差も反映する。使われていないと、その差は反映しない。」
    • 意図した字形に違いがないと(主にKS X 1001の重複漢字):「できるだけ元の字形を反映する。ただし、(仮想)J字形で使われているデザインだけを反映する。」
    • これで良いでしょうか。 --johotogoshinentai 2013年3月25日(月) 01:34

      • 私が前段に書いた内容論の表現はレトリックです。口語的な表現の方が焦点の置き方が分かりやすいというのが根幹にありまして。許容範囲内とは思っていますが、攻撃的に見えたかもしれないので、その点お詫びしておきます。失礼しました。
      • 提案がなされていますが、この問題はかなり大きな問題、根本的な問題を含んで一筋縄にはいかないように思うので、私としては引き続き意見の表明を控えさせていただきます。申し訳ありません。--kirikaxfan 2013年3月27日(水) 09:21

メタ情報の削除について

  • 荒らしによってノート:aj1-20072に書き込まれたメタ情報を削除しようとしてもできません。これは仕様でしょうか? --spinda-kkmr 2013年2月28日(木) 19:01
    • あれ?普通に白紙化できましたが、どのような状況でしょうか。(私はJavaScriptを切っているのでそれでOKだったのかもしれませんが…)--kamichi 2013年3月1日(金) 07:46
    • 先ほど,匿名の状態でsandboxにメタ情報を書き込み,その後ログインして編集を試みたところ,正常に削除できました。ノート:aj1-20072の時はメタ情報が存在するにもかかわらずノートページにメタ情報が表示されませんでした。原因は不明です。--spinda-kkmr 2013年3月1日(金) 18:24

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

KAGEエンジンの新しい改造内容について(2/12更新)

  • sandbox@1130のように、99で引用した部品について、ストレッチ機能を追加しました。中心(100,100)から第2項目をX座標、第3項目をY座標(ただし中心からの差分)で表現される座標に向けてリニアに変形させます。たとえば「99:-20:0」とすると左に圧縮します。「99:0:-20」とすると上に圧縮します。圧縮の端は0,0や200,200の外枠ではなく、その部品の最端座標になります。

  • 大変申し訳ないのですが、現在のグリフエディタにこの機能を追加することができません(あまりに煩雑すぎて断念しました)。ですのでしばらく手作業になります。(根性でなんとかグリフエディタでも反映できるようにしました。99部品を選択すると真ん中につまみが表示されるので、それを0,0-200,200の範囲内(目安)で動かしてください。

  • 現在試行中とし、しばらくしてこの機能がメリットがあるかないかを判断し、ないということでしたら廃止します。--kamichi 2013年2月1日(金) 22:09
    • 早速機能を使用させて頂きました。私としては、乱立した部品を一つの部品で賄え、統合、グリフ毎の微修正が部品をばらす事無く出来そうなので大変有り難いです。
    • となると、偏化変形部品ですが、例えばufa66u8fb6-g10u8fb6-10-var-001u3ac3-05-var-001u3ac3-10u9580-05u9580-10u9580-10-var-001などの部品は、それぞれストレッチ機能を使用し完全統合しても良い様な気もします。
      置き換えに関しては、取り敢えず、使用数の少なそうな部品のみストレッチ機能を使用した部品に置き換えていこうと思います。--kamiyo 2013年2月2日(土) 02:05
    • ご意見ありがとうございました。また、ご迷惑をおかけして申し訳ありませんでした。--kamichi 2013年2月2日(土) 17:29

  • やはり中心から、というのは無理があるかもしれません。任意の点から任意の点への変形でしょうか。また、1つではなく2つ、という要望も出そうですが、そうすると現状のKAGEでは座標が足りなくなってしまいます。たとえば全面引用(0,0-200,200)のみ変形を認めるなどの限定が必要と思います。--kamichi 2013年2月2日(土) 00:29

2/2の変更

大変ご迷惑をおかけしました。99番による部品引用時のストレッチ機能に2種類用意しました。

  • Aモード:中心点(100,100)から任意の1点に向けてのストレッチ
  • Bモード:任意の点から任意の点に向けてのストレッチ

後者は例えば左右2部品の左右のバランスを変更するなど、いろいろ応用ができます。

使い方ですが、まず99部品を選択すると灰色のつまみが中央に現れます。これを操作するとAモードの調整となります。つまみを右(X座標でいう200以上)に持っていくとつまみが左にワープし、同時に中央に黄色のつまみが現れます。これがBモードです。黄いつまみが元の基準となる点を表し(黄つまみを動かすと灰色つまみも同じ位置に動きます)、灰色つまみがストレット先を表します。まず黄つまみで部品内で分割する位置を指定し、いったんマウスクリックを離し、再度クリックすると灰色つまりを動かせますので変形します(2つのつまみは全体(200ドット四方)に対するものなので、部品を100%の大きさにしてからでないとイメージがつかめずうまく調整できないと思われます)。

BモードからAモードに戻すには、灰色つまみを左(0以下)に動かします。

  • 問題点として、上級者以外の人にとっては、変形機能よりも変形され終わった部品が用意されている方が便利、と思うことでしょうか。--kamichi 2013年2月2日(土) 18:07

  • ちょっと自由度が高すぎますね。グリフウィキの理念とは若干ずれてしまっている気がします。パラメータ1つぐらいで調整できる範囲が望ましいかと考えます。--kamichi 2013年2月3日(日) 17:16
    • 私もそう思います。構えや繞を調整するためならば,ストレッチ機能はAモードだけでもよいと思います。そうなると今までにBモードで調整されたグリフを再調整する必要がありますが… --spinda-kkmr 2013年2月3日(日) 19:06
    • ありがとうございます。昔KAGEシステムが自動合成を主としていたときに、はめ込み用の枠(四角)、というものを設定できました。他の部品と組み合わせるとその部分にいれる、というものです。逆に言うとその枠を拡大縮小するような仕組みでいいのかとも思います。個々の筆画に影響を与える変形は上級者すぎるかなと思います。--kamichi 2013年2月3日(日) 21:39

いったん使用停止でお願いします

まだ議論は途中と思いますが、いったんストレッチ機能は新規の使用は停止して、再検討したいと思います。今考えているのは、グリフに新しい線分を設定できるようにします。この線分は始点と終点の2点で構成されます。視覚上はなにも表示されません。変形の度合いが0%〜100%に相当します。つまり変形Bタイプの黄色の点が始点に相当し、灰色の点が終点に相当します。そして99部品として利用するときにスライダで0%〜100%の範囲で変形度合いを調節する、というものです。線分上をスライダでそうさするか、X軸とY軸に分けてスライドできるようにするか悩んでいます。--kamichi 2013年2月3日(日) 23:16

  • 自由度が相当高いから、かなりデザインの得意な人が慎重に使わないと、グリフ同士の統一性が損なわれる恐れが有るなあなどと思っていました。それで私が考えていたのも、部品側に基準点と変形方向の情報を予め持たせるという案で、多分 kamichi さんが考えていらっしゃるのと似た話だと思います。
  • あるいは、変形度合いの異なる二つの部品グリフを参照して、マルチプルマスターみたいに補間する機能が有ったら、応用性と、簡便さと、デザインの統一性を満たせるかも知れません。ちょっと複雑ですけど。(ニンベンの右側には「去」と「去-02」の平均を使うとかいう事も…。)— sayunu 2013年2月4日(月) 00:02
  • 仮にそうやるとしたら、二つの分離したグリフを参照するのではなくて、一つの部品グリフ内に二つのマスターを纏めて持っておくというシステムの方が良さそうですが、大きな改修になりますかね。— sayunu 2013年2月4日(月) 00:31
  • いや、マルチプルマスターはまた別の話にした方がよさそうですね。単純な変形機能に関して言えば、変形方向に「斜め」って必要でしょうか ? モンガマエ・トラガシラ・シンニョウみたいな大抵の場合は垂直か水平だけでまかなえると思いますが、問題はヤマイダレとかでしょうか。タレの類はかつて「どれぐらいのバリエーションを用意すればいいか検討しないといけないなあ」と思いながら放置してしまったので、まだ自信を持って言えないのですが、ヤマイダレって実は縦の調整はそんなに要らないのではないかという印象が有ります。斜めが可能で困る事も無いでしょうけど。縦横別々に調整できる必要は無さそうに思います。
  • 調整スライダーは、0〜100 の 101 段階という事でしたら、細か過ぎるのではないかと思います。0〜10 の 11 段階で足りるでしょうし、0〜5 の 6 段階ぐらいでもいい気がします。
    部品を作る上では、もしかしたら「始点から終点まで」よりは「基準点からプラス方向とマイナス方向へ」変形できるしくみの方が扱い易いかも知れません。普通は中庸な大きさで部品をデザインしますし…。線分の中心点を基準にするとか ? いや、でもあまり自信は無いです。— sayunu 2013年2月4日(月) 06:18

  • ご意見ありがとうございます。正負両方、荒めに調整、同意します。それで、XとYの分離が必要かどうか、ですが、よくわかりません。たとえば「まだれ」や「しんにょう」などの2方向囲いなどで必要か?と考えました。といっても囲うものはだいたい矩形ですので1軸でいいのかな?まず1軸で実装し、足りないと言うことであれば分離を検討、とも思います。--kamichi 2013年2月4日(月) 08:46

例:ufa66 -> 65,100(L) LだけなのでX軸のみ。Y座標は無視される。X座標65から左端(12)の方向にストレッチ

2/12の変更(第3世代)

  • 手を入れました。KAGEエンジン自体の変更はなく、あくまでグリフエディタにおいて今までのような詳細な変形をできなくしました。
  • まずグリフのメタ情報に「ストレッチ境界」という属姓名で境界となる座標(x,y)とそこからのストレッチの方向(UDLRで上下左右。2つ指定すると四隅を指定)を指定します。
  • その情報があるグリフについてはエディタで99部品として選択したときにストレッチの段階を-10〜10で変更できます。なお、すでに第2世代までで値を設定していた場合、今後メタ情報をセットして部品エディタで選択すると値が壊れますので、再度-10〜10で調節してください。
  • まだ試行とします。各ユーザーの試用をお願い致します。--kamichi 2013年2月12日(火) 01:42

  • メタ情報のセットが面倒なので、あまり使われていませんが、まずは大きな問題無しということで、このやり方での運用を行いたいと思います。メタ情報のセットのし易さについて機能追加を検討したいと思います。--kamichi 2013年2月15日(金) 08:23

UCSの地域+偏化変形グリフについて

vnpf-60838u7fdf-v02ufa1e-v03という引用をvnpf-60838u7fdf-02-var-002ufa1e-03-var-003と変更しました。これは、「-jv」の設置により「地域ソースは規格表で規定されているものに限る」という方針を偏化変形にも適用したためです。u7fdfufa1eにはVソースはないので「地域+偏化変形」グリフは登録できないと思います。しかし皆さんは今までは仮想地域字形として使われてきたかもしれません。

本来「偏化変形+地域」グリフの場合、規格表でその字形が規定されていません。また地域字形にあたるものを地域指定ではなく「-var-###」に持ってくると、「-var-###」が日本では使わないものが並んで濁ってしまうことも考えられます。仮想地域字形を規定するのは面倒ですし、どちらの方針にするか悩みます。

以上ご意見ありますでしょうか?--kamichi 2013年1月20日(日) 16:25

  • 部品グリフの例示ソース指定って、その欄で見受けられる部品の形状ではなくて、親字の特徴を引き継いだ部品を表すんですね。ソース指定と地域指定を別に用意するとしたら…しかし V 欄がベトナム字形の代表として妥当とも限らないし、或る字形を「ベトナムで通用している字形である」と認定するのは我々には中々難しいですね。
  • 連番で var をガンガン作っていくとしたら、ガンガン作ってもゴッチャにならないユーザーインターフェイスが欲しいものです。— sayunu 2013年2月2日(土) 19:06

キャッチフレーズのこと

新しいロゴを kamiyo さんが作ったそうでお疲れ様です。悪くないと思います。(仮名が旧版なのが残念ですけど…。)それで、この「漢字グリフ登録管理サイト」というフレーズはこれが最も良いんですかね ? 初見の人にもこのサイトの目的が端的に伝わるといいなあと思うんですが、「登録・管理」よりは「共有」を前に出したらどうでしょうか ? 例えば「フリー漢字グリフ共有サイト」みたいに…。このシステムの売りは「登録できる、ヤッター」でもなく「管理できる、ヤッター」でもなくて、最終的に「共有できる、ヤッター」でしょうし。— sayunu 2013年1月14日(月) 17:52

  • ご意見ありがとうございます。これ、人によって若干違うでしょうね。私は「自由」という文言を是非入れたかったのですが、どう入れるか悩み、やめました。文言の決定は私の責任だったので、私の考え不足ということになります。もしもっと良い文言がありましたら、kamiyoさんにお願いして文字だけ差し替えていただこうかと思っています。--kamichi 2013年1月14日(月) 17:59

  • ええ、自由(フリー)という表現は是非欲しいです。少なくとも私が考える限り、自分の作るデータを権利放棄してまでこのウィキに預ける事は、本人にとって利益にならない慈善行為ぢゃないですか。このサイトに載っているデータをどこの誰でも手軽に自由に無料で使える様にという目的の為に「登録」も「管理」もやっているんですよね ? データを登録する人よりも、データの恩恵を受ける人の方が多くなってくれないとしょうがない訣で…。
  • …あ、いや、そうか、このシステム上で独自の漢字字形データを「管理」できるのが売りの一つなんでしょうか。その意図は気付かなかったです、すいません。— sayunu 2013年1月14日(月) 18:48

  • ロゴを確定して、100万レコード、30万グリフ達成記念にロゴを印刷したマグカップを作ろうと考えています。ということで、このキャッチフレーズを詰めなければいけないのですが(笑)、「漢字字形自由共有サイト」「漢字字形自由共有網頁」「漢字字形自由共有ウェブ」「漢字字形自由共有Web」「漢字自由共有網頁」「文字自由共有網頁」では意味不明ですかね… --kamichi 2013年1月22日(火) 17:14

  • うーん、その中で選ぶとしたら、一番奇異な感じがしないのは「漢字字形自由共有サイト」でしょうかねえ。「網頁」を使うとしたら、「サイト」ってルビでも振りましょうか。— sayunu 2013年2月2日(土) 18:24

  • ありがとうございます。特に他にコメントもないので「漢字字形自由共有サイト」にしたいと思います。--kamichi 2013年2月10日(日) 21:47
    • ロゴを更新しました。kamiyo様、ありがとうございます。--kamichi 2013年2月11日(月) 16:04

白紙化の抑制について

異論も多いと思いますが、実運用で気になったので、明確にできればと思います。重複しているグリフの白紙化をどうするか、という問題はこれまでにも出てきました。これまでは意味のある重複は白紙化せず、「-itaiji-###, -var-###」に多く見られるただの重複については、白紙化を否定せず、ということでした。グリフウィキ上ではこの方針で構わないと思うのですが、実際にWebでグリフ画像を引用している場合に白紙化されてしまうと非常に面倒です。ですので、今後は「間違い等ではない限り、重複グリフを白紙化しない」という方針に転換したいと思います。同時進行で命名ガイドラインから命名ルールへの移行も想定しているため、それほど混乱は起きないと思います(結局「itaiji, var」あたりで番号を自由につけられる関係上、重複が発生しやすい。そのうち無法地帯になる可能性もある。他の命名を行ったグリフについては「itaiji, var」を作成しない、というルールも必要か)。コメントありましたらお願いします。--kamichi 2013年1月1日(火) 15:43

  • とりあえず、それでよいと思います。— sayunu 2013年1月12日(土) 01:33
  • 異体字グリフ「-itaiji-###」「-var-###」についての白紙化しない件、了解しました。
  • ちなみに、過去に白紙化されてしまったものに関しては、如何致しましょうか。もし、白紙化を今後行わないと言う方針に決定した場合、過去に白紙化されたものに関しましても異体字連番の欠落状態を解消する為、白紙化異体字グリフを復活させた方がいいのでは…と思いました。
    特に異体字作成の際、表示されている異体字番号の次の番号でグリフ作成しようとしたら、以前に白紙化されていた(例えば「uxxxx-itaiji-001」「uxxxx-itaiji-002」が表示されており、「uxxxx-itaiji-003」を作成しようとしたら、実は「-003」は以前に白紙化されていた)と言う事に幾度か遭遇しましたので、少々気になっておりました。--kamiyo 2013年1月12日(土) 11:05
  • 「間違い」には,varとitaijiの使い分けミスも含まれるのでしょうか? やはりUnicodeで包摂されるかどうかはきちんと運用されるほうがよいと思うので… なお,私はitaijiで表現されているグリフをIDS表現に直すことがありますが,その場合でも元のitaijiはエイリアスとして残すようにしています。--spinda-kkmr 2013年1月12日(土) 11:08
    • 難しいところです。個人的には「間違いによる白紙化の是非」は「間違いの種類」ではなく「間違ってから戻すまでの時間」によると思います。つまり、気がつかずに放置してしまった間違いを長い時間が経ってから白紙化するのは望ましくない、という意味です。システム上「削除」を「0:0:0:0」で判定しているので難しいのですが、白紙化するのではなくu342c-02@3のようなやり方もあるかなとは思います。ということで登録時に間違えて、というものはすぐに直せるので白紙化許容とし、時間が経ってしまったものはまずはノートで議論、ある程度問題となるケースの種類がしぼられてきたら再度ルール検討、でいかがでしょうか。あと、白紙化したものを連番で間違えて復活してしまう件はシステム的に補助できないものかと考えます。--kamichi 2013年1月22日(火) 17:21
  • 改めて考えましたが、画像が外部から参照された場合については白紙化直前のバージョンを返すという事は出来ないんでしょうか。ウエブ上で参照できる個別のリソースとしては URL が変らないのが望ましいですけど、データベース全体としては常に最も整理された最新の状態であってほしいですよね。
  • これまでの私の暗黙の方針では、「-02」「-07」などの部品グリフは自立グリフと違って部品専用だから、外部から参照される事などは考えずに、内部的な部品としての使い易さだけを重視して整理・改名していました。どうなんでしょう。— sayunu 2013年2月2日(土) 18:17
    • sayunuさんの意見に賛成です。本来varを使うべきものにitaijiが使われている例が存在するので,そのようなグリフはきちんとvarに移動したうえで白紙化するのが望ましいと考えております。白紙化されたグリフは白紙化直前のバージョンを出すようにすれば,データベースとしての正しさとグリフの安定性を両立させることができます。あるいは,「管理者または他の利用者の判断により白紙化されることがあります。確実にグリフを指定したい場合はバージョンを指定してください。」と注意書きを載せれば,とりあえずは大丈夫だとは思います。--spinda-kkmr 2013年2月2日(土) 18:54

古琴減字譜(GEOG-QIN)の命名規則について

古琴減字譜「geog-qin」のグリフと、減字譜を先日から少々調べていたのですが、現状追加出来ていないグリフが有るものの、現在のグリフ名の付け方の場合ですと、追加が困難であり、改番をした方が良さそうに見受けられました。
そこで「geog-qin-#####」から「qin-#####」へ移行する際、グループ:kamiyo_temp@2の様なグリフ命名規則に変更すると、追加が容易になるかと思われますので、命名変更の提案をさせて頂きたいと思います。如何でしょうか?--kamiyo 2012年12月16日(日) 01:24

  • 賛成です。ですが、もともとの作成者の方がこのドキュメントを見ているかどうかが気になります(仕方ないですね)。あと、現状のグリフについている関連字というのは妥当なのでしょうか?--kamichi 2012年12月29日(土) 23:47

  • 関連字についてですが、現状は呼称が漢字1字の記号は、
  • (「蠲:geog-qin-0160」→関連字「蠲」、「剔:geog-qin-0030」→関連字「剔」 など)、
    その呼称を関連字として割り当てられており、呼称が漢字2字以上の記号は
    (「撥剌:geog-qin-2016」→関連字「撥」、「滾拂:geog-qin-0580→関連字「滾」、「挑四弦:geog-qin-0014」→関連字「挑」、「大指当十二:geog-qin-1112」→関連字「大」 など)
    呼称1文字目を関連字として割り当てられおり、「関連字」としては妥当かと思います。但し問題は、記号によって(特に「大」「中」「名」など)80個近くが同じ関連字に割り当てられており、(減字譜以外)他の漢字(国字、字喃等含む)異体字グリフを探す事が少々困難になっておりますで、減字譜(geog-qin)に関しては関連字を外して、グループ:古琴減字譜(又はこのグループの派生グループ)にグリフを貼付する事で、これ等を解消すると言うのも良いかと思われます。--kamiyo 2012年12月30日(日) 13:40

  • 次はこのグリフ群の新命名への移行に着手したいと思います。--kamichi 2013年2月11日(月) 13:42
    • (done)新命名での旧命名へのエイリアスをはる(グループ:kamiyo_tempに沿って。一部新たに追加されたグリフも対象)
    • (done)エイリアスの向きを逆転
    • 引用部品名の更新
    • 白紙化(geog_にコピーするか要検討。いらないのでは?)

  • 関連字についてはメタ情報に記述し、関連字自体を削除したいと考えます。2、3個の記述で良いと思います。呼称、組み合わせの文字群、などでしょうか。--kamichi 2013年2月11日(月) 14:11

  • Hello! Sorry that I'm not familiar with Japanese and not certain if this is the correct way to join in the discussion. I was tied up and have put down the creation of qin tablature for a while. Thank you very much for Kamiyo's suggestion. I have to admit that my project is a evolving one and could have a better rule. I would like to join in this discussion with a view to creating a set of open source qin tablature characters. --Daniel(利用者:geog) 2013.3.11-0357GMT+8

KS X 1001規格票例示字形(k0-####)のコード位置番号表記について

現在,KS X 1001規格票例示字形“k0-####”のコード位置番号は,区点番号で表記されています。

しかし,CHISE character descriptionやchise_linkmap,およびUnicodeの規格票では,KS X 1001のコード位置はGL領域の番号で表記されているようです。“k0-####”も,“j78-####”や“j90-####”のように,GL領域の番号で表現したほうがよいのではないでしょうか。

以上,--spinda-kkmr 2012年7月27日(金) 19:34

  • ちょっと話が飛んでいるかもしれませんが、私は、k0-####は必要ないと思います。韓国の規格は文字が重なる場合がないからです。u####-kで十分だと思います。
  • できるだけ重複グリフを避けたほうが良いと思っています。--johotogoshinentai 2012年7月29日(日) 12:05

  • 2つの議論を分けて考えたとして、個人的には「k0-####」が「u####-k」で完全に代替できるなら、韓国ソースについては「u####-k」に一本化するということで構わないと考えます。現時点で、「完全」には代替できない、という情報をお持ちの方はいらっしゃいますでしょうか?また、重複グリフについては意見が分かれそうなので、ここでは取り上げないものとしてみます。--kamichi 2012年8月19日(日) 12:51

    • 以前,johotogoshinentaiさんが指摘したことですが,KS X 1001の規格票の草冠は3画草冠u8279-03なのに,ISO/IEC 10646のKソースは草冠がほぼ全て4画草冠ufa5e-03になっています。したがって,KS X 1001の字形とISO/IEC 10646のKソースは異なると思います。--spinda-kkmr 2012年8月21日(火) 19:22
      • そう言われれば、k0-####の必要があるかもしれませんね… --johotogoshinentai 2012年8月30日(木) 03:03

  • もとの話題に戻しますが、区点表記とGL表記とどちらがいいでしょうか。統一するということでGL表記に移行することに賛成です。ある程度たくさんあるので機械的に移行することになると思います。--kamichi 2012年12月4日(火) 08:49

  • この件ですが、GL表記に移行します。機械的に行う(autoglyph-botによる、新規登録と白紙化)予定です。--kamichi 2013年1月1日(火) 16:21
    • 移行が完了しました。--kamichi 2013年2月11日(月) 11:59

GやTやVソースの字形を忠実に再現することに関して(再考か否か)

現在、以下のデザインはデザイン差としてグリフウィキでは認めないとしています。個人的に見つけ次第強めに排除しているつもりです。

  • 折れのカーブ
    • 不可:u533b-t@1
    • ガイドライン:普通に「折れ」を使う(u4ea1)

  • Tデザインの口右下
    • 不可:横棒が飛び出る
    • ガイドライン:普通に右下角を使う

  • Gデザイン「入」の入り
    • ガイドライン:「細入」を使う(c1-442b)※将来的に改善対象

ですが、戸籍統一文字や登記文字を見ていて、迷っています。この方針に関して意見のある方は教えてください。なお、私が拒絶する理由はたとえばTデザインの口を許容すると、あらゆる「口」を含む漢字が単純2倍になってしまう、と感じるからです。--kamichi 2012年3月29日(木) 21:19

  • 私の案としては以下のとおりです。
    • Gソース,Tソース等の字形は,上記のガイドライン通り一定のルールのもとで再現する。
    • 戸籍統一文字,住基ネット統一文字,登記統一文字(以降,行政系文字コードとする)は可能な限り忠実に再現する。ただし,戸籍統一文字は必ずしもデザインが整ってはいないので,見た目を良くする程度の差異は許容する。
  • 行政系文字コードを正確に再現すべきと考える理由としては,行政系文字コードには包摂・統合の概念が無く1つのコードに対しただ1つの字形が存在するためです。
  • また,大規模文字セットであるGTコードについても,GT書体は若干クセのある字形ですので,グリフウィキでどう扱うかを考えるべきだと思います。たとえば,GTコードでの「好」の字(gt-07641)はsandbox@996のようになっており,u597dとは女偏の形が異なっております。しかしGT書体は画数を明確にするために恣意的に通常の明朝体とは字形を変えてある場合もあり,必ずしも厳密に再現すべきかどうか判断に迷うところです。gt-12636u5f71のように,接触・非接触の違いの場合は再現すべきと考えますが,女偏のように部首全体の字形が異なる場合は,デザイン差としても構わないと思います。ただし,GTコード自体には包摂の概念はありません。
  • なお,GT書体の一覧は,こちらのサイト で公開されています。
  • 以上,--spinda-kkmr 2012年3月31日(土) 12:36
  • 追記。GTコード系のフォントではJIS第1・第2水準の文字に対しUnicodeの配置通りのフォントが作成されています(他の文字はシフトJIS領域に対し別の字を割り当てている)が,たとえばsandbox@996(gt-07641)はu597dに割り当てられています。--spinda-kkmr 2012年3月31日(土) 12:44
  • GT書体の字形について分かりやすくまとめますと,「部首全体の字形が異なる場合はデザイン差とみなす」,「その他の字形の違いはなるべく再現する」ということです。--spinda-kkmr 2012年4月7日(土) 19:24
    • GT書体は確かに難しいですね。ですが、住基や戸籍などの例も踏まえると忠実に再現したいという要求に対しては否定できないかと考えます。ある程度共通理解が取れるようであれば「デザイン差」のルール化で対処するということでいかがでしょうか。

  • 話が飛んで恐縮ですが、Tソースの「口」の形状を許容する方向で考えています。ただし、KAGEシステムの思想として右下角の縦棒と横棒の末端がデータ上接続していないというのは許容できませんので、T型右下という形状を追加してから、と考えています。--kamichi 2012年4月24日(火) 08:35
    • 3年間止まっていますが,いまchanhenryfaihangさんがTソースの「口」の形状を作成して,umbreon126さんに白紙化されるというやりとりをしています。いまも方向性が同じなら,T型右下の早期実現が望ましいです。他にもGlyphWiki:ソフトウェアへの要望に要望が出ています。 --ziyang 2015年4月8日(水) 22:02

  • had a try to imitate G source 捺 stroke with visible beginning: u5165-var-001 u516b-var-002. 細入り conforms neither of them, also these two are different. one might be named 半細入り(for G 入, 內, etc) and the other might be 開放半細入り(for G 八, 公, 分, etc). furthermore, observing existing japanese fonts, 捺 strokes other than 乀乁, for example J source u516c u5206, looks like 半細入り, not 細入り which is only for 點. hope that these will be added into KAGE. farter 2015年8月18日(火) 16:50

仮想J字形が戸籍統一文字のエイリアスとして作成されている件について

匿名利用者の方が“u####-jv”“u2####-jv”のグリフを“koseki-#####0”のエイリアスとして作成してしまっています。私はこれは望ましくない(“koseki-#####0”と“u####-jv”が同じグリフなら,後者を実体にすべき)と考えますが,意見をお願いいたします。--spinda-kkmr 2012年1月23日(月) 20:57

追記。上記の結果,同じコード位置の“u####”と“u####-jv”が別のグリフとして存在してしまっているものがあります。私はこれも望ましいことではないと考えます。意見をお願いします。--spinda-kkmr 2012年1月23日(月) 21:01

  • 理想的には、「エイリアスと被エイリアスは上下関係なし」であり、でも「UCS符号位置がベースの方がしっくり」きます。あと、字形が安定している方がベースの方が管理しやすい(そういう意味ではkoseki-の方が安定しているか?)と思います。本来はエイリアスと被エイリアスを入れ替える機能を早く作るべきなのですが、手間取っています。建前上、矛盾する上記2つの理想が、ルールと考えることに同意いただけるようでしたら明文化してもいいと思います。--kamichi 2012年1月23日(月) 21:35

  • UCSとJVの件についても、JV計画が宙ぶらりんになっていて申し訳ありません。早く無印UCSの編集をストップしてJVに移行したいのですが…--kamichi 2012年1月23日(月) 21:35

    • グリフウィキではUCSのコード位置で関連字や異体字を管理しているので,“u####-jv”や“u####-var-###”“u####-itaiji-###”が実体で“koseki-#####0”や“juki-####”がエイリアスのほうが分かりやすいというのが私が上記の意見を書いた主な理由です。特に住基ネット統一文字(juki-####)は一般人は容易に閲覧できないので実体になっていると部品として利用するときに分かりにくくなります。

    • なお,エイリアスと実体の入れ替え機能は,是非とも早期に実現していただきたいです。

KAGE の肉付けについて(特に縦画起筆)

  • ここで話すべきか分かりませんが、ほかの場所も無いので…。以前から気になっているのですが、縦画起筆(開放形状)の右側に飛び出るウロコはもっと大きくしてはどうでしょうか。二倍か三倍ぐらいに。私の持っている主な明朝体を比べた画像を用意しました。
  • 明朝体エレメント比較
  • 字形デザインの差異も興味深いですが、個々のエレメントに注目して見比べてみると色々と思う所が有るでしょう。特に花園明朝は縦画起筆のウロコが非常に弱々しい事が分ります。遠目には存在に気付かないくらい。これを大きくした方がいいと考える理由は次の通りです。
    • ほかの明朝体で組まれた文章中で、足りない字だけ花園明朝を使う様な場合、エレメントが似ていた方が溶け込み易い。
    • 縦画の接続・開放まで作り分けているグリフウィキにおいて、その違いが縮小した画像でも見分け易い。
    • ウロコを付ける以上、ちゃんとした大きさの方がカッコいい。
    • グリフの編集中、「拡大しているのだ」という事を思い出し易い(実寸の積もりでデザインしてしまわない)。
    • 肉付け処理の改変が恐らく比較的容易。
    • 大した副作用が予想されない。
  • 御検討願います。— sayunu 2011年6月10日(金) 14:37

  • ありがとうございます。検討します。もともとは、これ以上縦画起筆ウロコを大きくすることは直線ポリゴンでは変だ、ということで躊躇していました。試行して調整したいと思います。--kamichi 2011年6月21日(火) 09:04

GlyphWikiにおけるIDS記述ルールについて

IDS記述ルールについて、現状は次のようになっています。

  • 文字要素は無印UCSおよび命名ガイドラインの「その他の文字コード、字典番号」のみとし、地域・変化変形・IVSは使えない
  • 同名IDSの異なる字形を区別するためには「-itaiji-###」を使う

これを次のように変更したいと思います。

  • 文字要素はUCSグリフおよび命名ガイドラインの「その他の文字コード、字典番号」のみとする。UCSグリフは地域指定およびIVSを使うことができる
  • 変化変形、「-itaiji-###」、「-var-###」を利用できる。これらはすべて全体に対する修飾となり、したがって必ず末尾に位置する

一応運用はこの通り開始するとし、異論や提案があればその都度検討とします。--kamichi 2011年2月28日(月) 09:29

  • 再検討していいでしょうか?まず大前提として全体にかかる記述である「var,itaiji」および「偏化変形」は使えないものとします。次に使える候補としてIVS、地域指定、CDP、CDP以外のその他の接尾辞によるグリフ、です。困るのは区切りが機械的に判別できない記述は望ましくないということです。--kamichi 2012年12月4日(火) 08:56

命名するときのローマ字表記について

グリフウィキでは、普通にはヘボン式ローマ字を使っていますけど、たまに訓令式や日本式ローマ字も見えます。

なので、命名ガイドラインに、「グリフに名前を付けるときには、特別な場合ではなければ、必ずヘボン式ローマ字を使うべきだ」という事項を追加すればいいと思います。この人はヘボン式を使ったり、あの人は訓令式を使ったりして混乱が生えればダメだと思います。

訓令式や日本式は発音にも合わず、事実上よく使われていません。(誰が「ti」を「チ」と読みますか。tiが「チ」なら、「ティ」は?) 訓令式や日本式は日本語の文法や音韻を教えるときにはいいかもしれませんけど、グリフウィキはそんな場所ではないので、訓令式や日本式を使う理由は全然ないと思います。--johotogoshinentai 2010年12月30日(木) 02:27

  • いくつかコメントがありますが、結論から言うと、複数の方々の共通の認識が確立される前に「削除」や「移動」するのはちょっと問題があります。
    • まず、今回johotogoshinentaiさんが更新されたkikko関係のグリフは正式なグリフとして管理をしているものではありません。1つの参考として「命名ガイドライン」に載っていないものは私的なグリフと考えてください。つまり、その命名で使いたい人がいる、ということで、その命名を尊重してください。
    • 2つめに、確かにヘボン式ローマ字が事実上の標準ですが、一部の方々や組織ではヘボン式以外のローマ字を使っています。これは一種の文化ですので、尊重する必要があります。
      • 日本語は良い意味でも悪い意味でも正書法が定義されていない言語だと私は認識しています。
    • 3つめ、あまり関係ないですが、私は文字を打つ時は「ち」を「ti」で打ちます。「てぃ」は「thi」です。これはIMEに私が合わせていることになりますが、このことによりそれほど違和感は感じません。もちろん「ち」をローマ字で書くときは「chi」です。

ということで今回の件、移動してしまったグリフについては、もともとの作成者のご意向に委ねたいと思います。基本的にグリフウィキは「登録した人のニーズに合わせる」ポリシーですので他の方が強制的に変更するというのは望ましくありません。ご理解をよろしくお願いします。(下に続く)--以上はkamichi 2010年12月30日(木) 12:21

4つめ

本来はこの話とは切り離して考えるべきですが、このように私的なグリフの命名を勝手気ままに認めると、ユーザーが増えた時に混乱すると思います。その意味でjohotogoshinentaiさんのご指摘は正しいと思います。グリフウィキの設計をするときはとにかく「自由」を前面に考えていたのでこのような「ルール無し」となりました。現状では命名ガイドラインに沿っていないグリフは少ないので、ルールを変更するのであれば今がチャンスかなとは思います。私が考えているルールは次のようなものです。

  • 命名ガイドラインに載っていない命名は認めない
    • ユーザー占有グリフ(kamichi_****)として作る分はルール無し
  • まとまった集合については、命名ガイドラインへの追加申請を認める。申請時にはその集合の概要を説明する必要がある--以上kamichi 2010年12月30日(木) 12:22

    • 自由な命名ができなくなってしまうとtokyo23city-04-shinjukufukuoka-ward-02-hakataが使えなくなるので困ります。私は今後も少しずつ組み文字を作成しようと思っているのですが,組み文字を“kumimoji-u####-u####-u####”のまま扱うのは非常に厄介なのでエイリアス名を付けています。占有グリフにしないのは,他の方が利用できるようにと考えてのことです。もし自由命名が禁止された場合,組み文字の管理が厄介になりそうですね。組み文字はグリフウィキの本来の目的ではないので,やむを得ないのかもしれませんが… --spinda-kkmr 2010年12月30日(木) 18:54
    • 追記。もし自由命名が禁止された場合,ouichizaのように,どの文字コードでもコード化されていない文字はどのように扱うのでしょうか? --spinda-kkmr 2010年12月30日(木) 19:10

  • ご意見ありがとうございます。おそらく、「グリフ」の自由命名に制限ができる代わりに、集合を冠した自由命名(定義)で対処することになると思います。できれば接頭辞に限定したいところではありますが、たとえば「tokyo23city-」は東京23区向けの命名、といった感じです。大きな制限をかけるというよりも、必ず何かの集合の一部にしてもらうというやり方を考えています。ouichizaはいろいろ考えられますが「画数の多い漢字」など考えられると思います。これらの集合は命名ガイドラインというよりも「集合リスト」というグループページに記述していく感じです。以上いかがでしょうか。--kamichi 2010年12月30日(木) 19:55

    • つまり,「無秩序に命名することは禁止するが,各自で一定の接頭辞を作ってそれを使う事は許容する」ということでしょうか? --spinda-kkmr 2010年12月30日(木) 20:31

    • はい、「無秩序に命名することは禁止する」、「各自で一定の接頭辞を作り、その意味を記述する。問題があれば事後審議」というのが大枠です。--kamichi 2010年12月30日(木) 21:47

    • ただし、今先にやるべきことがいろいろあるので、すぐに試行(施行)というわけではありません。3月末までの間にこれも含めて進めたいと考えます。この制限自体の是非も含めてご意見お願いします。--kamichi 2010年12月30日(木) 21:47

  • 少し議題とずれますが、僕が前から気に成つてた事に、「先に命名したもん勝ち」と言ふものが有ります。此僕の所謂命名の先取性と自由命名性との組合せから考へられる主な弊害は、例へば、tokyo23city-04-shinjukuと云ふ符号は、既に「新宿」が左、右の順に並んでゐるので、

    • 【一】「新宿」を縦に並べたい人がゐても、別の命名を考へねばならない。

    • 【二】「新」の字形をu65b0-var-001にしたい人がゐても、別の命名を考へねばならない。

    • 【三】tokyo23city-04-shinjukuで「文京」を組んだり、sandbox@537taitoと命名したりする事も出来るし、誰かに然うされた場合、誰も其符号は嬲られないので、変であると思つても直されず、残続ける。

  • と云ふ者が有るかと思ひますが、此の点に就て皆さんは何う考へて御出ででせうか。――lizard 2010年12月30日(木) 23:11

  • ある意味「厚かましさ」に依存しますが、グリフウィキは「先取」とは言い切れないと思います。つまり後から登録しなおしたもの勝ち、ということです。また、バージョン番号を併記することで共存も可能と考えます。結局本件は突き詰めると問題の対象が「グリフ名」から「接尾語」に移るだけではあります。ただ、ある種の集合に属する、というメタ情報的な要素が1つ増えるだけでも運用しやすいのではないかと思います。みなさんいかがお考えでしょうか。--kamichi 2010年12月30日(木) 23:37

  • まづローマ字について、私は日本式に似た規則を普段使っていて、チは「ti」です。(ちなみにティは「tĕi」です。)ローマ字は「表音記号」ではないし、johotogoshinentai さんはラテン文字の言語を英語しか知らないんぢゃないですか ? 言語学の論文などでは日本式の様な表記(音韻表記)を取る事が多いですから、それに近接した学術的文脈に在るグリフウィキでそれを用いるのも無理は無いです。
  • 全く自由な命名は私も問題が有ると思っていました。実際、ガイドラインに沿わない命名のグリフが匿名利用者によって一個や二個作られても、意図が不明というのも有って削除されていたし。定義された接頭辞が必ず付いて、名前空間が限られる様になると扱い易いでしょう。
  • 接頭辞を定義する際に或る程度は慎重さが必要だろうと思います。その下位の命名規則も決めるべきでしょう。「tokyo23city-」だったら、縦書きも横書きもこの下位に置けると定義した上で、例えば縦書きは「tokyo23city-04-shinjuku-ttb」とするとか。(「ttb」は「top to bottom」の略で、「ltr」や「rtl」と共に CSS なんかで使われる表現です。)
  • そもそもその地名の組文字を何に使う為に作ってるのか不明なのであまり踏み込めませんが、地名の組文字を表す上位の接頭辞を定義したらどうです ? ついでながら、東京 23 区なら「city」より「ward」では ? — sayunu 2010年12月31日(金) 17:51
    • tokyo23city-04-shinjukufukuoka-ward-02-hakata等を作成した本人からの提案ですが,自治体名・区名の組み文字のエイリアス名を“autonomy-#####-xxx…”とするのはどうでしょうか(実体グリフは必ず“kumimoji-…”を用いる)。#####にはJIS X 0402で定められる5桁の市町村コード,xxx…には自治体名・区名をローマ字で入れる,というのはどうでしょうか? 例えば“autonomy-13104-shinjuku”,“autonomy-40132-hakata”などとなります。これで複数の接頭辞を1つにまとめられると思います。縦書き・横書きについては,横書きをデフォルトとし,縦書きは末尾に“-vert”を付ける,などが考えられます。
    • また,極端な意見かもしれませんが,組み文字は面倒でも“kumimoji-…”を使った名称でのみ管理する,という方法もあるかもしれません。組み文字はグリフウィキの本来の目的ではないと私も考えているので,これも1つの案として検討する必要があるかもしれません。
    • なお,私が東京特別区に“ward”ではなく“city”を用いたのは,東京特別区自身が「区」の訳語として“city”を用いているためです。
    • 組み文字とは関係ありませんが,自由命名はouichiza等の,文字コードを割り当てられていない文字に限る,というのはどうでしょうか。
    • 以上,--spinda-kkmr 2010年12月31日(金) 19:13
  • 取り消し線で抹消した部分の提案を撤回いたします。申し訳ありません。
  • 私が作成したグリフのせいで皆様に迷惑をかけているようなので,“tokyo23city-…”をはじめとする区名組み文字のエイリアス名は,2011年2月末をメドにすべて削除(白紙化)します。今後は“kumimoji-…”を直接扱います。
  • 以上,--spinda-kkmr 2011年1月1日(土) 19:16

  • 政令組文字グリフについてですが、全く迷惑でありませんので白紙化については再考をお願いします。この件はやや私が性急に過ぎた感がありますので、もう少しじっくり考える、また、あまり縛りをかけずに少しずつルールを決めていくという感じで進めたいと思います。--kamichi 2011年1月1日(土) 20:01
  • これまでの議論に出たように、縦に並べるか横に並べるか、それ以外か、などの情報はあるといいと思います。おそらくフォントの文化からして基本的には横なので、縦の場合にvertに相当する情報を名前に入れるのが妥当と思います。横は冗長なので情報なしでいいのではないでしょうか。あと長くなるので組文字のIDS化は私は好ましくないと思っています。--kamichi 2011年1月1日(土) 20:01
    • 了解しました。白紙化については再考いたします。もう少し議論が深まるのを待とうと思います。--spinda-kkmr 2011年1月1日(土) 20:12

既存グリフの字体の変更について(匿名ユーザー・登録ユーザー)

  • 今般、既存グリフの字体の変更が多々行われ、字体に関する議論および移行が進んでいない中で、もったいない状況にあると思います。登録ユーザーの場合は利用者-会話ページで呼びかけることができますが、匿名の場合、リバートした際のサマリーに書くのがせいぜいです。(つづく)
  • かといってシステム側で制限するのは本意ではありません。しかしいくらか制限を設けるべきなのかもしれません。この議論はすでに提議されていて、私は「トラブルドリブン」と書きました。今がその段階のような気がします。(つづく)
  • 原因となるUCS符号位置の抽象性を排除する作業を急ぐという考え方もあると思います。再度のお願いになりますが、皆様のご意見をいただきたく思います。(つづく)
  • たとえば「匿名ユーザー、登録ユーザーに対する機能制限(機能削除)を設けるべきか」「UCS符号位置グリフの抽象性の排除に関して、すぐに実行できそうな対処法」あたりについてコメントがあればお書きください。--kamichi 2010年10月24日(日) 10:10
    • エイリアスグリフのエイリアス対象のデータ更新時の扱いも議論すべきかもしれません。--kamichi 2010年10月24日(日) 10:20
  • 「勿体無い」と云ふのは、小生も同感です。エイリアスの実体となつてゐるグリフを更新した際に、「以下のグリフで参照先となつてゐますが、同時に更新しますか」の様な文言と選択肢が出て、「○×は更新」「一括更新」をチェックすると選択した者が更新、「更新しない」を選択するとエイリアスは旧版を参照し続ける(或いは旧版の自動的な実体化が成される)と云ふのが有ると当面は便利であると存じます。或いは投稿前の画面に「字形を変更」と云ふチェックボックスを設け、エイリアス実体グリフの編輯を投稿する際に此にチェックすると、自動的にエイリアス先の更新はしない(或いは実体更新前版の自動実体化が成される)と云ふ機能が当面は便利であると存じます。―lizard 2010年10月24日(日) 13:25
  • 匿名利用者に既存のグリフを大量に書き換えられてしまうのは違和感を感じます。UCS符号位置の字形の方針が固まるまでは,「部品グリフを別のグリフに置き換える」機能の匿名利用者に対する利用制限を設けることもやむを得ないと考えます。この機能は大量のグリフを一括で変更してしまうので,影響が大き過ぎます。--spinda-kkmr 2010年10月26日(火) 19:07

「縦払い」ストロークで3つの点が並ぶ現状について

縦払いストロークは、初めの3つの点が1直線に並ばないとポリゴンが切れる不具合があります。この解決方法として

(1)常に1直線になるように固定する(2点目のX座標は無視する) (2)直線部分と曲線部分が切れないようにする(直線部分の末端に丸ポリゴンを置く)

の2つがあると思いますが、デザイン上(1)の1直線に「ならない」ケースは存在するでしょうか?するのであれば(2)にすべきですし、存在しないなら(1)にしたいと思います。--kamichi 2010年8月9日(月) 22:39