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

GlyphWiki:井戸端-保存

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

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

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

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


台湾語の文字について

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

Vandalism

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Server Errors

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

iOS11でグループ:kesuuko_sandbox@3で生成されたフォントで実験をして確認したところ、正常に合成されました。--kesuuko 2017年10月8日(日) 23:03

  • 後手後手ですみません。今までの書き込みではtweさんのおっしゃる、グリフを負の位置に置いて文字移動幅0にする方法と、johotogoshinentaiさんのおっしゃる、始点と終点(といってもこれがグリフデータ上どれを指すのかわからないのですが)を真ん中にすればいい、という2つがあり、まだ混乱しています。それとkesuukoさんの方法はグリフウィキとしては合成用文字として特に処理されず、OSレベルでU+0300グリフがnon-spacingグリフとして扱われているものと思います。ですので、まだ私の中ではどうすれば合成用グリフが生成されるのかが見えていません。そこで、既存のフォントの挙動を参考に作りたいと思います。合成用グリフがきちんと利用できるフォントの代表と言ったら何でしょうか?Arial Unicode MSは大きいので、普通のラテン用フォントでご教示いただきたく思います。--kamichi 2017年10月9日(月) 09:16

  • 当時きちんと読んでいなかったのがよくないのですが一番初めの「2013年3月31日(日) 19:10」の書き込みを読んで理解したのは、KAGEデータで99の部品引用で負の位置に配置すれば合成ができる、ただし文字幅が0でないので2文字分になる、文字幅を修正すれば合成用グリフの実装ができる、ただしグリフウィキ上文字が見えないのが問題、そこでグリフウィキで指定したグリフ集合について、普通の場所に置いたグリフを負の位置に配置して文字幅0に設定する特別処理を用意すれば合成用グリフが生成できる、ということでいいでしょうか。今はグループ:HalfwidthGlyphsにあるものはFontForge上で「SetWidth(512)」という指定をしているだけです(通常は1024)。これを0にするというのがtweさんのおっしゃっている内容と思い、私もこれで行けるのではないかと思っています。--kamichi 2017年10月9日(月) 09:26

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の中間程度の形状のもの
    • kamiyo 2016年2月7日(日) 15:02

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

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

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

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

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

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

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

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

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

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

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

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

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

CJK互換漢字Standardized Variantについて

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

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