GlyphWiki logo
導航
幫助
搜索

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

GlyphWiki-討論:命名ガイドライン

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

GL領域の番号について

「GL領域の番号」は10進と16進のどちらで記述すればいいのでしょうか。とりあえず10進と仮定してページを作ってみましたが。--emk 2008年8月6日(水) 04:09

本文末尾に一応記述してあるとおり、16進数表記です。これは将来的に連携を想定しているCHISEプロジェクトの文字データベースの実体参照表記に合わせてあります(本当は面倒なので単純に面区点を10進数で書けると楽なのかもしれませんが)。--kamichi 2008年8月6日(水) 08:36

ただ、同じ本文に書いてあるようにJIS規格票字形についてはより下にあるものを想定している、つまり、emkさんが用意されようとした2004字形こそが、実はUCS符号位置の名前のグリフで実装すべき字形で、現在すでに登録されているグリフの方を「古いもの」として移す必要があります。したがって「jx1-2000-GL番号」というような命名形式を追加することになります。--kamichi 2008年8月6日(水) 08:36

ご指摘に従って修正しました。ページのソースは変換表からプログラムで自動生成しているので、面倒さについてはまったく問題ありません。--emk 2008年8月6日(水) 20:20

IDS による命名における itaiji と var の使用について

  • ああ、改めて読むと、itaiji と var の使い分けがいかにも書き足した感じになってますね。この「異体字」の節の記述が影響しているのは、Unicode 符号位置についての
    • 上記以外の任意の異体字は、対象となるUCSコードに接頭辞"-itaiji-"を加え
  • と、IDS についての
    • このことにより同じIDS記述で異なるグリフを登録したい場合は、当面「-itaiji」を利用してください
  • の二箇所であって、使い分けは Unicode 符号位置(単独)に限らないと思っているんですが、その理解でいいでしょうか ? それでよければ、今度時間の有る時にちょっと構成を書き換ようかと思います。— sayunu 2011年10月16日(日) 03:04

中華字海の命名方法

作業をしていて思ったのですが、現在の「部首」-「部首内画数」-「連番」方式だと、画数が明記されていない漢字が多くあり、グリフ名から該当する文字(辞書側)を探すことが非常に困難・煩雑です。その他の理由(参照できるデータベースがあるため、そちらに合わせたい)により、「ページ番号4ケタ」-「ページ内番号2ケタ」に移行・併存させてください。重点入力対象にしようと思っています。--kamichi 2011年11月12日(土) 23:41

  • 私は誤字を修正しただけで,追加したわけではありませんが,議論が済んでいないということで,とりあえず削除しておきました。--spinda-kkmr 2011年11月13日(日) 12:33

  • 中華字海の命名ですが、「ページ番号4ケタ」-「ページ内番号2ケタ」へ変更したグリフ一覧を作成致しました。また、旧番号の文字移行も今後順次行いたいと思います。---kamiyo 2011年11月14日(月) 04:27
    • ありがとうございます。それで…、もう一点あるのですが、〔 〕内の文字について、理屈では別で親字として項目があるはずなので、通し番号に入れなくていいかなと思います。というのは、参考にしようとしているWebサイト「http://yedict.com 」ではカウントしていないので、それに合わせたいというのが本音です。このサイトの情報を利用するとUCSとしてマッピングできる文字とUCS外(あるいは異体)の文字を判別できるので、UCS外を埋めていく作業にちょうど良いと思っています。いかがでしょうか。

    • ご連絡有難う御座います。「http://yedict.com 」という便利なサイトが有るんですね。〔〕内は私も重複しているのでどうしようかと迷いましたが、「〔〕内の文字は無視する」旨、字表:中華字海に記述しておきました。(「http://yedict.com 」と番号を合わせたほうがミスも減り、作業効率も上がりますね。)また、私の方もUCS外を埋めていく際に使用して戴ければ嬉しいです。---kamiyo 2011年11月14日(月) 13:05
      • ありがとうございます。最後の一文について文意が不明ですが、どういうことでしょうか?(もし必要でしたら、直接上地までメールをいただけませんでしょうか)--kamichi 2011年11月14日(月) 13:27
      • とりあえず、1700ページ以降から、UCS外文字を埋めていく作業を始めてみます。--kamichi 2011年11月14日(月) 13:27
    • ご連絡有難う御座います。すみません、読み返しましたら当方の勘違いでしたので、スルーして戴ければ幸いです。(ややこしい文面になり申し訳ないです…)---kamiyo 2011年11月14日(月) 16:46

行政系文字コードと汎用電子IVSの字形について

数日前から、IVDのチャートに載っている平成明朝体を手本に登記統一文字の作成を始めました。今までよく認識していなかったのですが、汎用電子情報交換環境整備プログラム成果報告書別冊 を見たところ、登記統一文字・戸籍統一文字・住基ネット統一文字のオリジナルグリフと汎用電子の平成明朝体グリフとの間に、字形の差異がぽつぽつあることに気づきました。 この場合、toki-, koseki-, juki- はそれぞれのオリジナルのグリフを再現し、IVS(uXXXX-ue01XX)は汎用電子の平成明朝体グリフを再現する、という方針でいいんでしょうか。--mashabow 2012年3月25日(日) 03:59

  • 「toki-, koseki-, juki- はそれぞれのオリジナルのグリフを再現」でよいと思います。IVSの方は、UnicodeのIVDチャートのグリフが最終的なグリフになると思います(問題があるグリフも指摘されていますが、それはその都度検討ということで)。新規登録分については現在機械的にオリジナル→IVSのエイリアスを張っていますが、字形の差異がある分についてはエイリアスを外して分離することになります。よろしくお願いします。--kamichi 2012年3月25日(日) 09:14

    • ありがとうございます。了解です。わたしが作成した分については修正しておきました。--mashabow 2012年3月26日(月) 00:10

-kpの廃止を提案します

以下の理由で、-kpの廃止を提案します。
  • KPソースのグリフは、UnicodeやISO/IEC 10646のPDFファイルに提示されていなく、将来に提示される可能性も低い
  • 北朝鮮は、UnicodeやISO/IEC 10646の活動に(ほとんど)参加していない
  • グリフウィキにも、-kpグリフは1つも登録されていない
  • 以上、--johotogoshinentai 2012年12月1日(土) 12:28

  • 賛成です。今後kpソースが出てきた時点で復活を検討すれば良いと思います。--kamichi 2012年12月1日(土) 14:39

  • 将来的に政策変更で漢字文献を扱うこともあり得なくはないと思うので、予約扱いにしました。--kamichi 2013年1月1日(火) 16:53

  • KPの出典として,http://www.itscj.ipsj.or.jp/ISO-IR/202.pdf が考えられますがいかがでしょうか? 「一般社団法人 情報処理学会 情報規格調査会」ということで,出典としての信憑性についても十分であると思われます。nan-saram 2013年5月30日(木) 23:03

    • “-kp”はあくまでも「ISO/IEC 10646規格票のKPソース」ですので,KPS 9566の規格票を出典として作成するならば,新たに「KPS 9566規格票字形」の命名が必要になると思います。--spinda-kkmr 2013年6月15日(土) 11:54

    • まとめますと、10646規格票のKPソース字形を元にグリフを登録したい方がいらっしゃれば「-kp」ソースの復活を、KPS 9566の規格票字形としてグリフを登録したい方は、別の命名(「kp0-####」でしょうか)を、ということになると思います。いずれも希望者がいらっしゃるのでしたら反対ではありません。--kamichi 2013年6月15日(土) 12:02

  • Ext.CのU2A700.pdfを眺めていたらkpグリフがありました。匿名利用者 2016年10月26日(水) 17:12
    • ご指摘ありがとうございます。現状では、kpグリフ(Ext.CのKP1-####)で他と区別すべき字形は無いと思われるので、あえてkpグリフを作成する必要はないと考えますが、必要だと考えたユーザーが作成することは構わないと思いますし、現状の認識では「データが存在しないが廃止ではなく、予約状態」と思っています。--kamichi 2016年10月27日(木) 11:01

ISO規格票における“UCS2003”グリフについて

私は現在,ISO/IEC 10646:2012 (E)規格票(ExtB)における“UCS2003”と表記されたグリフについて,“u2####-us”という命名を行っていますが,これは問題ないでしょうか。--spinda-kkmr 2012年12月9日(日) 11:26

  • 「-us」は一応Unicode標準のリスト上の字形を指しているので、バッティングしていると思います。「-u」「-i」「-us」を明確に定義した方がいいですね。数が多くない場合、あまり細かくしすぎるのもいやですが。--kamichi 2013年1月1日(火) 16:42

  • では,“UCS2003”グリフに対しては,“-i”と“-us”のどちらを用いるべき(あるいは新たな接尾語が必要?)でしょうか。--spinda-kkmr 2013年1月1日(火) 19:34

  • 以下の通り(当初の通り)としたいと思います。

-usUnicode標準の過去の1欄表記における出典不明の字形
-iISO/IEC 10646:2003(2011も同じ)のSIPの1欄表記の字形、および2012における「UCS2003」
-uISO/IEC 10646における「U source」

ということで、「-us」に「-i」が混ざっちゃっています。分離(再登録)は機械的にしたいと思いますが、どうやって分別すればいいでしょうか?なにか条件付けできるでしょうか?--kamichi 2013年1月1日(火) 20:17

  • 私が作成した“-us”グリフは「UCS2003」グリフですので,“-i”に移動できると思います。kamiyoさんが登録している“-us”グリフもおそらく同様だと思います。過去に作成された“-us”グリフは一つ一つ確認するしかなさそうです。--spinda-kkmr 2013年1月1日(火) 20:29

  • 了解しました。まずは一覧を出してみます。--2013年1月1日(火) 20:31
    • この一覧に残るものについて「-i」への複製を行います。--kamichi 2013年1月1日(火) 20:41

「-i」に移行

未確認

u20851-us	----
u27c0c-us	----
u20876-us	----
u21bce-us	daekyo
u207e3-us	johotogoshinentai
u20808-us	johotogoshinentai
u208af-us	johotogoshinentai
u208ef-us	johotogoshinentai
u20905-us	johotogoshinentai
u27d34-us	johotogoshinentai
u28488-us	johotogoshinentai
u2000d-us	kamiyo
u20082-us	kamiyo
u20098-us	kamiyo
u200b9-us	kamiyo
u200cf-us	kamiyo
u200fd-us	kamiyo
u20158-us	kamiyo
u203c1-us	kamiyo
u20544-us	kamiyo
u207c2-us	kamiyo
u209b5-us	kamiyo
u20adf-us	kamiyo
u20ae4-us	kamiyo
u20afd-us	kamiyo
u20b0b-us	kamiyo
u20b23-us	kamiyo
u20bd2-us	kamiyo
u20dce-us	kamiyo
u211be-us	kamiyo
u211cb-us	kamiyo
u2153d-us	kamiyo
u21624-us	kamiyo
u219bf-us	kamiyo
u219f1-us	kamiyo
u21a0b-us	kamiyo
u21a3c-us	kamiyo
u21b55-us	kamiyo
u21bc7-us	kamiyo
u21c21-us	kamiyo
u21c22-us	kamiyo
u21d65-us	kamiyo
u21d6b-us	kamiyo
u21e51-us	kamiyo
u22045-us	kamiyo
u221c1-us	kamiyo
u221db-us	kamiyo
u22350-us	kamiyo
u223d8-us	kamiyo
u223da-us	kamiyo
u223fb-us	kamiyo
u223fd-us	kamiyo
u22a24-us	kamiyo
u22b9f-us	kamiyo
u23205-us	kamiyo
u23249-us	kamiyo
u238f4-us	kamiyo
u239b6-us	kamiyo
u23c73-us	kamiyo
u23cad-us	kamiyo
u23dac-us	kamiyo
u2406b-us	kamiyo
u240fc-us	kamiyo
u243ce-us	kamiyo
u24570-us	kamiyo
u2521c-us	kamiyo
u2521e-us	kamiyo
u2524c-us	kamiyo
u25292-us	kamiyo
u2554a-us	kamiyo
u2592b-us	kamiyo
u25ed7-us	kamiyo
u25efe-us	kamiyo
u25f2c-us	kamiyo
u260a5-us	kamiyo
u26100-us	kamiyo
u263a7-us	kamiyo
u267c0-us	kamiyo
u268f9-us	kamiyo
u26936-us	kamiyo
u2693a-us	kamiyo
u26b63-us	kamiyo
u26cb8-us	kamiyo
u278da-us	kamiyo
u278fd-us	kamiyo
u2794a-us	kamiyo
u27c32-us	kamiyo
u27cd3-us	kamiyo
u2871e-us	kamiyo
u28794-us	kamiyo
u28e37-us	kamiyo
u29c8f-us	kamiyo
u29c9c-us	kamiyo
u200fc-us	mandel59
u2524f-us	nkay
u20b55-us	pyrite
u29fce-us	sayunu
u206d9-us	spinda-kkmr
u216b1-us	spinda-kkmr
u21c5d-us	spinda-kkmr
u22857-us	spinda-kkmr
u22a8b-us	spinda-kkmr
u22b08-us	spinda-kkmr
u262c4-us	spinda-kkmr
u262da-us	spinda-kkmr
u2634f-us	spinda-kkmr
u2638d-us	spinda-kkmr
u263ad-us	spinda-kkmr
u263e6-us	spinda-kkmr
u264f0-us	spinda-kkmr
u26508-us	spinda-kkmr
u278b7-us	spinda-kkmr
u278b8-us	spinda-kkmr
u278d2-us	spinda-kkmr
u278e4-us	spinda-kkmr
u278ec-us	spinda-kkmr
u27904-us	spinda-kkmr
u27911-us	spinda-kkmr
u27926-us	spinda-kkmr
u27927-us	spinda-kkmr
u2792b-us	spinda-kkmr
u2792e-us	spinda-kkmr
u27930-us	spinda-kkmr
u27940-us	spinda-kkmr
u27942-us	spinda-kkmr
u27959-us	spinda-kkmr
u2795a-us	spinda-kkmr
u27bad-us	spinda-kkmr
u27bb2-us	spinda-kkmr
u27bc1-us	spinda-kkmr
u27bc2-us	spinda-kkmr
u27bcf-us	spinda-kkmr
u27bda-us	spinda-kkmr
u27bdc-us	spinda-kkmr
u27be1-us	spinda-kkmr
u27be5-us	spinda-kkmr
u27be6-us	spinda-kkmr
u27bf3-us	spinda-kkmr
u27d25-us	spinda-kkmr
u27d2d-us	spinda-kkmr
u27d36-us	spinda-kkmr
u27d37-us	spinda-kkmr
u27d39-us	spinda-kkmr
u27d4e-us	spinda-kkmr
u27d5c-us	spinda-kkmr
u27d5e-us	spinda-kkmr
u27d60-us	spinda-kkmr
u27d62-us	spinda-kkmr
u27d69-us	spinda-kkmr
u27d6a-us	spinda-kkmr
u27d6b-us	spinda-kkmr
u27d6f-us	spinda-kkmr
u27d70-us	spinda-kkmr
u27d72-us	spinda-kkmr
u27d7d-us	spinda-kkmr
u27d7e-us	spinda-kkmr
u27d7f-us	spinda-kkmr
u27d82-us	spinda-kkmr
u27d8c-us	spinda-kkmr
u27d9d-us	spinda-kkmr
u27daa-us	spinda-kkmr
u27db9-us	spinda-kkmr
u27dbb-us	spinda-kkmr
u27dc4-us	spinda-kkmr
u27dc7-us	spinda-kkmr
u27dc9-us	spinda-kkmr
u27dcb-us	spinda-kkmr
u27dcd-us	spinda-kkmr
u27dd2-us	spinda-kkmr
u27dd6-us	spinda-kkmr
u27ddf-us	spinda-kkmr
u27de2-us	spinda-kkmr
u27de7-us	spinda-kkmr
u27df5-us	spinda-kkmr
u27dfb-us	spinda-kkmr
u27dff-us	spinda-kkmr
u27e00-us	spinda-kkmr
u27e0a-us	spinda-kkmr
u27e17-us	spinda-kkmr
u27e25-us	spinda-kkmr
u27e2f-us	spinda-kkmr
u27e48-us	spinda-kkmr
u27e73-us	spinda-kkmr
u27e78-us	spinda-kkmr
u27fb8-us	spinda-kkmr
u27fbb-us	spinda-kkmr
u27fc0-us	spinda-kkmr
u27fee-us	spinda-kkmr
u28022-us	spinda-kkmr
u2807a-us	spinda-kkmr
u280a1-us	spinda-kkmr
u280a2-us	spinda-kkmr
u280a7-us	spinda-kkmr
u280af-us	spinda-kkmr
u280b6-us	spinda-kkmr
u280e8-us	spinda-kkmr
u28dfe-us	spinda-kkmr
u2907f-us	spinda-kkmr
u2a6a5-us	spinda-kkmr
u200d2-us	tomomo
u21dc8-us	tomomo
u26445-us	tomomo
u20525-us	uchi
u206ec-us	uchi
u208d0-us	uchi

「-us」のまま

u6db3-us	----
u301c-us	johotogoshinentai
u5794-us	johotogoshinentai
u7ac4-us	johotogoshinentai
u95ea-us	johotogoshinentai
u3515-us	kamiyo
u4c7b-us	kamiyo
u5867-us	kamiyo
u671b-us	kamiyo
u7bdb-us	kamiyo
u60b2-us	nkay
u51ad-us	pyrite
u5829-us	pyrite
u6452-us	pyrite
u3c06-us	sayunu
u7506-us	sayunu
u52fd-us	tomomo
u6dd4-us	tomomo
u76f4-us	tomomo
u6d99-us	twe
u5017-us	twex
u876b-us	twex

「-joyo」の提案

安岡先生のをこのPDFファイル 見ると、2010年の常用漢字表の字形の中、JISの例示字形やIVSで表現できない文字があるようです。ということで、「-joyo」という接尾語を提案したいと思います。たとえば、「摂」の常用漢字表の字形(= u6442-var-001)は、u6442-joyoになるのです。これはいかがでしょうか。 --johotogoshinentai 2013年3月20日(水) 15:45
  • 私の考えでは賛成できません。“-var-”を用いて命名したうえで,メタ情報に記述する,常用漢字表のグループに引用するといった形で十分だと思います。--spinda-kkmr 2013年3月20日(水) 16:03
  • 私も、UCSに接尾辞を増やしたくないと思うので、逆に「joyo-u(UCS-HEX)」を提案します。もう少しメタ情報(バグ除去に未着手で申し訳ありません)が本格的に使えるようになれば、それで十分とも思います。--kamichi
  • ここで書かれている意図は,字表:常用漢字-字形にてjmjグリフを使ってできましたので,joyoグリフは必要ないかと思います。 --ziyang 2016年12月26日(月) 05:21

康熙字典グリフの命名について

康熙字典のグリフの命名は“kx-ppppnn”(ppppはページ番号,nnはページ内番号)となっていますが,これはUnicodeUnihanDatabase のkIRGKangXiの値から末尾の0を取ったものと解釈してよいのでしょうか? --spinda-kkmr 2013年6月10日(月) 20:36
  • そうなると認識しています。--kamichi 2013年6月15日(土) 11:57

「IDSによる記述」の凡例について

「IDSによる記述」の凡例を以下のように追記する事を提案したく思います。
※説明文の文言追加と、例の「可」「不可」の追加、例2の追加。
太字が追記箇所です。

↓↓↓↓↓以下現状↓↓↓↓↓
IDSの記述に使う部品は素の符号位置としてください。「-02」「-g」などの情報はつけないでください。このことにより同じIDS記述で異なるグリフを登録したい場合は、当面「-itaiji」を利用してください。

 不可:u2ff0-u53e3-01-u6606-02
 可:u2ff0-u53e3-u6606
 可:u2ff0-u53e3-u6606-itaiji-001
↑↑↑↑↑↑ここまで↑↑↑↑↑↑

↓↓↓↓↓以下追加修正後↓↓↓↓↓
IDSの記述に使う部品は素の符号位置としてください。「-02」「-g」などの情報はつけないでください。このことにより同じIDS記述で異なるグリフを登録したい場合は、当面「-itaiji」「-var」を利用してください。

 不可:u2ff0-u53e3-01-u6606-02
不可:u2ff0-u53e3-u6606-g
 可:u2ff0-u53e3-u6606
 可:u2ff0-u53e3-u6606-itaiji-001
可:u2ff0-u53e3-u6606-var-001

例2:u2ffa-ufa66-cdp-857e (⿺辶〓)

不可:u2ffa-ufa66-cdp-857e-02
可:u2ffa-ufa66-cdp-857e
可:u2ffa-ufa66-cdp-857e-itaiji-001
可:u2ffa-ufa66-cdp-857e-var-001
↑↑↑↑↑↑ ここまで ↑↑↑↑↑↑

理由としまして、私自身つい数ヶ月前迄、凡例及び説明文に「-var」「cdp-####」の説明が無かった為、IDSに「-var-###」や「cdp-####」を使用出来無いと思い込んでおり、「-itaiji」の乱用や「cdp-####」を使用しない長いIDS名称を命名おりました。
※各所のノート等を見てみると「-var-###」や「cdp-####」が使用出来る事が判明。
よって、今後の未然防止の意味も込めまして追記を提案したく思います。--kamiyo 2013年7月23日(火) 12:27

  • ご提案ありがとうございます。賛成です。ただ、正直なところ、以下の事項については迷いがあります。ですので、考え方としては「少なくとも「地域」「偏化変形」の付与は認めない」というのが現状と認識しています。
    • UCSコード以外を許していいのか
    • 互換漢字や部首などの使用を許していいのか

IDSの命名について

もしよろしければ以下のようなルールにしてもらえれば有難いと思いました。

  • IDSで構成される漢字字形のうち、中国・台湾等に特有な字体を使うものは、IDS-g, t のように「地域」コードを付与することを許容して欲しい。古壮字等で作成されている多くのIDSグリフは中国特有の部品を使っており、それらとは別に仮想J的なIDSグリフを作れるようにするため。
  • IDSで構成された漢字グリフを部品化する場合は、-01, -02 等の「偏化変形」コードを付けられるようにして欲しい。(特にそうしてはまずい理由はあるでしょうか?)
  • IDSで構成される漢字を作ろうとするとき、包摂の範囲内で既存の文字とかぶる場合は、IDS-var-001, -var-002 を付与できるようにして欲しい。
  • 逆に、IDS-itaiji-XXX は許さないようにして欲しい。(包摂できない差ならば、できるだけIDSで別表現にして欲しい。)
  • IDS による検索性を高めるため、DC(IDSの部品文字)は極力、漢字またはCDP外字のみにして、特に康煕部首文字(U+2F00-2FD5)を使うのは避けるようにして欲しい。
  • IDS のDCに使える非漢字のリスト(CDP外字を含む)は、特設のページで管理できるようにして欲しい。KDPのIDSデータでは、 "αℓ△⺀⺄⺆⺈⺊⺌⺍⺶⺸⺻⺼〇〢キサ㇀㇉㇢"が使われている。 --golconda 2014年10月7日(火) 21:21

ごもっともな提案で(IDSに地域接尾辞をつける箇所を除き)賛成です。IDSでは例示字形がないので編集合戦の余地があり,地域接尾辞ではなくvarを使うことにして,争いの種は減らしておくのが無難だと思います。 --ziyang 2015年8月16日(日) 00:18

  • 遅くなりましたが、上記ほぼ賛成です。
    • IDS-x[地域コード]の設定 → 反対です。こちらはT、Gなどが明確でない(例えば、左下zh新でもVソース、KPソースや、まれにKソースがあり得るなど)、地域コードはUCSのみ付与したく思います。
    • IDS-##[偏化変形]の設定 → 賛成です。稀に現グリフでも使用している事例がありますが、命名規則にないため作成に躊躇しているので、現状疑問に思いながら「-var」で作成しおります。
    • IDS-var-###[バリエーション]の設定 → 賛成です。命名グリフには存在しませんが、以前議論があり、それ以降当方も命名規則にはありませんが「-var」を積極的に使用しております。
    • IDS-itaiji-###[異体字]の廃止 → 賛成です。以前当方が作成した「-itaiji」は他のIDSに置き換え、または「-var」に置き換え中です。
    • 康煕部首文字(U+2F00-2FD5)使用禁止 → 賛成です。但し、CJKやCDPで表現不可のものは、例えば平仮名やアルファベットu2ffb-u3059-u4e8cなどの表現も可としたいです。
    • 非漢字のリスト特設のページで管理 → 賛成です。特に問題ないと思います。
  • --kamiyo 2015年8月25日(火) 21:16

IDSの命名に関連する議論をGlyphWiki:サンドボックス@148にまとめました。接尾辞の可否について,ガイドラインと最近のユーザーの意見(敬称略)をまとめると以下のようになります。

接尾辞(例)ガイドラインkamiyogolcondaziyangspinda-kkmr
-01×
-g××××
-itaiji-001××××
-var-001×

kamichiさんのご意見は時期によって違うので,まとめに入れていません。喫緊の課題はvarで,varが使われたグリフに対する適切な命名が他に考えられず白紙化できないため,ガイドラインの禁止は有名無実化しています。このため,varを許可し,varを使わない運用の提案があれば議論することにするのが良いと思います。
他の方針転換は議論の余地があるかもしれませんが,「itaijiは可能な限り避ける」ことをガイドラインに加えれば,ほぼ禁止に近い効果があるのではないかと予想します。 --ziyang 2015年8月29日(土) 15:46

  • 私の意見を上記表に追加させていただきました。△は条件付き可です。
    • 偏化変形…条件付き可。そのIDSの偏化変形接尾コード無しの素のグリフが存在する場合に限り作成可。素のグリフが存在しない「無の派生」は好ましくない。
    • 地域コード…不可。地域コードはUnicode由来のものなので,Unicodeコード位置以外には付けるべきではない。
    • “itaiji”…不可。IDSにおける異体字の定義が曖昧。
    • “var”…可。同じIDSでの微妙な字形の違いを表現するのに必要。また,現状で“var”がそのような目的で使われている。
  • 以上,--spinda-kkmr 2016年11月13日(日) 10:16

    • 以下は,誤解がありましたので取り消します。--ziyang 2016年11月23日(水) 20:36 現在の記述が矛盾しているvarは多数意見と実態にしたがい,許容するようにGlyphWiki:グリフを登録するの記述を書き換えました。 --ziyang 2016年11月22日(火) 23:12

「ISO/IEC 10646の規格票について」のリンクについて

「ISO/IEC 10646の規格票について」に書かれているリンク“ http://std。dkuug。dk/jtc1/sc2/wg2/ ”(不用意にアクセスしないようコロンを全角に,半角ピリオドを句点に変更)がウイルス感染していてNortonにブロックされてしまい表示できませんね。--spinda-kkmr 2014年11月30日(日) 11:17

  • 上記,正常化したようです。--spinda-kkmr 2015年8月15日(土) 09:36

地域接尾コードと“-var-”“-itaiji-”について

地域接尾コードと偏化変形の組み合わせは禁止されていますが(「u4e00-g01-var-001は不可」と記述あり),地域接尾コードと異体字“-var-”“-itaiji-”の組み合わせに関しては明記されていません。しかし過去の履歴を見る限りu5165-g-var-001@2(白紙化済み)のような組み合わせは許されていないように思われます。
命名ガイドライン「異体字」の項目に以下の文章を追加することを提案いたします。

  • 「-var-###」「-itaiji-###」と上記の接尾コードは組み合わせないでください(u4e00-g-var-001は不可。u4e00-var-001とする)。

以上,--spinda-kkmr 2015年8月15日(土) 09:36

  • 賛成です。 --ziyang 2015年8月16日(日) 00:18
  • 上記意見賛成です。必要な場合は地域コードを含めない「-var-###」「-itaiji-###」を使用する事で問題ないかと思います。--kamiyo 2015年8月16日(日) 00:26

賛成意見が多いようなので,08/23(日)までに反対意見が無かった場合は,命名ガイドラインに追加させていただきます。--spinda-kkmr 2015年8月19日(水) 20:29

  • 上記,追加いたしました。なお,より分かりやすくするために「上記の接尾コード」を「複数欄指定の接尾コード」に変更して追加いたしました。--spinda-kkmr 2015年8月29日(土) 10:12