以下、保存用です。編集はご遠慮ください。
2015年から2016年までの分を保存しています。それ以降についてはGlyphWiki:井戸端-保存をご覧ください。
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
- 議論が長期間止まってしまっているので，早期に方針を決める必要があります。現在，事実上CNSグリフの登録が停止してしまっています。命名について提案いたします。
| hkcs氏案 | spinda-kkmr案 | kamichi案 |
| CNS11643 明体 | c(#)#-m#### | c(#)#-#### | c(#)#m-#### |
| CNS11643 宋体 | c(#)#-s#### | t(#)#-#### | c(#)#-#### |
| Unicode Tソース | t(#)#-#### | u(#)####-t | t(#)#-#### |
- なお，少なくとも私が作成したグリフについては明体と宋体で字形が大きく異なる場合は登録そのものを断念していたはずなので問題はありません。
- 以上，--spinda-kkmr 2020年3月13日(金) 18:34
- spinda-kkmr案について、明体については賛成しますが、宋体については反対します。t(#)#-####はUnicodeのT字形を示す場合に使われており、特に拡張Hに相当するものについてはu(#)####-tによる代用は不可能です。--kesuuko 2020年3月17日(火) 03:18
- 代案（？）を出しました。基本的に現状維持＋αの案だと思います。ただし「m」と4桁を分けたほうがいいと思うので前に移しました。--kamichi 2020年3月17日(火) 17:52
- CNS11643の宋体とUnicodeのT字形は等価なのでしょうか。もし等価ならばspinda-kkmr案に賛成し、等価でないならばkamichi案に賛成します。--kesuuko 2020年3月18日(水) 14:18
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を編集するにあたって、私の一存では決めかねる事がありましたので、皆さんのご意見をお聴きしたく投稿いたします。既に決定事項がありましたらお手数ですがご教授願います。
- １．汎用電子コレクションの典拠グリフのリンクにあたって、グループ:IVD-20101114の「汎用電子文字のグリフウィキ変換について」に従って追加予定です。しかし、これらを全て追加するのか、それともX0208:1978固有＋α(ft-####)や表外漢字不足(hg-####)などの現在登録が全くないものに関しては省くのか、どちらがよいでしょうか。私としては省かずに全てのリンクを登録した方がよいのではないかと考えています。
- ２．汎用電子コレクションの中には典拠のコードの末尾に「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
ご意見を元に再考した修正案を提示致します。
- １．汎用電子コレクションの典拠グリフは平成明朝グリフのプレフィックス「heisei-」を典拠元の文字集合に関わらず使用する。
１については平成明朝グリフとその典拠元グリフに差がある登録が既にあるため。（例：
heisei-tk01098690と
toki-01098690）
２は１を受けて典拠元グリフではなく平成明朝グリフにリンクするため。また、グループ:汎用電子で付加されているため。
ご意見ありましたらお願い致します。--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
- 1年以上議論が止まっており，康熙字典グリフの登録が事実上できない状態が続いております。半角グリフグループなどの緊急性の高い問題が解決してからでよいので，命名の移行をお願いいたします。--spinda-kkmr 2018年6月3日(日) 10:59
- 恐縮です。3Bの作業を行います。(1)新命名グリフにコピー(2)旧命名グリフを新命名グリフへのエイリアスに(3)命名ルールの変更、とします。--kamichi 2018年6月3日(日) 11:32
- 作業を行いました。(現状でいつにするか未定ですが）今後旧命名グリフの白紙化を行います。--kamichi 2018年6月3日(日) 13:43
仮想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
データベースの高速化について（旧見出し：バックエンドのデータベースのテーブル構造について）
最近ページ表示がさらに遅くなっている気がしたので、ページ生成のどこに時間がかかっているかを確認しました。大きな要素としては（A)「このグリフを内部で引用している他のグリフ一覧」および（B)「このグリフを収録するグループおよび引用するドキュメント一覧」でした。（A)はおよそ1.2秒、（B)は2.5秒ほど費やしています。（B)については対象をグループページに絞ると1.8秒ほどに短くなります。ただしこの情報はデフォルトで表示する内容ではないとも考えましたので、デフォルトは非表示とし、リンクを開いたときに表示するように変更しました。（A)については現状では改善する方策が見出せません。おそらく1年ほど前に書いた下記の記述のとおり、大きな変更が必要なのではないかと考えます。ひとまず現状を記します。--kamichi 2016年2月27日(土) 17:59
- 現在のグリフウィキではwikiのページを種別（グリフとドキュメント）関係なく１テーブルで扱っています。グリフ（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
- すみません、実はすでに翻訳データを有志の方からいただいているのですが、反映できていません。この１，２ヶ月中にハングルも合わせて運用を始めたいと考えています。--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-02のu5782-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）が
ダウンロード できます。
この２つで異同があるようです。
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
- 拡張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
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
接尾コードの追加について
「宀」「冖」などの字形を用いたグリフを作成する際、現在接尾コード「-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の中間程度の形状のもの |
画像が表示されないようです。
編集中のプレビューでも表示されませんでした。
u6534-09 --pyrite 2015年3月22日(日) 18:54
- 大変失礼しました。復旧しました。--kamichi 2015年3月22日(日) 19:38
CJK互換漢字Standardized Variantについて
グループ:互換漢字IVD(グループ名が変ですが)が花園明朝に含まれていないのは意図的なものですか? 文字情報基盤は一部の異体字をCJK互換漢字Standardized Variantで表すことを前提にしていて、IPAmj明朝にも実装されているので、採用を検討していただきたいです。--
emk 2015年1月2日(金) 16:23
RSS