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

GlyphWiki:井戸端

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

目次

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

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年3月26日(月) 15:05
グループ名 左端右端対応状況備考
(いずれにも入っていない)0200対応済み
グループ:HalfwidthGlyphs0100対応済みUCSグリフ等のみ
グループ:HalfwidthGlyphs-nonUCS0100未対応UCSグリフ等以外
グループ:One-thirdwidthGlyphs067未対応
グループ:One-quarterwidthGlyphs050未対応
グループ:One-sixthwidthGlyphs033未対応
グループ:DoublewidthGlyphs0400未対応
グループ:TriplewidthGlyphs0600未対応
グループ:NonSpacingGlyphs00未対応制御文字
グループ:NonSpacingGlyphs-Halfwidth-1000対応済み半角の文字に対して合成
グループ:NonSpacingGlyphs-Fullwidth-2000対応済み全角の文字に対して合成
    • 皆様のご意見をお待ちしております。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

合成文字のグループ

合成文字のグループはどのようなものが望ましいでしょうか。私は次のように分けるべきだと思っているのですが。--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

簡体字のUソース

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

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

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

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

グループ: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: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

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

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

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

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

  • 明朝体が見出し字となっている辞書に、非明朝体だが見出し字として掲載されている字形は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####-###」でいきたいと思います。

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

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

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日置いて、旧グリフを白紙化

  • 大変遅くなりました。作業が完了し、「tron-?-」グリフは0個になりました。--kamichi 2017年12月17日(日) 14:29

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

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

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

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

白紙化の抑制について

異論も多いと思いますが、実運用で気になったので、明確にできればと思います。重複しているグリフの白紙化をどうするか、という問題はこれまでにも出てきました。これまでは意味のある重複は白紙化せず、「-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

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

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

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

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

訓令式や日本式は発音にも合わず、事実上よく使われていません。(誰が「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