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

GlyphWiki:ソフトウェアへの要望

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

以下、要望がありましたらご記入ください。なお、ソフトウェアの改変情報はシステム変更記録に載せていきます。

記述は、新しい項目を上にして、項目ごとに1行空行を入れてください。


GT書体(GTコード)でも諸橋大漢和グリフ(dkw-#####)のページのように前の番号・次の番号が出ると便利だと思います。GT書体一覧とGTコード欠番一覧は既に完成済みですので,可能であれば欠番グリフは飛ばす仕様にしていただけると便利です(例:gt-00175の次は欠番のgt-00176ではなく,次の有効な番号であるgt-00177を表示する)。--spinda-kkmr 2019年5月20日(月) 18:54


IDSエディタ もhttpsに対応していただけないでしょうか。iOSではiOS12.2以降ではHTTPのサイト全てに対して「安全ではありません」と表示されるようになりました。HTTPS版IDSエディタのアドレスは「https://fonts.jp/glyphwiki/idsedit/idsedit.html 」が良いと思います。--kesuuko 2019年4月3日(水) 11:48

関連字を1グリフに2字まで設定できるようにしてください。irg2015-03152に対する(u7cd6/u42af)のように、必要であると思われるグリフが存在します。--kesuuko --kesuuko 2018年10月28日(日) 15:01

  • さすがにそれは設計思想の修正を伴うので無理だと思うのですが、興味深い実例ですね。すこし考えてみます。--kamichi 2018年10月29日(月) 14:43

  • Adobe-Japan1-6にも前後の文字番号を表示してください。例えば、aj1-01125の場合、

前の番号: aj1-01124(aj1-01124)

次の番号: aj1-01126(aj1-01126)

のように表示してください。--kesuuko 2018年8月29日(水) 19:55

  • グループ:NegativeCharactersの更新に対応してください。--kesuuko 2018年6月30日(土) 22:46
    • 検討します。ページで用意すると通常のグリフの登録に負荷がかかるので、反転と同じくKAGEデータ0番の追加で模索中です。--kamichi 2018年7月1日(日) 14:19

  • 検索を正規表現に対応していただけないでしょうか。--kesuuko 2018年4月28日(土) 11:51
    • セキュリティ面で工数が大きくなりすぎるので現状では難しいです。--kamichi 2018年7月1日(日) 14:19

  • 文字幅等を定義するグループのフォント生成対応は、現在三グループに対応していますが、次のように追加していただけないでしょうか。--kesuuko 2018年3月3日(土) 01:23
グループ名 左端右端対応状況備考
(いずれにも入っていない)0200対応済み
グループ:HalfwidthGlyphs0100対応済みUCSグリフ等のみ
グループ:HalfwidthGlyphs-nonUCS0100未対応UCSグリフ等以外
グループ:One-thirdwidthGlyphs067未対応
グループ:One-quarterwidthGlyphs050未対応
グループ:One-sixthwidthGlyphs033未対応
グループ:DoublewidthGlyphs0400未対応
グループ:TriplewidthGlyphs0600未対応
グループ:NonSpacingGlyphs00未対応制御文字
グループ:NonSpacingGlyphs-Halfwidth-1000対応済み半角の文字に対して合成
グループ:NonSpacingGlyphs-Fullwidth-2000対応済み全角の文字に対して合成

  • 戸籍統一文字と同じように,MJ文字図形名のグリフページに文字情報基盤データベースの該当文字へのリンクを表示する機能を実装していただけませんでしょうか。例えばjmj-006294のページに https://mojikiban.ipa.go.jp/search/detail/MJ006294 へのリンクが表示されるようにするということです。同時にMJ文字図形名のページにも「前の番号」「次の番号」を表示してほしいです。--spinda-kkmr 2018年1月28日(日) 10:19

  • ISO/IEC 10646 付属の、 CJKSRC.txt において、各 Uxxxxx に対する各国・各地域のソース情報がある場合、 uXXXXX の他に、 uXXXXX-{c,t,j,v,u,k,kp,h,m} のグリフも例示する機能を、拡張Fまで搭載できませんでしょうか? -- golconda 2018年1月13日(土) 10:50
    • 2017/12/22改定のデータで更新しました。--kamichi 2018年1月13日(土) 12:27

  • Unicode の EastAsianWidth (http://unicode.org/reports/tr11/ ) が、narrow か halfwidth の場合、編集領域を縦横比 1:2 にすることはできませんでしょうか? -- golconda 2018年1月13日(土) 10:50
    • これは専用エディタの話でしょうか。SWFからHTML5への以降の時点で検討するかどうかのタイミングになってしまいます。--kamichi 2018年1月13日(土) 12:27


  • u2d000u2ebe0にも前の符号位置および次の符号位置を表示してください。--kesuuko 2017年12月26日(火) 17:31
    • すみません、バグでした。修正しました。--kamichi 2018年1月13日(土) 12:01


  • GlyphWiki全体、またはグリフ画像のリンクをSSL対応していただくことは可能でしょうか。現在GlyphWiki:グリフを利用するのURLからグリフ画像を利用させていただいているのですが、https付きの他サイトから引用するとそこだけhttpのままになります。現在はブラウザが少し警告を出す程度で機能に問題はないため喫緊の課題ではないですが、iOSが将来SSL必須にするのではないかという話 もあり、できればhttpsプロトコルでも利用できるようにしていただければうれしいです。n747 2017年3月24日(金) 16:55
    • ご提案ありがとうございました。早速ですがGlyphWiki全体(ただしglyphwiki.orgのみで他語種未対応)に対してSSL(TLS)を導入して見ました。不具合ありましたらお知らせ願います。--kamichi 2017年3月25日(土) 15:36
      • さっそくのご対応誠にありがとうございます。遅ればせながらで申し訳ありませんが、httpsで取得できることを確認いたしました。今後ともよろしくお願いいたします。n747 2017年4月10日(月) 14:19


  • 旧部品の一括更新時に失敗して赤い×印になってしまう事例がありました(例:waseikanji-no-jiten-2135@2waseikanji-no-jiten-2135@3,現在は復旧済み)。この他にも赤い×印のまま放置されているグリフが存在すると思われます。赤い×印になっているグリフを検出するツール(「最近更新したページ」のような特別ページ)があれば赤い×のまま放置されることを防げると思います。--spinda-kkmr 2017年2月9日(木) 19:29
    • 特殊ページを新規に増やすのが難しいので、このような 検索ができるように細工をしてみました。新しいものから10個の赤バツのグリフが新しい順に表示されます。
    • それで、赤バツのグリフは(1)生成時にプロセスが落ちたもの(2)データが間違っている、の2つありますが、(1)については(手動で)定期的に再生成することにします。(2)いついては(手動で)定期的に削除することにします。--kamichi 2017年2月10日(金) 18:48
      • 掃除が終わったので現在0個です。--kamichi 2017年2月10日(金) 21:07


  • 命名ルールに沿わないグリフは登録・編集ともにできなくなっていますが,「編集は可」としていただくと,一般使用者も既存の該当グリフを整理することができます。命名ルールにないbsmg3033a2205@1extf-06486@2と同字形なので整理したいのですが,現状の仕様ではこうした作業をいちいちkamichiさんにお願いしなければならず,管理者の負担が大きいのではないかと思います。 --ziyang 2017年1月29日(日) 10:58
    • 私も上記意見に賛成いたします。登録のみ不可とすれば既存不適格グリフの整理ができるのでよいと思います。「匿名利用者は登録・編集ともに不可,登録利用者は編集のみ可」とすれば荒らしを防止しつつ既存不適格グリフの整理も可能になるのでよいと思います。--spinda-kkmr 2017年1月29日(日) 11:10
    • ご意見ありがとうございます。そのように改善しました。--kamichi 2017年2月10日(金) 16:55


  • Add Extension F support? The Extension F chart is already finalized and any modifications (e.g. removal of EXACT duplicate character) I have proposed to have already been rejected by experts from UTC via email correspondence. hkcs 13:04, 31 December 2016


  • 「最近更新したページ」にて、「ユーザー占有グリフを表示or隠す」を追加して頂きたいです。最近ユーザー占有グリフ(username_xxxxxx)が劇的に増えています。そのため、他の方が登録編集ミスしたグリフを見落としする可能性がありますので、当フィルタがあると有難いです。--kamiyo 2016年12月30日(金) 13:15
    • 上記,私も賛成です。康熙字典命名移行後あたりに行ってくれればありがたいです。--spinda-kkmr 2016年12月30日(金) 22:05
    • 最近,ユーザー占有グリフが増えており,このままでは荒らしの編集を見落とす可能性があります。なるべく早い実現をお願いいたします。--spinda-kkmr 2017年1月15日(日) 10:48

  • 「最近更新したページ」にて,簡体字中国語の利用者が編集した「旧部品の一括更新」に対する「旧部件批量更新」や「エイリアス実体変更による自動更新」に対する「别名实体变更引起的自动更新」の表示を,日本語ユーザー利用時も(自動編集の表示オフ時に)表示を省略するようにしてほしい。--spinda-kkmr 2016年9月17日(土) 10:14
    • 対応しました。翻訳が固まっていないので他言語(おそらくハングルのみ)については都度追加とします。--kamichi 2016年9月17日(土) 11:34
  • バグがあるようです。このページの@470の編集が「最近更新したページ」から見えなくなってしまっています。「文章のみ」の表示にして自動編集の表示を切り替えれば確認できると思います。--spinda-kkmr 2016年9月17日(土) 19:15
    • 失礼しました。自動更新などのキーワードの部分一致で判定するのをやめ、要約メッセージの完全一致で判定するように修正しました。--kamichi 2016年9月17日(土) 20:40

  • CJK統合漢字拡張FのJソースとなるIPAmj明朝の「酉」の部分字形では,第5画の折れの終筆が縦画に接続しています。例えば,jmj-060255jmj-060256jmj-058887です。u9149-01-var-003u9149-04-var-004のような既存の部品も同様です。現在,「折れ」の尾形状は開放と上ハネしかないため,開放が使われていますが,横に縮小すると突き抜けてしまいます。「接続」があると便利なように思います。 --ziyang 2016年7月11日(月) 21:09


  • Req 1: Currently there is previous / next codepoint buttons for uxxxx-y and koseki-xxxxxx. Is it possible to specify which sequences to show the prev/next buttons, in a way similar to GlyphWiki:グリフの説明?
    The main use case is the previous mentioned h-propose-uxxxx, it would be much easier to navigate if there were link for the previous and next character.
    For now maybe just assume that all characters are sequential in order.

    • 現在、ページ表示の計算処理に時間がかかっているので、これ以上追加したくないのですが、前向きに検討します。ただし、汎用的な機構を用意するのではなく、あくまでもソースコードに個々のケースの追加となります。--kamichi 2015年5月12日(火) 13:08

  • Req 2: It would be better if the suffix (e.g. hen-ka deformation, locale can be preserved in the links), i.e. in u4e00-t next button will be u4e01-t instead of u4e01.

    • ちょっと要求と違いますが、拡張してみました。--kamichi 2015年5月12日(火) 13:08

  • Req 3: For the glyphs that do not exist in the Unicode Multi-column Chart, e.g. u200b8-t, is it possible to show a warning at the top of the page?

    • これも追加したいと思います。グリフ命名のルール化に伴う機能拡張の一部として考えています。--kamichi 2015年5月12日(火) 13:08

Thank you in advance!! -- chanhenryfaihang 16:50, 8 May 2015

  • ご提案ありがとうございます。仕様をどのようにするか迷っています。
    • まず、エイリアスグリフでも一般グリフと同じように情報を出す方向で考えています。
    • 地域コードつきは地域コードつきの移動ができるようにしたいですが、グリフが無い場合、あるいはそもそも地域コードが無い場合にどうするか
    • そろそろ全地域コードが一覧できたほうが良いか
    • などなど--kamichi 2015年5月9日(土) 18:18

  • UIは試行中ですが、とりあえず拡張しました。見にくいでしょうか… --kamichi 2015年5月12日(火) 13:03

  • Thank you very much!!
  • I think I would be better to place the boxes in a <table> so "previous code point", "browser view" and "next code point" line up. Also, in that case, maybe having them in fixed table cell would be better. An empty cell would be inserted if that country did not have source reference.
  • The order may be better if it follow the Unicode Chart order i.e. GHTJKV. For now, no KP glyph exists in the code chart, so maybe it can be ommitted.
  • For Extension B, there should be an -i glyph. Also for characters with no Japanese source, there should also be a -jv glyph.
  • A design suggestion is available at http://hovertravel.byethost17.com/glyphwiki-suggest-1.png .
  • --chanhenryfaihang 20:54, 15 May 2015

    • l think that jv should be displayed only if a jv glyph aiready exists, so that people are not tempted to create it when jv rules are not applicable. Also, -ja needs to be included (see u34f2-ja)--umbreon126 2015年5月16日(土) 00:26

  • 現状では日本語でグリフウィキを利用していると,「最近更新したページ」で自動編集を表示しない設定にしていても,英語での利用者が編集した「旧部品の一括更新」に対する“lump update of old components”や「エイリアス実体変更による自動更新」に対する“Automatic update by changes of substance of aliases”が表示されてしまうので,表示されないようにしてほしい。--spinda-kkmr 2015年4月20日(月) 17:51
    • ご指摘ありがとうございます。ということで現状の英訳について、表示しないようにしました。--kamichi 2015年4月20日(月) 23:37

  • 関連字の無いページ(IDS、CDPとか)でも-var-001 -itaiji-001が表示されるのは便利と思います。--umbreon126 2015年4月13日(月) 16:07
    • これはどういう意味でしょうか。「xxxxxx」というグリフと「xxxxxx-var-001」というグリフが存在したときに、「xxxxxx」のグリフページに「xxxxxx-var-001」が表示されるということでしょうか?どの形態になりますか。--kamichi 2015年4月16日(木) 22:22
    • はい。分かるように説明しなかったすみません。umbreon126 2015年4月20日(月) 18:01
    • ありがとうございます。そうするとページ生成に計算処理が増えてしまうので、若干ページ表示がさらに遅くなるという問題がありますが、検討します。--kamichi 2015年5月12日(火) 13:11

  • Addition of extra stroke types or stroke endings for the following cases:
  • small triangle in lower left hand corner of 豎折 u31d7, similar to chanhenryfaihang_stroke-szh.
  • small triangle on the top of (non-composite) 捺 u31cf, similar to chanhenryfaihang_stroke-n.
  • This is so that I can more accurately reproduce the stroke shapes found in G-source glyphs and also in certain HK fonts
  • Also, I suggest the thickening of the top 捺 of 橫捺 u4e41, similar to chanhenryfaihang_stroke-hn, which is component of u4eaa, as current form looks like disjointed strokes.
  • chanhenryfaihang 17:44, 8 April 2015

    • (まだ病み上がりなので取り上えず日本語で書きます)私はこれらのペアは「明朝体のデザイン差」だと思っています。つまり、同じフォントで両者が混在することはあり得ないと考えます。グリフウィキは「字形差」を追求できることを目標にはしましたが、デザイン差は区別しません。同じ環境にデザイン差が混在できることは無用な混乱を引き起こすと思います。
    • ですが、日本とそれ以外の漢字文化圏で明朝体のデザイン差が生じている現状は、データベースの国際化も目指している以上、考慮しなければいけません。
    • そこで私は「デザインセット」の導入を考えたいと思います。つまりグリフウィキで指定できる端形状について、日本デザイン、香港デザイン、大陸デザインのように定義しておいて(当然KAGEエンジンを先に作らなければいけませんが)、ある一定のグリフ(決められたグループページに記述されたグリフに限る形をとりたいと思います)はデザインセットを切り替えてグリフデータを作成するというものです。
    • ただこれは前提として、対象とするすべての漢字のu31d7が香港のデザインセットではchanhenryfaihang_stroke-szhに置き換わって問題ない場合に採用できる方法です。全てではない、となった場合は、端形状の種類も増やす必要があると思います。
    • まずは香港セットから着手してみようと思います。と言っても、なにぶん忙しいので、しばらく時間をください。(そして適宜催促してください)
    • 以上はkamichi 2015年4月10日(金) 22:36

    • 少し調べているうちに、上記の方法をとるまでもなく、G用の左下を用意したのと同じ理屈でGH用の左下、HT用の箱右下を追加したほうが早そうですね。残りの二つはもう少し検討します。--kamichi 2015年4月10日(金) 23:23

    • Actually for lower left corner serif, this is only required for G-glyph, as T-glyph and H-glyph do not exhibit this serif. (I am proposing the H-glyph to adopt the G-glyph style to the government.)
    • For the second one, this style is also G-glyph only, which I would like to be able to faithfully reproduce, for reason above as well.
    • For the third one, the thickening of the stroke is required to accurately reproduce the form for T-glyph and H-glyph.
    • FYI, current "Lower Left G/T" is more similar to T-glyph in Unicode. To reproduce H-glyph, one can use "Connect (H)" for the end shape of the downward stroke instead. Only G-glyph style cannot be accurately reproduced.
    • Above from chanhenryfaihang 01:30, 11 April 2015

    • It is welcome if "Lower Right T/H" could be implemented directly. I am not sure if I misread the translation, but I think it is better if the same glyph can use any of these end shape designs, as it will be hard to auto-detect a "Japan Design Set" or "Hong Kong Design Set" for user owned glyphs. Vietnam Glyph may choose to have some of these special feature too... I think not necessary to distinguish between "design" and "shape", it is hard to draw the line for international use.

    • For the proposed "Lower Left G" and "Lower Right H/T", I suggest these be implemented as a start/end on the horizontal stroke. The vertical stroke can choose to use "Connect (H)", that should simplify implementation. For example, for "Lower Left G" the new polygon only depends primarily on the angle of the horizontal stroke. Also for "Lower Right H/T", the shape can be easily constructed by extending the y-coordinate of the existing polygon. Hope this can help!

  • chanhenryfaihangさんのお返事を読む前に、作成に着手してしまったので、とりあえずプロトタイプです。sandbox@2172 --kamichi 2015年4月16日(木) 22:14
    • 今回の新しい左下角、および、今まで拒否してきましたけど方針を変えて追加することにする右下角は、私の考え方では、日本のデザインでは、もともと形状として2種類あるものが1つに統合されていると判断したため、分離する、という位置付けです。本来はデザインセットで切り替える形をとりたいのですが、数が少ないのでひとまず共存ということにします。--kamichi 2015年4月16日(木) 23:15
  • こちらもプロトタイプ作りました。sandbox@2173--kamichi 2015年4月17日(金) 08:45

  • http://i.imgur.com/Tg9TLsL.png 捺+1.
  • i also suggest to add "half-thickness beginning" and "half-thickness beginning with small triangle". note that 癶登發 has no triangle. they're unified in most chinese 宋体 fonts, including ucs (see http://i.imgur.com/TqyZ8b7.png http://i.imgur.com/1g0hwqH.png http://i.imgur.com/vXap6yh.png . also note the 兪's long triangle).
  • ((((入 is a more special case. see http://i.imgur.com/BB9lkZ4.png
  • in fact there are following types of 入 implemented in china: "点捺"u5165-var-002 (like u5165-g but inexactly) with half-thickness beginning, full-half-full thickness like u5165-var-001, and half-thickness beginning with small triangle (as in ucs); also "捺" half thickness beginning with triangle (like u5165-g@1 but inexactly). none of them begins with "细入り".
  • but ucs seemed to always use with-triangle 入.
  • also, just unlock 右払い combined with 接続/開放 (also the half-thickness mentioned above) in 曲線/複曲線. see 华文中宋 亪.
  • though i called it "half", it may be in fact like 1/3.
  • above from farter 2016年1月13日(水) 00:01


  • ストレッチ境界に「U」「D」「L」「R」以外に、「C」(Center)「V」(VerticalCenter)の追加というのはいかがでしょうか。
  • 例えばu6797-05をメタ情報で「ストレッチ境界 100,100(C)」と設定、専用エディタの[ストレッチ]を「-#」に設定すればu6797-11の様に中心が徐々に狭まり、「+#」に設定すればすればu6797-10の様に中心が徐々に広がる、
    u26b07-05メタ情報で「ストレッチ境界 100,140(V)」と設定、上記同様に専用エディタの[ストレッチ]の値を変化させればu26b07-10の様に変化する、
    また「ストレッチ境界 100,100(VC)」とすれば、u24cf3をストレッチ調整してu5341と組み合わせるだけでextf-04775が出来るなど
    既存部品を利用しても見栄えの良いグリフが出来、部品数も減らして新規に作成できるので良いかと思います。--kamiyo 2014年12月29日(月) 13:59

  • KAGEエンジンのパス統合済みのSVGを出力する関数はどれですか?教えてください turgenev 2014年12月5日(金) 00:29
    • 現状では存在しません。外部ツール(Clipper )で結合しています。--kamichi 2014年12月5日(金) 07:54
    • リポジトリ(git.chise.org)のどのファイルを見ればclipperの使われ方が分かりますか?ローカル(WindowsやLinux上)でkage→パス統合SVGに変換したいです。--turgenev 2014年12月5日(金) 18:46
      • 利用者-会話:kamichiのような感じでPerlを介してKAGE出力SVGをパス統合SVGにしています。--2014年12月6日(土) 15:18

  • Special:Mustrenewのサイズ(HTMLだけ)は5MB以上です。(ブラウザのコンテキストメニューの「Save Link as」をクリックしたら5MB以上のページが保存されました)これは好ましくないと思います--umbreon126 2014年11月20日(木) 11:32
    • ご指摘ありがとうございます。コストをかけずに対処するにはどうすればいいでしょうかね。先頭の一部しか出さない、とするのは望ましくないでしょうし。--kamichi 2014年11月22日(土) 09:13
    • 考え方を変えて、ランダムに500個表示する方式に変更してみました。網羅性は落ちますが、表示するごとに集合が変わります。(現在日本語ページでのみ動いています)--kamichi 2014年12月4日(木) 11:59

  • sandboxの関連字を強制的に〓にする。--kamichi 2014年10月8日(水) 08:37

  • u0022u1f0a3のような非漢字のUnicodeページでも前の符号位置,次の符号位置が表示されるようにしてほしいです。--spinda-kkmr 2014年10月5日(日) 13:22
    • ブロックの空き符号位置を考慮せずに単にプラスマイナス1、でしたら可能と思います。--kamichi 2014年10月5日(日) 14:45
      • ご検討ありがとうございます。非漢字は空き符号位置が多いので考慮するのは事実上不可能だと思うので,それで十分だと思います。--spinda-kkmr 2014年10月5日(日) 15:00
      • やってみました。なお、手抜きによりU+3###の符号位置は漢字として扱われ、それ以外の非漢字は非漢字として処理します(他サイトへのリンクが表示されません)。--kamichi 2014年10月5日(日) 16:15

  • 「部品の一括更新」からユーザー占有グリフを除きますのは便利ですと思います。他のユーザーの編集はできませんので、表示しますのは意味がありませんか。--umbreon126 2014年9月21日(日) 04:59
    • おっしゃる通りと思います。対応いたします。--kamichi 2014年10月5日(日) 14:46
    • 対応してみました。--kamichi 2014年10月5日(日) 16:15

  • 戸籍統のグリフなどのように、字海のグリフに「関連情報」リンクが表示されるのは良いと思います。(グループ:中華字海からの例え:zihai-114510http://yedict.com/content.asp?word=114510 umbreon126 2014年8月29日(金) 14:52
    • 辞書とyedict.comの関係が分からないのですが、無関係でもリンクをつけますか。他の方のご意見もお聞きしたいところです。--kamichi 2014年8月29日(金) 18:30

  • U+9FCDからU+9FE9まで、UNCが追加される予定です。関連字の範囲を変更してください。(UNCの臨時命名は困難なので、直接登録するしかないと思います。)
  • http://std.dkuug.dk/JTC1/SC2/WG2/docs/n4585.pdf --johotogoshinentai 2014年6月6日(金) 19:31
    • http://blogs.adobe.com/CCJKType/2014/06/9fcd-thru-9fe9.html 通用规范汉字表のマッピングも更新され、変更もない可能性が高いようです。 --johotogoshinentai 2014年6月7日(土) 10:49
    • 早いかなとも思ったのですが、グリフウィキの近年の目的として、制定中事項の対応も必要性が高いので、変更しました。ご提案ありがとうございます。--kamichi 2014年6月7日(土) 14:59

  • u91d2-01の「旧部品の一括更新」http://glyphwiki.org/wiki/Special:Mustrenew?view=listup&target=u91d2-01 が,ユーザー占有グリフで埋まってしまい進まなくなりました。「ユーザー占有グリフの表示の有無を選べるようにする」か「ユーザー占有グリフは本人分のみ表示する」かのいずれかの対応をするほうがよいと思います。--spinda-kkmr 2014年5月10日(土) 11:48
    • ユーザー占有グリフは自分の分のみ候補として出す事に変更しました。ご指摘ありがとうございます。--kamichi 2014年6月7日(土) 17:42

  • フォント生成時のfallback機能を提案します。現在、グリフウィキでは主に(仮想)J字形がメインで、GやT、K字形などは(仮想)J字形よりは少ないです。地域フラグがついていない符号位置も多いです。そのため、G用フォントやT用フォント、K用フォントを作るのが厄介です。
  • というわけで、グループにu####-gu####-kのような記述があって、u####-gやu####-kがグリフウィキに登録されていないと、フォント生成時には無印グリフのu####が代わりに使われるようにする、いわゆるfallback機能を提案します。 --johotogoshinentai 2014年4月2日(水) 07:09

    • 現状で[u####][u####-g u####]と書けば同等の事ができるので、いらないかな、という気もします。追加する方向で検討しますが、フォント生成は優先度の高い修正事項があるので、そちらを優先したいと思います。--kamichi 2014年4月2日(水) 22:49

      • 私が意図したのはグループ:test@171です。つまり、フォント生成時に、コードポイントに対してグリフを埋めていく課程で、上書き処理で読み込むというものです。ですので、先にfallbackに相当する無印グリフを読み込んでおき、あとで-kなどのグリフを呼び出せば、同じ事ができます。実際には、指定されたグリフが無い場合にその記述を無視する必要がありますが、現状ではグリフが無い場合はそのコードポイントごと無くなってしまうので、上手くいきませんでした。これを上手くいくようにするだけではダメでしょうか。というのは、あまりUCSコードポイントに複雑な意味を持たせたくないからです。--kamichi 2014年4月5日(土) 20:58

  • ベースグリフからの派生時のグリフ命名の簡素化および番号重複を避けるための機能が必要 --kamichi 2014年1月4日(土) 14:34

  • グリフエディタで「左下GT用」のカドも(「左下カド」と同じように)横画と接続している時に片方のストロークを動かすともう片方のストロークが連動するように(つまり、カドの接続が離れないように)してほしいです。―twe 2013年5月11日(土) 11:08

  • IDS表現のグリフを編集するときに,互換漢字領域の漢字もエディタに表示されるようにしてほしいです。例えば,u2ffa-ufa66-u9ce5を編集するときに,ufa66がエディタの右側の部品一覧に表示されません。--spinda-kkmr 2013年4月19日(金) 18:36

  • 今、旧部品引用グリフの数が多いので、「旧部品引用グリフ」ページをロードするのに時間がかかりすぎ、サーバにも負荷を与えていると思われます。分割を提案したいと思います。 --johotogoshinentai 2013年2月20日(水) 19:31
    • 私も賛成します。「旧部品引用グリフ」のページの容量が大き過ぎ,最後まで読み込まれなかったり,ブラウザが落ちたりします。--spinda-kkmr 2013年2月20日(水) 19:55
    • あまり複雑にしたくないのですが、「u」で始まるか否かで分割ということでいいでしょうか?実際やってみないと判断できないかもしれません。--kamichi 2013年2月20日(水) 20:27
      • 50個ごと分割するのはいかがでしょうか? --johotogoshinentai 2013年3月12日(火) 18:59
      • その都度ページ状態を計算・保持するのが面倒なんですよね…。エイやっと実行するにはちょっと時間(やる気)が足りません。--kamichi 2013年3月25日(月) 15:08

  • 現在、koseki-######とdkw-#####は、「前/次の符号位置/番号」が表示されますが、このようなものをjuki-####とtoki-########にも適用するのはどうでしょうか。 --johotogoshinentai 2012年11月4日(日) 13:41
    • 「juki-」は連番になっていないですよね、テーブルを持たないと対応できないとなると若干面倒です。「toki-」はどうなんでしょうか。--kamichi 2012年11月4日(日) 17:55
    • いったん凍結として閉じます。--kamichi 2013年2月10日(日) 21:44

  • u25316-jv@1のように,部品と部品の組み合わせによってはカドが大きく飛び出して(ここでは「目」のカド)字形が悪くなってしまうので改良してほしいです。--spinda-kkmr 2012年6月10日(日) 20:50

  • 特殊グリフには説明文を付けたい --kamichi 2012年6月9日(土) 11:49
    • メタ情報に相当するので実装済みとして閉じます。--2013年2月10日(日) 21:43

  • 「末端にウロコがついている折れ」を表現できるようにしてほしいです,具体的には「折れ」の尾形状に「開放ウロコ付き」を追加してほしいです。現状では「折れ」の尾形状が「開放」と「上ハネ」しかなく,sandbox@928のように縦払いと直線の2本に分割して強引に表現するしかありません。koseki-030150u81e3-var-002等で使われていますが,現状では2本に分割して無理やり表現せざるを得ない状況です。--spinda-kkmr 2012年2月25日(土) 13:01
    • 以前あるグリフのノートページに書きましたが、この形状は明朝体の一般的な形状なのか、あるいは戸籍統一明朝のみのデザイン差なのか、それがわかりません。戸籍明朝以外で使用(デザイン)例はあるでしょうか?そこが気になっています。--kamichi 2012年2月25日(土) 14:21
      • 角川大字源に用例があるようです(http://twitpic.com/3khd6g ただ、この2字のみとのこと)。--pyrite 2012年2月25日(土) 14:45
      • おおお、楽しいですね…。そうですか…、用例あるんですね…。--kamichi 2012年2月25日(土) 14:55
      • もう一つ。講談社大字典(昭和十五年華語増補版)http://twitpic.com/8occom --pyrite 2012年2月25日(土) 15:05
      • 明朝体活字字形一覧を見ると古い方でそれっぽいのがあります。定着前のデザインがゾンビになったもののような気がします。大字典もS40の普及版では該当デザインはありませんね。困りましたね。--kamichi 2012年2月25日(土) 17:20

  • 部品の一括更新に、「座標を変更せず部品のみを置き換える」機能があってほしいです。この機能を使うと、変わるのは部品の名前だけです。部品の微調整をしたときなど、部品の座標をそのままにしたいとき必要です。 --johotogoshinentai 2012年2月3日(金) 20:20

  • 機械生成されてから、ユーザーによって編集されたことがないグリフ(つまり「簡易調整」が必要なグリフ)を確認できる機能があってほしいです。機械生成されたグリフは、バランスがおかしい場合もあるので、そんなグリフを確認できると、グリフを直すのが易くなりそうです。 --johotogoshinentai 2011年4月27日(水) 16:30
    • すみません、ご要望を確認していたのですが、反応していませんでした。追加します。--kamichi 2011年5月7日(土) 19:20

  • 「左下 GT 用」を追加したのはよいですが、現在の肉付け(ゲタを短くしただけ)は一般的な中国式の左下形状と違うんぢゃないでしょうか。「右上カド」を 180° 引っ繰り返した形を取る筈ですよね。それと名称について、縦画と横画を一画で続けて書かない場合は中国式デザインでも通常の「左下カド」を用いるので、少し紛らわしい気がしますが、まあ巧い名前は思い付かないし、しかたないのかも知れません。— sayunu 2010年11月25日(木) 22:33
    • そう言えばこの件についてお考えを伺っていなかったのですが、「左下 GT 用」の形状についてどう思われますか。— sayunu 2011年10月6日(木) 22:43
    • 現状のta2 = 313 (a2 = 13, opt2 = 3) では、衝突判定で左下カドのゲタが短くなった場合にもta2 = 313になってしまうので、もしかしたら、「左下 GT 用」の形状を変えるのに支障が出るかもしれません。 --hanubeki 2011年11月2日(水) 17:26
    • 情報ありがとうございます。大分前に見た肉付けエンジンの中身はよく憶えてないけど、普通の左下カドが短くなった場合と同じ形状しているって事ですかね、多分。変える為には別のやり方で肉付けをする事になりますね。上地さんはどう思ってらっしゃるんでしょうか ? — sayunu 2011年11月4日(金) 00:08
    • 詳細にG書体の形状をまとめずに、短絡的に用意したのが左下GT用でしたので、実際の「右上角ひっくり返した形」は把握していませんでした。別の議論としてT書体の「口」の右下形状など、J以外の書体の細分化を追求するかどうか、個人的には否定的です。できれば、平成明朝体(規格票以外の文字情報基盤整備事業のドキュメントの大量のグリフ集合も含めて)をJ書体形状の規範として、そこに現れない形状はサポートせず、としたいところですが、そうもいかないとも思っています。--kamichi 2011年11月4日(金) 09:33

  • ドキュメントページでフォントあるいは言語情報を指定できるとよい --kamichi 2010年11月20日(土) 09:56

  • 部品エディタのIDSからの部品列挙にCDPも入れるべき --kamichi 2010年11月3日(水) 22:22

  • グリフを編集したときにそのグリフが部品として引用されていたら、「古い部品を引用しているグリフの一括更新」のページが表示されるようにしてほしいです。 時々更新し忘れちゃうので。--daekyo 2010年9月15日(水) 00:17
    • すみません、検討します。--kamichi 2010年11月3日(水) 22:22

  • RSSフィードも多言語が必要か? --kamichi 2010年8月10日(火) 00:20

  • Arial Unicode MSのような、中韓のグリフも一緒に収録したフォントを生成できるようにならないでしょうか。収録されていても今まではDTPアプリケーションくらいしか使い道がありませんでしたが、Minefieldに最近投入された「-moz-font-language-override」CSSプロパティで実際に使えるようになりました。ただし今のところデフォルトでは有効にされておらず、about:configで「gfx.font_rendering.harfbuzz.level」を1に設定する必要があります。Arial Unicode MSの中韓グリフは実際に認識することを確認しています。
  • IVDがあれば上記ほど重要ではないですが、「-moz-font-feature-settings」で'jp90'などのタグもフォントに含まれていれば利用できるようになりました。こちらはメイリオで確認済みです。--emk 2010年7月18日(日) 23:14
    • Arial Unicode MSのG,T,Kデザイングリフについては、面白いと思いつつ、どうやって使うのか疑問に思っていました。ブラウザで使えるようになるといいですね。グリフウィキはJ欄以外はあまり収録率が高くないですが、対応することは面白いと思います。また他地域欄拡充のモチベーションを上げる意味でもよいと思います。そうなると意外とすぐに「64kの壁」に到達してしまいますね。そろそろ分割の方針を固める必要がありそうです。--kamichi 2010年7月18日(日) 23:26
    • もしご存知でしたら教えてください。Arial Unicode MSは、Kを'salt'、Gを'smpl'、Tを'trad'のテーブルで用意していますが、このやり方でいいのでしょうか。また、1つの符号位置に対して3地域合わせて1つの代替グリフしか用意していないのですが、これは理由があってそうしているのでしょうか。たとえば「骨」であれば、JとGは区別したいですがTも区別したいと思います。このようなことはできるのでしょうか。--kamichi 2010年7月18日(日) 23:48
    • 間違えました。上記質問の前半ですが、'locl'の'hani(KOR,ZHT,ZHS)'以外にsalt,smpl,tradの'dflt'もついているのですが、必要なのでしょうか?--kamichi 2010年7月19日(月) 00:13
      • とりあえずArial Unicode MSと同じテーブルの作り方によるテスト用フォントでGTJKの4種をうまく書き分けできました。取り込みたいと思います。--kamichi 2010年7月19日(月) 01:05
    • 自己解決されたようですがいちおうコメントしておくと、salt,smpl,tradはfont-feature-settingsでjp90などと同じように使います。loclをlangSys別に用意しておけば言語の指定に応じて自動的に切り替わるはずなので、そういう意味では不要だと思います。smpl,tradはJとCで置換ルールを変えたくなるはずですしsaltがKグリフに限定される理由もないはずなので'dflt'にあるのはむしろ微妙かも。
    • U+9F9CなどはArial Unicode MSでも4種類あるようなので、3種類以上の切り替えにとくに問題はないはずです。--emk 2010年7月19日(月) 13:40

  • 曲線も直線と同様に周囲に合わせて細くなりませんでしょうか。u20978など、どうしても窮屈になってしまします。又、同時に右はねも小さくなりませんでしょうか。u8b80こういう場合突き抜けてしまします。--tokume 2010年3月31日(水) 12:44
    • 機能改善事項には入っているのですが、まだ手がつけられていません。もう少々お待ちください。--kamichi 2010年3月31日(水) 13:23
    • まだ更新していませんが、u21569のようなグリフまで右はねが小さくなってしまいます。--mandel59 2010年9月12日(日) 21:06
      • ご指摘ありがとうございます。ちょっと粗すぎるようで、要調整です。学期が始まってしまったので、いつ直せるか見通し不明です。できれば更新して目立つとありがたいのですが…、無茶言ってます。--kamichi 2010年9月12日(日) 22:26

  • 専用エディタで、縦払いではじめの3点が1直線状に並んでいない時にメッセージを出してほしい。(第二制御点のところで亀裂が入るので)

  • 四つ要望させていただきます。
  • 一つ目。u28668のような折れの場合、上はねを選択すると表示がおかしくなります。(tomomo_mysandbox@75)koseki-030010のデザイン修正をしたいので、お願いします。
  • 二つ目。一括更新の際、滅茶苦茶な位置補正がされた場合に、何らかの形で補正された値を取得して、リバートできるような機能があればいいなと思っています。
  • 三つ目。検索ワードに「User-talk:kamichi」,「利用者-会話:kamichi」などと入れて検索しても、上部リンクが灰色になっています。「利用者-会話:kamichi」の場合は、検索結果が何も出ません
  • 四つ目。とりわけ重要ではありませんが、大漢和補巻の前後の番号機能が無いようです。大漢和番号と併せて、機能追加したほうがいいと思います。以上です。--tomomo 2010年2月15日(月) 17:17
    • 1つ目と4つ目に対応しました --kamichi 2010年8月9日(月) 19:16
    • 3つ目に対応しました。--kamichi 2010年8月10日(火) 00:31

  • 一度話題になっていたと思いますが、曲線の右撥ねの角度は固定した方がいいですよね、やはり。私は今は複曲線の二つ目の制御点の縦座標を終端と揃えて一応固定していますが、この場合の角度より少し外側に傾けた辺りで固定するのがいいと思います。撥ねの根本から少し外側にずらした方がいいかも知れません。— sayunu 2010年2月6日(土) 19:08
    • 曲げと同じ形状で固定するように変更しました。角度はどうでしょうか?(エディタは未対応(明日以降)で、プレビューのほうが対応しています) --kamichi 2010年8月9日(月) 19:29
    • 撥ねの角度について。目安としては、撥ねの先端が、トメの部分の半円の右端と揃うぐらいにすると大体良いのではないかと思います。話を簡単にする為に「固定」という提案にしましたが、更にこだわるならば筆画の傾きによって多少は変動する(筆画が緩やかなら撥ねは上に向き、筆画が急なら少し右へ倒れて行く)のが理想的な様に思います。例えば平成明朝の〈代〉と〈風〉みたいな具合です。どの辺が適当か調整が微妙だし、しなくても許容されるでしょうけど。— sayunu 2010年10月2日(土) 00:41
    • ご意見ありがとうございます。「撥ねの先端が、トメの部分の半円の右端と揃う」の右端というのは、その筆画の最終部分に垂直な、半円の右端に接触する直線、ということでしょうか。現状ではもう少し外側ということですよね。--kamichi 2010年10月2日(土) 11:11
    • ええと、私の考えは、撥ねの先端を通ってトメの半円に接する直線を引くと、それが垂直になるくらい、という意味です。現状より少し右へ倒す事になります。— sayunu 2010年10月9日(土) 22:53

  • カカトって呼ぶんでしょうか、例えば「口」の右下と左下のカドで縦画が下に突き出すところ、左右の長さを同じにした方が扱い易いのではないかと思います。今は左下が右下よりも長くなっていますが、どちらも右下ぐらいの長さに揃えてはどうでしょうか。「門」@1 u9580@1 などでは、長さを揃えるためか、わざわざカドとしての接続を外してあるようです。 — sayunu 2009年8月13日(木) 23:27
    • グリフウィキで利用しているKAGEは、字形をなるべく抽象的に表現することを目的としているので、u9580@1のような見た目を優先するために接続を外すようなやり方はNGです。肉付けエンジンの修正を要望とする方向が望ましいです。さて、このカカトについては問題点は認識しています。「口」のようなカカトの長い文字をベースに設計してしまったのが問題で、過去において少し短くなるような変更をしたのですが、まだダメなようですね。長さを同じにする、というのは極端かと思いますが、もっと短くしてほしいというご意見として承りました --kamichi 2009年8月14日(金) 13:22
    • きちんとカドとして接続してある u9580@3 が自然に見えるような具合の調整をよろしくお願いします。 — sayunu 2009年8月14日(金) 22:05
    • 手持ちの明朝体フォントを観察したところ、MS 明朝はちょっと拡大すると明らかに左下カドの方が長いですが、IPA 明朝、平成明朝体などは巨大に表示して水平線を引いてみないと分からないくらいの差だし(厳密には数値で比を出すべきでしょうけど)、ヒラギノ明朝に至っては右下カドの方が少し長いです。左右を同じにするのが極端といった感じは私はしないのですけど。 — sayunu 2009年8月14日(金) 23:53
    • 加えて、「門」に関しては、例に挙げた四種類のフォントでいずれも左側(右下カド)を長くしているようです。 — sayunu 2009年8月15日(土) 00:08
    • でも、「叩」「峠」などのように偏の部品では、確かに左下カドを長くしますね。偏の下端は右上がりにする、っていうことの一環なんでしょうけど。どうすればいいんだろう…。ここが右上がりでないとおかしいでしょうか? — sayunu 2009年8月17日(月) 00:14
      • 一つ言い忘れていました。KAGEエンジンは箱左下角が長く、箱右下角が短く、の形状しか持っていません。ですので(1)「門」などのケース向けに箱左下角が長くならない形状を新設する(2)いっそのこと全ケースにおいて左と右の長さを合わせる(3)あきらめる、のいずれかになると思います。1番が妥当でしょうか。
      • 直接関係ありませんが、KAGEエンジンにおいてカカトの長さを調整する仕組みを追加しました。--kamichi 2009年8月26日(水) 14:24
    • 私としては左右のカカトの長さが揃っていても問題無いと思うので (2) なんですけど、「カカトは左の方が長くなきゃ明朝体ではない!」って言う人が居たりするんでしょうか。
      • 私の幻想かもしれませんが、設計当時に多くの明朝体がそうだと思ったので右ならえした結果です(厳密には多く、ではなくMS明朝が、だったかもしれません)。--kamichi 2009年9月3日(木) 21:20
    • 少し別の話ですが、他の筆画に反応してカカトが短くなるのは、現在はカカトの真下で「短くしないと衝突する場合」だけですが、もっと縦横の広い範囲に反応した方がデザイン上すっきりすると思います。例えば u610f@8 の「日」の左カカトは「心」の間に突っ込んでますが、引っ込んでほしいです。具体的には、カドの点から真下に50 ピクセルぐらいと、その左右に各 70° ぐらいの扇形の範囲です。(厳密な数値ではないです。)
    • 一般的な明朝体で際立って左カカトが長くなるのは、左側で小さめの部品(口ヘンなど)だと思うんですが、上記の引っ込み方だと右側部品に接近した右カカトが短くなってくれるので、それが再現されます。
      • 現状ではカカトカットの範囲はX方向は20固定です。もう少し凝ったほうがいいですね(なお、これはKAGEエンジンの方が検討対象です。kage.jsがその部分です)。--kamichi 2009年9月3日(木) 21:17

  • エディタで部品検索をする際に、原規格分離などがなければ本来包摂されていたペア(刃刄・即卽・既旣・食飠・眞真・吳吴呉などなど)についてはどちらも表示してほしい。--mashabow 2009年7月23日(木) 13:04
    • 恐れ入りますが、刃刄・即卽は出ると思います。元データのIPSJ TS-0008ではすべて取り込んだはずなので、取りこぼしはないと思いますが…。一つ具体例を挙げていただけると幸いです。--kamichi 2009年7月23日(木) 22:51
      • 例えば「⿰糸刄」(aj1-20188, u7d09-ue0101)を作ろうと思って「u7d09」で部品を検索した場合、「刃」は出てくるのですが「刄」が出てきません。--mashabow 2009年7月23日(木) 23:05
    • 具体例ありがとうございます。「刃」で調べると「刄」がでるところまではできていて、孫引きができないということですね。思うに、1つのキーワードに対して孫、ひ孫と大量に出すのではなく、候補を右クリックしたら(実際は右クリック検出はできないので別のやり方が必要ですが)それをキーワードに再検索、のような仕組みに変えたいと思います。--kamichi 2009年7月23日(木) 23:10


過去の分についてはGlyphWiki:ソフトウェアへの要望-保存を参照してください。