GlyphWiki logo
ナビゲーション
ヘルプ
検索

ツールボックス
他の言語
解説ノート編集履歴

GlyphWiki:井戸端-保存

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

以下、保存用です。編集はご遠慮ください。

2009年〜2012年の分についてはGlyphWiki:井戸端-保存2012年までをご覧ください。

2013年〜2014年の分についてはGlyphWiki:井戸端-保存2014年までをご覧ください。

2015年〜2016年の分についてはGlyphWiki:井戸端-保存2016年までをご覧ください。


グリフウィキで共有したい漢字(文字)とは何か

  • もともとグリフウィキはPCで扱えない漢字をインターネット上で共有することを目的としていて具体的には学術性のある文字(文字そのものに、ではなく、扱う分野が)をイメージしていました。過去の字典や文献に出現する漢字、あるいは異体字がターゲットになります。このところ創作漢字やかなり近現代(第二次大戦以降)の用例字が登録されていて、後者は目的としては問題ないと思うのですが、どうしてもサイト維持の点で考えると、登録される文字が思想・主張や字義以上の意味を持っているとどうしても軋轢が生じてしまいます。今グリフウィキで使わせてもらっている固定IPアドレスは所属先から借りているもので、かつ他の用途にも使われています。このため、今後トラブルが起きた際にいろいろな迷惑がかかることを考えると「登録グリフの方針を変更する」あるいは「非力な外部サーバに移設する」などの選択肢を考える必要があると思っています。言論の自由も大事なのですが、もともとの目的は学術のニーズを満たす、ということがベースですので、それを維持することが優先だと思っています。皆様のご意見を頂戴したいと思います。--kamichi 2020年5月10日(日) 11:58

(なお、私が全く理解できない言語を自分の発言として載せることはできないので、申し訳ありませんがハングルへの翻訳はしませんでした)

  • (This is a machine translation. Welcome modifications)
    • What are the kanji we want to share on GlyphWiki
      • Originally, GlyphWiki was aimed at sharing Kanji that could not be handled on a PC on the Internet, and specifically envisioned academic characters (not the characters themselves to be academic, but the field to be handled). The target is the kanji or variant characters that have appeared in past books and literature. Recently, I think that the original Kanji (創作漢字 sosaku-kanji) and the characters used in modern times (since World War II) have been registered, and the latter does not pose a problem for the purpose. If there is more meaning than ideology / assertion or literal meaning, there will be conflict. The fixed IP address that I am currently using at GlyphWiki is borrowed from my office and is also used for other purposes. For this reason, considering that various troubles will occur when trouble occurs in the future, I think that it is necessary to consider options such as "change the registration glyph policy" or "remove to a weak external server". Freedom of speech is also important, but since the original purpose is to meet academic needs, I think maintaining that is a priority. We would like to hear from you.

  • (这是机器翻译。欢迎修改)
    • 我们想在GlyphWiki上分享什么汉字
      • 最初,GlyphWiki旨在共享无法在Internet上的PC上处理的汉字,并且特别设想了学术字符(不是字符本身,而是要处理的领域)。目标是过去书籍和文学中出现的汉字或变体字符。最近,已经注册了艺术汉字(創作漢字 sosaku-kanji)和近代(第二次世界大战之后)的实例,我认为后者并不是目的,但是就维护站点而言,将要注册的字符是不可避免的。如果含义比意识形态/主张或字面意义更多,那就会有冲突。我目前在GlyphWiki上使用的固定IP地址是从我的分支机构借来的,也可用于其他目的。因此,考虑到将来发生故障时会发生各种故障,我认为有必要考虑诸如“更改注册标志符号策略”或“删除到弱外部服务器”之类的选项。 言论自由也很重要,但是由于最初的目的是为了满足学术需要,所以我认为保持言论自由是当务之急。我们希望收到您的来信。

(ここからご意見をお書きください)

  • 今のところの私の意見ですが、少なくとも、現代の政治的な事項であっても造字され、流通した漢字は大事な資産と思いますので、サイトを一般のVPSサーバに移設することを考えています。予算の都合で仮想6コア、メモリ8GB、ですがストレージがSSDですし、ネットワークも今より良い環境になると思います。--kamichi 2020年5月11日(月) 14:01

  • 私見ですが、問題のもとになりそうな一部の(政治的な)字を除けば基本的に放置で良いのではないでしょうか。(いつぞやの草書風字がこれに入るかは知りませんが。)結局、上記の選択肢をとっても荒らしが湧かなくなるわけではないですし、問題のもとになるものが具体的に予想されているわけでもありません。 
 それと、話が変わって申し訳ないのですが、Unicodeのアプデで小書きの仮名も追加されましたし、そろそろ花園フォントの更新をお願いします。    
yoshiciv 2020年7月20日(月) 11:38

  • yoshicivさんありがとうございます。同意です。閉じます。--kamichi 2020年7月22日(水) 09:07

サービスの一部不具合について

  • GlyphWiki:お知らせの「サービスの一時不具合について」ですが,1回目のメンテナンス直後にFirefoxでアクセスできない(httpsで接続できないためと思われる)現象が発生しましたが,すぐに復旧しました。現在でも正常です。--spinda-kkmr 2020年3月25日(水) 18:11

Ext.Gの自動登録について

  • Unicode13は(おそらく)既に安定しています(こちらの資料 によると、既にベータレビューは終了しています)。そのため、可能な限り早くExt.Gを自動登録すべきだと思います。但し、実際には次に挙げるような問題があります。
1グループ:ExtG-finalと実際のExt.G の一致。私はBabelStone Hanフォント との矛盾がないことは確認しました。
2UKソースの命名。-uとするか-ukとするか。
3エイリアス関連の処理。Ext.Fのようにu3XXXXのグリフがirg2015-0XXXXのエイリアスになってしまうことは避けたい。

以上。--kesuuko 2020年1月22日(水) 14:16

    • 議論が進展しないので、ひとまず次のように決定してもよろしいでしょうか。
1sim-chさんによって作成されたデータをもとにグループ:ExtG-finalを修正した為、一致しているものとみなす。
2-ukとする。
3「irg2015-*****のデータをu3****-jvに移す→u3****をu3****-jvのエイリアスとして作成する→irg2015-*****又はそのエイリアス元をu3****-jvのエイリアスにする」を作業内容とする。

以上。--kesuuko 2020年2月21日(金) 19:16

  • 良いと思います。2番は具体的な作業は発生するのでしょうか?--kamichi 2020年2月22日(土) 11:25
    • 追加です。sim-chさん、ありがとうございます。--kamichi 2020年2月22日(土) 11:33
    • 3番の、Ext.Fで起きている問題点を教えていただけないでしょうか。一括で治せるものなら一緒に直してしまいたいです。--kamichi 2020年2月22日(土) 11:33
    • 2番については、特に自動登録に関わる作業は発生しません。但し、「-u」とすると拡張Hの登録時に問題が発生します(https://hc.jsecs.org/irg/ws2017/app/index.php?id=04282 )。また、3番については、現在extf-*****の関連字が〓になってしまっている問題があります。--kesuuko 2020年2月22日(土) 18:56

  • では2番は「-uk」に改めて賛成です。3番ですが、多くの「extf-*****」はExt.F領域グリフのエイリアスなので、関連字は関係ない(エイリアス先に依存)と思うのですが、エイリアス先に依存せず対応するExt.Fの文字を当てるべきというご意見なのか、それとも別に残っている「extf-*****」の関連字に問題があるのかどちらでしょうか?あるいは、そもそもの記述にある「extf-*****」が大本(Ext.F符号位置グリフのエイリアス参照先)になることが問題とお考えの派生でしょうか。こちらについては他の方の意見も欲しいのですが、もし同様にお考えの方が多ければ機械的に直したいと思います。--kamichi 2020年2月23日(日) 10:08
    • 私は、u2****がextf-*****のエイリアスになっていることが問題(Ext.Eまでの慣行に反する)だと考えています。--kesuuko 2020年2月23日(日) 10:17

      • すみません、これは2018年にすでにどなたから提起された際に、私の当時の認識では自動修正はできないという結論でした。それで、今Ext.F領域のグリフデータを確認したところ、462グリフが独自にデザインされて登録されたグリフ、5,116グリフが「extf-*****」以外のエイリアス、1,895グリフが「extf-*****」のエイリアスでした。この最後の1,895グリフについて向きを逆にすればよいという認識で正しいでしょうか?--kamichi 2020年2月23日(日) 10:43
  • (インデント戻る)私の試案を表にします。
独自にデザインされたグリフ(u2****が実体)現状維持
「extf-*****」以外のエイリアス個別検討(u2****-j/jv/gなどのエイリアスは問題ないが、IDSグリフやsawnグリフのエイリアスは修正すべき)
「extf-*****」のエイリアス最低でもエイリアスの入れ替えは行うべき

以上。--kesuuko 2020年2月23日(日) 11:04

  • 現在、「extf-*****」について入れ替え中です。それ以外についてですが、「u2****-j/jv/gなどのエイリアス」を除くと649グリフです。私のノートページにデータを置きますので、ご覧ください。--kamichi 2020年2月23日(日) 11:51
    • 基本的にはエイリアスの入れ替えを行うべきだと思いますが、ユーザー占有グリフのエイリアスになっているものに関しては手作業で修正を行うべきだと思います。--kesuuko 2020年2月25日(火) 10:12

  • 今、irg2015のグリフのデータそのままをu3****-jvに登録しました。次に-jvを無印にエイリアスを貼ろうとしたのですが、たとえばu30020のような関係の場合に、どのグリフがベースで、どれがエイリアスかに悩みます。ひとまず止まっています。--kamichi 2020年2月24日(月) 14:04
    • 一旦そのままエイリアスを貼るべきだと思います。--kesuuko 2020年2月25日(火) 10:12
      • 承知しました。また作業を再開します。--kamichi 2020年3月13日(金) 15:13

  • 今、Ext.Gのすべてのグリフについて自動登録が終わりました。U+30000-U+301EFについては一部矛盾グリフがあるので、適宜直していきます。それで今後irgグリフやIDSグリフについて、整理削除する過程で一括処理ができるものについては言ってください。--kamichi 2020年3月14日(土) 14:05
    • 矛盾(存在するのにサムネイルがない)を解消しました。自動登録は完了です。--kamichi 2020年3月14日(土) 14:24

明朝体以外の花園フォントについて

花園フォントでは、ゴシック体も用意すると聞いたのですが本当ですか? もしそうなら、ゴシック体以外の字体の「花園行書」などを作る予定があるのですか?--yoshiciv 2019年12月29日(日) 19:28

  • 構想段階では、花園フォントはあくまでもニッチなニーズに応えることが目的で、既存のフォント(特に商用)とバッティングしないことを意識していました。このため、最低水準のラインナップとして明朝体、その次はゴシック体、と思っていました。すでに10年以上たちましたが、目論見通りニッチなフォントとしての位置づけとなり、既存フォントとバッティングする心配はなさそうです。ですので、特に書体を制限することは現状では考えていません。同時に、ゴシック体ですら実装に取り掛かる余裕もないのが現状です。明朝体のデータが蓄積されていますので、これを何かしらの変換で他書体にすることもいずれはできるのではないかと思っていますし、みなさまの試作を歓迎します。ゴシック体、やりたいですね…。--kamichi 2020年2月22日(土) 11:31

命名の文字数制限について

グリフ名が60文字を超えた場合意図的に登録できないようですが、100文字ほどに増強は出来ないでしょうか。 IDSの命名において60文字を超えてしまうことが多々あり、そうした場合占有グリフとして登録するしか道がなく不便に感じます。(例として、u2ff1-u2ffb-u2ffa-u5ef4-u2026-u2ffa-u2010e-u56de-u6b6a-u2ff3-cdp-8b62-u4e5d-u516dが登録できないため、n-gtwinppx_keidukaejitomoyasuとして仮登録、u2ff8-u5382-u2ff3-u2ff2-u6709-u6709-u6709-u2ff2-u6709-u6709-u6709-u2ff2-u6709-u6709-u6709が登録できないため、n-gtwinppx_amanohashidateとして仮登録。グリフの典拠は要約にあります。)--n-gtwinppx 2019年12月23日(月) 16:51
  • 私は反対です(少なくとも積極的には賛成できません)。ノート:biangpublicにあるとおり,60文字制限は管理人のkamichiさんがCD-Rに保存する時の制約(Joliet規格)を考えて決めたものです。
  • 60文字を超えるIDSと言うのは滅多にない物なので,そのような場合はグループ:prefix-miscにある“misc-####…”命名を用い,IDSをメタ情報に記入するというのはどうでしょうか。misc-biangを参考にしてください。
  • 今回の場合,前者はmisc-keizukaejitomoyasu,後者はmisc-amanohashidate-itaiji-001(misc-amanohashidateは使用済み)が望ましいと考えます。
  • 以上,--spinda-kkmr 2019年12月23日(月) 17:41
    • 迅速なご意見ありがとうごさいます。spinda-kkmrさんのご意見通りに"misc-####..."の命名で行きたいと思います。さらに、60文字以内でなければならない理由までつぶさに教えてくださり感謝いたします。--n-gtwinppx 2019年12月23日(月) 19:00

「単」の字について

「单」の字を含む地域ソースのない漢字グリフが「単」に変更されています。 例:u5a75, u6b9a, u89ef, u28859 Jソースのある文字に限り「単」の字形を採用すべきだと思いますがどのように考えていますか。
    • prometziu 2019年8月1日(木) 10:53
    • 私は強く反対です。prometziuさんの言っていることはu2c739の艹を四画にしたりu2ce51の左半分を黄にしたりするようなものです。--kesuuko 2019年8月1日(木) 13:52

SATソースの命名について

CJK統合漢字拡張Gでは、u302f6のようにUKソースとSATソースの両方を持つ符号位置が存在します。そのため、SATソースの命名の変更を提案します。
  • 案1:SATソースを-s命名に変更する。
  • 案2:SATソースを-z命名に変更する。
  • 以下にそれぞれの命名の例を挙げます。
現在案1案2説明
u2e014-uu2e014-uu2e014-uUTC、UK、UCIソースのグリフは-uのまま変更しません。
u2ceb7-uu2ceb7-su2ceb7-zSATソースのグリフは命名が変更されます。

以上。--kesuuko 2019年7月26日(金) 14:59

  • 本来、接尾ソース記号は規格票のGTJKVなどのソース欄の例示字形を指すものでした。拡張領域でソースを欄で区別するのではなく、ソースを列挙する形に変わりましたので、意味が変わってきていると思います。このためSATソースに1文字を割り当てるのは変(今後アルファベットが足りなくなって崩壊する)と思います。代案としてUソースのみ「-usat」「-utc」「-uci」に分解するというのはいかがでしょうか。混乱しますかね?--kamichi 2019年7月31日(水) 19:07
    • こちらの資料 ではSATソースはUソースではなくなるようです。いずれにせよ「-usat」は不適切だと思います。--kesuuko 2019年7月31日(水) 19:13
    • ご指摘ありがとうございます。ただ…「-s」「-z」は反対です。誤解を生みかねないので。影響が大きすぎるのでできませんが、拡張領域の1字ソース自体が現状にそぐわないとすら思っています。もう少し議論しませんか。--kamichi 2019年7月31日(水) 21:10
      • こちらの資料 では、SATソースの正式な略称(TやV、Jなど)はSとなるようです。その為私はSATソースの接尾詞は「-s」が良いと思います。--kesuuko 2019年9月10日(火) 22:12
      • 現状では、こちら に挙げた漢字など、UTC/UKソースとSATソースを同時に持つ漢字の命名が困難です。早急に命名を規定することが必要です。私の私案は次の通りです。
ソース名現在私案1私案2
UTCソース-u-u-u
UKソース(-u)-u-uk
UCIソース-u廃止*廃止*
SATソース-u-s-s

 *UCIソースについては、Unicode13.0以降のソースに使わない方針のようです。

以上。--kesuuko 2019年12月21日(土) 10:22

  • 追認という形でよいと思うのですが、まずはSATソースが「-s」ということですね。--kamichi 2019年12月23日(月) 13:29

諸橋大漢和(など)の字書の古い版固有のグリフについて

旧版で存在し、新版で削除・更新されているグリフについて、記録としてグリフ登録できるとよいと思います。接尾辞「-old」あるいは版番号付きの派生などが考えられます。--kamichi 2019年5月22日(水) 14:48

  • よいと思います。このページ によると各版の間で差異があるようなので,接尾辞“-old-AAB”を提案いたします。AAは版番号(初版は00)でBは初版と縮写版を区別するための枝番です。

命名(spinda-kkmr案)
初版(1955年~1960年)dkw-NNNNN-old-001
縮写版(1966年~1968年)dkw-NNNNN-old-002
修訂1版(1984年~1986年)dkw-NNNNN-old-011
修訂2版(1989年~1990年)dkw-NNNNN

  • この命名であればかなり機械的に判定ができるのでよいと考えます。
  • 以上,--spinda-kkmr 2019年6月9日(日) 18:41

ExtGの自動登録について

ExtGの自動登録の際は、irg2015-0****のデータをu3****-jvにコピーして、u3****及びirg2015-0****をu3****-jvのエイリアスにするのが良いのではないでしょうか。なお簡体字特有の字体に関しては利用者が目視で確認します。

その理由としては、

  • 1.ExtGの漢字にJソースを持つ字が存在しないこと
  • 2.現在、UCSグリフの実体を-jvにすることが私を含む複数の利用者によって行われていること
  • 3.未だにExtFのグリフが実体になっていないケースが非常に多いこと
  • などがあります。--kesuuko 2019年4月26日(金) 15:06

右側に付ける合成用文字について

u102cu17c8のように基底文字の右側に付ける合成文字についてですが、1文字分の幅を必要とするため、u0e32のように合成文字ではない扱いにした方が良いのではないでしょうか。--prometziu 2019年4月10日(水) 01:08
  • 賛成です。その方がフォントにした時見映えがいいと思います。--kesuuko 2019年4月22日(月) 22:17

フォント生成について

少し気になったので質問です。ログを見た所、一文字目に「一」が入るのは仕様でしょうか?

仮想J字形の適用対象外について

現在GlyphWiki:仮想J字形のガイドラインでは、Jソースの存在する符号位置及び簡体字特有の部品を含む符号位置のみが仮想J字形の適用対象外とされていますが、今後は戸籍統一文字又は住基統一文字に含まれる文字も仮想J字形の適用対象外とし、戸籍統一文字及び住基統一文字の字形を優先するようにすべきだと思いますが意見をお願いします。字形の統一性が大きく乱れてしまいますが、現在もJソースの存在する符号位置で乱れているので特に問題はないでしょう。尚、戸籍統一文字と住基統一文字で字形が異なる場合は戸籍統一文字を優先させようと思っています。--kesuuko 2018年12月23日(日) 13:04
  • 反対です。
  • 現在の仮想J字形に「筆押さえは八屋根以外は付けない」とありますが,これはノート:u25adcにて管理人のkamichiさんが「JIS X 0213:2004に倣って筆押さえは付けない」という方針を決め,それをGlyphWiki:仮想J字形のガイドラインにてルール化したものです。しかし,戸籍統一文字は大部分が筆押さえ付きの文字となっています。戸籍統一文字優先に変更してしまうと,多くのグリフを変更する作業が必要になりますし,JIS X 0213:2004に倣うとしたGlyphWikiおよび花園明朝の方針を大きく変更するものとなります。
  • 字形が大きく変更されれば花園明朝ユーザーに多大な影響が出ます。GlyphWikiを知らない花園明朝のみのユーザーから見れば理由のよく分からない字形変更となり,花園明朝の信頼性が落ちてしまいます
  • もし戸籍統一文字を優先させたいという需要が多数あるならば「花園明朝A-戸籍」「花園明朝B-戸籍」というような派生フォントの制作を検討すべきと考えますが,現時点ではそこまでの需要は無いと考えます。
  • 以上,--spinda-kkmr 2019年2月22日(金) 21:28

uXXXXの字形について

現在、uXXXXとuXXXX-jの字形に差が存在するグリフが存在しますが、字形を合わせるべきでしょうか。--kesuuko 2018年11月13日(火) 23:22

ゲエズ文字の作字について

①文字幅

ゲエズ文字は全角と半角のどちらが良いのでしょうか。--kesuuko 2018年8月22日(水) 20:19
    • ひとまず全角で作字を行うことにしました。異論のある方はこちらにご記入ください。--kesuuko 2018年9月30日(日) 12:52

②書体

ゲエズ文字をUnicode規格票通り作字することは困難です。このような場合、どのように作字すれば良いでしょうか。--kesuuko 2018年8月22日(水) 20:19
    • ひとまずゴシック体で作字を行うことにしました。異論のある方はこちらにご記入ください。--kesuuko 2018年9月30日(日) 12:52

u4e22-tに関して

現在、u4e22-tは正確な字形になっていません。このような場合、どのようにすれば良いでしょうか。なお、対応案の一覧を作成しましたので、そちらも参考にしてください。
1新しい筆画の種類2:33:xxとする
25画目が4画目を貫くようにする
34画目と5画目を離す
4作字不可能として白紙化する
    • 以上。kesuuko 2018年7月23日(月) 15:29
  • u4e22-tについて、u2123cを使わないようにしました。
  • 筆画同士であれば頭部形状を接続にすることができますが、部品に対しては接続ができないと思われるため、
5部品を使わない

「関連付けるべき符号位置」のページについて

  • 「その他(未整理)」のところに異体字を追加しようとしてもできないのですが、多すぎて詰まっている、ということはありませんか?(私の勘違いでしたらすみません)
  • yoshiciv 2018年7月17日(火) 21:00
    • 諸事情により当該ページは現在投稿できない状態になっています。追加したいデータを直接管理者までメールで送ってくださいませんでしょうか。--kamichi 2018年7月17日(火) 21:16
    • 一々メールで送るのは失礼だとも思ったのでここに書きます。崇と𡸶です。u21e36とu5d07です。出典は天原發微。康熙字典にあるというのは誤りですね。yoshiciv 2018年7月20日(金) 00:59。
  • 対応が遅くなって申し訳ありません。当該ページに追加しました。また修正済みのため、投稿も可能となっております。--kamichi 2018年8月27日(月) 12:10

ハングル字母の字形

合成文字の字形

合成文字の字形はsandbox@3271のようにそのまま重ねて合成できる字形とu0363@1のようにGlyphWikiでしっかり表示できる字形のどちらが良いのでしょうか。--kesuuko 2018年5月27日(日) 20:31
  • 私個人の意見ですが,フォントとして生成した時の実用性の方が大切だと思うので,前者の方が好ましいと考えます。--spinda-kkmr 2018年5月27日(日) 20:36

Unicode11.0の文字について

Unicode11.0で追加される文字はいつからu****(*)に登録してよろしいのでしょうか。--kesuuko 2018年4月30日(月) 09:52

  • 「unstable-****」の使い方が定着しつつあるので、裏を返せば発行されてからかなと思います。ただ漢字のように集合が大きいものは少し早めに解禁するか、管理者側で一括でstableにするかしないといけませんね。--kamichi 2018年4月30日(月) 18:26

ハングルの追加

wiriamuさんがハングルの11172個(U+AC00~U+D7A3)の字母のデータを提供してくれました(wiriamu_uac00wiriamu_ud7a3)。データをそのままUCSコードポイントのグリフに置き換えて、ハングル完成、としても良いのではないかと思いますがご意見お願いします。特に異論がなければそのようにしたいと考えています。--kamichi 2018年4月17日(火) 09:03

利用者-会話:kesuuko@8ゟ引用

そのまま置き換えることに賛成です。ハングルは出来る限り早く完成させるべきだと思います。--kesuuko 2018年4月16日(月) 16:22

choseong、jungseong、jongseongのグリフ(グループ:wiriamu_hangulにあるもの)の名前は、u11##-var-00#が適切です。U+31xxのハングル字母はKS X 1001との互換のために存在し、結合には使われないので不適切です。結合に使われるハングル字母はU+11xxです。 --匿名利用者 2018年4月16日(月) 17:39

  • 私もそう思います。前から不自然な命名だと思っておりました。速やかに移動すべきだと思います。--kesuuko 2018年4月16日(月) 18:48

サンプルです。--kesuuko 2018年4月16日(月) 21:07

古い字形新しい字形
uac00@4uac00@5
uac01@5uac01@6
u115f-u1161-u11a8@6u115f-u1161-u11a8@7

↑引用終わり

  • wiriamuさんのデータをそのまま取り込むとした場合に、元のデータはwiriamuさんの部品を組み合わせています。以下223個です。これをkesuukoさんがやっているようにu11##系の部品に直して取り込むほうがきれいだと思うのですが、対応関係というのはすぐに付けられるものでしょうか?--kamichi 2018年4月20日(金) 11:19

利用者-会話:kamichi 223個の一覧

合成文字のグループ

合成文字のグループはどのようなものが望ましいでしょうか。私は次のように分けるべきだと思っているのですが。--kesuuko 2018年2月6日(火) 20:35
グループ名説明文字の一例
グループ:NonSpacingGlyphs全角か半角か決まっていない文字に合成される文字及び制御文字ufeff
グループ:NonSpacingGlyphs-Halfwidth半角の文字に合成される文字u0300
グループ:NonSpacingGlyphs-Fullwidth全角の文字に合成される文字u3099

契丹小字

グループ:契丹小字-文字一覧に含まれている文字は明朝体にするべきでしょうか。--kesuuko 2018年2月1日(木) 23:40
    • 明朝体がいいと思います。
    • 参照するグリフを決めておくと編集合戦を避けられますが,Andrew Westさんのサイトにあるグリフ http://www.babelstone.co.uk/Khitan/Kane2009List.html ではいかがでしょうか。 --ziyang 2018年2月2日(金) 00:03
    • 賛成ですが、サイトに存在しない文字はどのようにすべきでしょうか。--kesuuko 2018年3月26日(月) 15:05

Ext.G

http://www.unicode.org/wg2/docs/n4922-5theditionPdam2-2-charts.pdf に含まれているグリフの内、http://www.unicode.org/alloc/Pipeline.html に含まれていないグリフはどのような命名が望ましいでしょうか。 以下に想定され得る命名の一覧とそれの問題点をまとめました。--kesuuko 2017年12月9日(土) 23:04
命名問題点
グループ:prefix-unstablehttp://www.unicode.org/alloc/Pipeline.html に含まれていない
グループ:prefix-roadmaphttps://unicode.org/roadmaps/index.html に含まれていない
グループ:prefix-uまだUnicode標準になっていない
新規命名使い捨てになる

  • すみません、反応が遅れました。現時点では、ソース名が唯一固まっているものと思いますので、ソース名で登録するというのはいかがでしょうか。例えば上記PDFでU+30000を当てているグリフについてはuk-02764となります。--kamichi 2017年12月17日(日) 13:14

    • 回答ありがとうございます。ですが、問題がいくつかありました。
      • uk-02764は不正な命名である。
      • ②非漢字についての説明がない(これは私が作った見出しが問題だと思いますが……)
      • 以上です。--kesuuko 2017年12月21日(木) 23:22

  • ①については、1つ目の登録にまずprefixの登録作業が発生しますね。今回の作業用にまとめて用意したほうが混乱が少ないでしょうか。ちょっと考えてみます。--kamichi 2017年12月22日(金) 11:49
  • ②については今のところノーアイデアですが、「work-uXXXX(X)」で暫定的に登録し、後で機械的に再登録する形でいかがでしょうか。--kamichi 2017年12月22日(金) 12:02

  • UTCとWG2で別々に審議されているので,WG2で提案された文字がすぐにPipeline Tableには載りませんが,通常はつぎのUTCの審議でPipeline Tableに掲載されると思われます。Pipeline Table掲載に先駆けてunstable-uを使用しても支障はないように思います。prefix-unstable-uの定義での「Unicode Technical CommitteeによりUnicodeに追加が予定されている文字」を「Unicode Technical CommitteeまたはISO/IEC JTC1/SC2/WG2によりUnicode/UCSに追加が予定されている文字」に拡張すれば,unstable-uを使えるようになります。
  • 下のトピックのroadmapにある文字は,現状のprefix-unstable-uの定義に含まれると解釈して,こちらもunstable-uを使用しても支障はないように思います。 --ziyang 2018年2月4日(日) 13:54

Roadmaps to Unicodeに関して

https://unicode.org/roadmaps/smp/ に含まれるグリフはどのような命名が望ましいでしょうか。--kesuuko 2017年11月11日(土) 21:45

システム用グリフの使い分け

undefinedreservedmissingketsubanの使い分け方を教えてください。 --kesuuko 2017年11月5日(日) 22:38
  • ノート:ketsubanによると、グループ:CodeChartsのように連番でグリフを並べたグループ・一覧表で、undefinedはシステム上定義され得ない番号に、reservedは今後文字が追加される可能性がある番号に、missingketsubanは今後も文字が追加される可能性がない番号(欠番)に使用することとなっているようです。missingketsubanそれからu2ff0-u6b20-u756a-u20dd(=circled-u2ff0-u6b20-u756a)の使い分けは特にされていないようですね……? 本当に使い分けられていないのであればどれか1つに統一したほうが混乱が少ないと思いますが。―twe 2017年11月6日(月) 00:17
  • 欠番を示すグリフを統一することに賛成です。また,ノート:ketsubanで提案されているように,ketsuban@1u2ff0-u6b20-u756a-u20dd@3missingに統一することに賛成です。そちらでは,作成者も「欠番を表す記号のような利用例があればそれに変更することに賛成です」。後者はすぐ白紙化できそうですが,前者は「CodeChart-大漢和辞典文字」に大量に使われているので,入れ替え作業は億劫です。とりあえず「missing」のエイリアスにして,記号は統一するのが良いと思います。 --ziyang 2018年2月18日(日) 19:56
    • circled-u2ff0-u6b20-u756a@4は,ノート:circled-u2ff0-u6b20-u756aで削除の結論が出ていますが,現在までそのままになっているようです。こちらは先行して白紙化します。 --ziyang 2018年2月19日(月) 00:19
    • 「ketsuban」を「missing」のエイリアスにし,「u2ff0-u6b20-u756a-u20dd」は名称上「missing」のエイリアスにはできないので白紙化しました。 --ziyang 2018年2月25日(日) 23:40

古代ペルシア楔形文字について

古代ペルシア楔形文字はsandbox@2999のようにするのとu10382のようにするのではどちらが望ましいですか?--kesuuko 2017年10月19日(木) 21:02
  • u10382のようにする方針で作成開始しました。異議のあるかたは記入をお願いします。--kesuuko 2017年10月24日(火) 20:47
    • それでよいと思います。古代文字はUnicode規格票に近い形で作成するのがよいと思います。--spinda-kkmr 2017年10月28日(土) 10:21

アラビア文字について

アラビア文字は投稿しない方が良いですか?--kesuuko 2017年10月12日(木) 22:30

  • おそらくどなたも回答しようがないと思うのでコメントします。原則論として(1)グリフウィキは明朝体漢字字形の共有データベースである、副次的に非明朝体漢字字形(非漢字含む)の登録も可能である。(2)グリフを共有したいと思う人がいれば、自分で登録作業ができる。という2点を考えれば、登録していただいてよいと思いますし、ありがたく思います。ただ、それを花園フォントに搭載するかどうかについては別の議論になります。問題は、花園フォント管理者(私)がアラビア文字体系に疎いことと、アラビア文字のフォントへの搭載についても疎いということで、花園明朝への搭載は難航することが予想されます。--kamichi 2017年10月13日(金) 11:47

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

台湾語の文字について

台湾語の文字を見つけたのですがグループってどうやって作ればよいのでしょうか?命名方法とかに疎いので。作っていただければ登録に協力します。勝手なお願いで申し訳ありません。 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

  • 取り敢えずtaiwanese-gin2-001で作ろうとしたら命名ルールで弾かれてしまうのですがどうすればよいでしょうか。この種のことに暗くて。yoshiciv 2017年7月4日(火) 23:06

    • 「taiwanese-NNNN」というprefixなので「taiwanese-0001」のような4桁の数字表記のみ許容されます。まずは連番で作成し、完成したら音表記に移行するということでいかがでしょうか。--kamichi 2017年7月7日(金) 16:11

    •  作成できました。有難うございます。yoshiciv 2017年7月8日(土) 09:13

サンドボックス

グリフのサンドボックスは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

  • Unicode 10.0に収録された変体仮名のうち、戸籍統一文字に存在しない分を“jmj-09####”に作成し終わったので、(3)を実行できるようになりました。―twe 2017年8月3日(木) 21:10

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

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