GlyphWiki logo
导航
帮助
搜索

工具箱
其他语言
文章讨论编辑历史

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

字形维基(GlyphWiki), 自由的字形数据库

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

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


異体字関係の表示についての提案

GlyphWikiにおける異体字の表示について、以下の2点を提案します。

(1)漢字データベースプロジェクトのデータの非表示機能

異体字関係のデータの多くは漢字データベースプロジェクトに基づいていますが、漢字データベースプロジェクトには不適切と思われる異体字関係が存在します(例えばu5316u2b049u95d1u2b539など)。

こうした異体字関係を表示しないようにするため、GlyphWiki:関連付けるべきでない符号位置を用意して、そのページに記載のある異体字関係はグリフページに表示しないようにすることが望ましいと思います。

記法は通常の異体字関係と同様に、

のようにすればいいと思います。

なお、文字によっては「戸籍統一文字」は消したいが「民國教育部」は残したい、といったニーズもあると考えられます(例えばu379bu21c79、戸籍統一文字の字形はkoseki-088000=u21c8f)が、こうした場合の記法については未定です。--kesuuko 09:22, 19 January 2024

(2)「〓」を含む異体字関係は非表示にする

GlyphWiki:関連付けるべき符号位置にユーザーが登録した異体字関係はグリフページで表示されますが、「〓(u3013)」を含んだ異体字関係を登録する(GlyphWiki:関連付けるべき符号位置-UCS互換@4のように)と、関連字が「〓(未設定)」のグリフが大量に表示されようとしてしまうと思われます。

こうした挙動は荒らしが悪用する可能性が高いので、「〓」を含む異体字関係は非表示にする方がいいと思います。--kesuuko 09:22, 19 January 2024

OGPによるプレビュー画像表示への対応

OGP(Open Graph Protcol)という仕組みを使うと、SNSでWebページをシェアした際のプレビュー画像(サムネイル)やタイトルを設定することができます。現在、GlyphWikiの各グリフページにはこれらが設定されていませんが、字形をSNSで手軽にシェアするというのはGlyphWikiの典型的な使い方なので、設定したほうが良いのではないかと思います。幸い、各グリフの画像ファイル(png)は既に生成されているので、
<meta property="og:image" content="https://glyphwiki.org/glyph/sandbox.png" />
のようなmetaタグを各ページに動的に(←一応、ここは多少工数のかかるところではあるかもしれませんが)追加するだけで対応できます。正しく設定できているかは https://rakko.tools/tools/9/ などで確認できます。参考までに、自分のサイトで勝手に実装してツイートしてみました。https://x.com/e9g/status/1734591485319032839?s=20
  • (↑署名を忘れておりすみません、turgenevです)
  • ついでに言えば、現状のpng画像は白黒に2値化されており、最大サイズでもギザギザが目立ちます。別の原因があるかもしれませんがGlyphWiki:バグ報告にもあるような不自然な形状になっている場合もあります。データ容量を少しでも削減したいといった特段の事情がない限りは、グレースケール(256段階)のpngを使用するほうが扱いやすいのではないかと思いますが、いかがでしょうか?--turgenev 2024年1月17日(水) 23:28

  • すみません、導入に賛成なので、近々に着手したいです。それとPNGについてですが、現状で2値にしているのは、ワードなどに張り付けて印字した際にグレースケールだとぼやけて文字として読みにくい(と認識している)ためなので、これが改善されないのであれば基本的には多値化に反対です。両方生成する、というのも現状でファイル数が膨大になっているので、難しいです。--kamichi 2024年1月18日(木) 13:26
  • OGPの対応について、ありがとうございます。PNG画像に関しては、たしかに2値のほうが使いやすい場面もありそうですね。承知しました。--turgenev 2024年1月18日(木) 20:21

  • 試しにmetaタグを出力するように更新しました。--kamichi 2024年2月11日(日) 14:51

UCSに関する命名に対する関連字の強制について

GlyphWiki:関連字において、UCS関連グリフはそれに対応する符号位置のみを関連字とすることができると規定されています。しかし、UCSの符号位置に対応する命名であっても、次に挙げる命名については他の漢字やゲタを関連字とすることができてしまいます。これらの命名についても、対応する符号位置のみを関連字とすることができるようにしていただけないでしょうか。--kesuuko 12:45, 16 November 2023

命名意味
u****(*)-sUnicode Sソース
u****(*)-kpUnicode KPソース
u****(*)-ufe0*Unicode SVS
u****(*)-ue01**Unicode IVS

  • すみません、ご要望を以前から承っておりますが、作業タイミングの問題で滞っています。秋口は最繁忙なので…、ちょっとまだ時期をお約束できません。--kamichi 2023年11月16日(木) 17:11
    • その他、以下に挙げる命名についても対応をお願いします。--kesuuko 10:06, 1 February 2024

命名意味
u****(*)-jnUnicode 正規化Jソース
u****(*)-itaiji-***Unicode itaiji命名

  • (s|kp|fe0*|e01**|jn)について、新規作成時の関連字が自動設定となる様に変更しました。また(s|kp|jn)について、保存不可(プレビューに移動)としました。itaijiとvarについては変更の影響が(記憶をさかのぼる必要があり)不明なため保留としています。--kamichi 2024年2月11日(日) 14:04

(non title)

  • 部品の一括更新に、「座標を変更せず部品のみを置き換える」機能があってほしいです。この機能を使うと、変わるのは部品の名前だけです。部品の微調整をしたときなど、部品の座標をそのままにしたいとき必要です。 --johotogoshinentai 2012年2月3日(金) 20:20
    • 私も強く賛成します。--kesuuko 20:04, 21 October 2023
      • その他、「自動調整を行わず、元の座標から単純に加算・減算した座標にする」機能もほしいところです。--kesuuko 20:06, 21 October 2023
    • 過去に自分が類似の投稿をしていたのでこちらに統合しておきます。--turgenev 2023年10月22日(日) 17:06
      • 「部品の一括更新」(MustrenewではなくRenewall)に関して、部品を配置する場所を変えたい際、現在は(縦横それぞれで)「座標の増減を定数値で指定」「座標を直接指定」の2種類しかありませんが、ここに「座標の増減を元の部品サイズに対する相対比率で指定」を加えていただきたいです。
      • 具体的には、例えば"-50%,0%,50%,0%"のように指定すると、始点X座標と終点X座標が元の部品のX方向サイズに対してそれぞれ-50%、+50%増減し、結果としてX方向にのみ部品のサイズが(中心位置を保ったまま)2倍になる、という感じです。 この機能があれば、部品を(内部のバランスを変更せずに)縦横に移動させたり拡大縮小変形させたりしたときに、旧バージョンを使用しているグリフの見た目を変えずに一括更新できるようになります。 現行の「座標の増減を定数値で指定」方式だと、部品のサイズが小さい場合に変形の度合いが大きくなってしまいます。--turgenev 2022年10月4日(火) 16:25

UnicodeのSソースやKPソースのグリフを作成する際に関連字が自動入力されるようにしてほしい

UnicodeのSソースやKPソースのグリフを作成する際、関連字がデフォルトで入力されるようにしていただけないでしょうか。Unicodeの他のソースでは問題なく関連字がデフォルトで入力されるようになっています。--kesuuko 19:28, 11 October 2023

GlyphWiki:関連付けるべき符号位置の分割について

GlyphWiki:関連付けるべき符号位置の分割として、Ext.Cに対応するGlyphWiki:関連付けるべき符号位置-ExtC、Ext.Eに対応するGlyphWiki:関連付けるべき符号位置-ExtE、Ext.I(今年9月に符号化予定)に対応するGlyphWiki:関連付けるべき符号位置-ExtIに対応していただけないでしょうか(GlyphWiki:関連付けるべき符号位置-ExtI以外は現在未作成ですが、対応次第作成予定です)。--kesuuko 05:27, 30 August 2023
  • ご提案ありがとうございます。追加しました。--kamichi 2023年8月30日(水) 08:06

花園明朝のグリフ数が溢れる問題について

花園明朝のグリフ数が溢れる問題ですが、私はこの問題に「同一の形状をもつ文字が複数のグリフに割り当てられてしまう」ことが関係すると考えています。
  • 例えば、字表:kesuuko_sandbox7@12のフォントの場合、くさかんむりのグリフはu8279ufa5dufa5eの3つで十分なはずですが、このフォントでは12個のグリフが割り当てられてしまっています。
    • これによってフォントに含まれるグリフの数が無駄に増えてしまっていると考えられます。この問題を解決すればフォントに含まれるグリフの数を削減することができ、結果として花園明朝のグリフ数が溢れる問題の解決に繋がると考えられるので、早急な対応をお願いします。
      • この問題の解決策として、私は「同一の字形かつ同一の文字幅のグリフが複数のコードポイントに収録される場合、1つのグリフに複数のコードポイントを割り当てる」ことで対応できると考えています。
    • 以上。--kesuuko 00:21, 22 December 2022
  • 私もこの件に関しては興味を持っていて、未だに詳細がわかっていないのですが、うまく統合されているものとされていないものがあるようです。
    • GlyphWiki:グリフウィキについてなどに記載の通り、花園フォントのリリース版の生成では、IVSの割り当てにTTXという外部ソフトウェアを使用しています。したがって最終的にリリースされるフォントはグループページで生成されるものとは構造が異なります。リリースされている最新の花園明朝AをFontForgeで開いてU+8279(u8279)の「グリフ情報」を見てみると、"Alternative Unicode Encodings"のところにU+8279-U+E0101とU+8279-U+E0105が記載されているため、この3つはうまく統合されていて無駄なグリフを消費していないようです(統合の判断はGlyphWiki上でエイリアスになっているかどうかで判断しているのでしょう)。
    • 一方で、CJK統合漢字ではなくCJK部首補助ブロックに所属するu2ebeは完全に別グリフになっています。また、同一字形(GlyphWiki上エイリアス)のIVSグリフ同士であっても重複して収録されているもの(例えばu4f34-ue0101u4f34-ue0103など)もあります。
    • 見た感じ、おそらく「自らの異体字シーケンス部分を除去したUCSグリフのエイリアスになっているIVSグリフ」のみが、いわばUCSグリフに「寄生」するような形で統合されているのではないかと思います。「寄生」できるUCSグリフを持たない同一字形のIVSグリフ同士(先ほどのu4f34-ue0101u4f34-ue0103)、あるいは別のコードポイントを持つUCSグリフ同士(先ほどのu8279u2ebe)は統合されないということになります。
    • 実際、字表-讨论:花園フォントの「参考:HanaMinA 64,377程度」のIVDの項目にある数字(10211など)や、花園フォントのリリースページ( http://fonts.jp/hanazono/ )にある数字("8,828字が追加異体字")は、統合が全く行われていないにしては少なすぎる数字になっています。
    • したがって、現在統合されていない文字同士を統合することで一定の効果は挙がると思いますが、劇的に余裕が出ることはないのではないかと思います。
    • 手元での集計だと、AJ1の漢字CID( https://github.com/adobe-type-tools/Adobe-Japan1/blob/master/README-JP.md )(重複が3文字あり、ルビ用の注aj1-12869含む)で14664個、それと重複しないCJK統合漢字(拡張A-H含む)・康煕部首・CJK部首補助・CJK互換漢字・CJK互換漢字補助があわせて84870個、さらにそれと重複しないIVS(Hanyo-Denshi, Moji_Johoなど)が7616個などとなっています。(収録の優先順位なども加味して、もうちょっと詳細な分析をしたいところです。)
    • ここまで--turgenev 2022年12月22日(木) 16:05
    • 上記の集計について追記です。まずAJ1のIVSを完全収録するのに必要なのは(ルビ用の注を入れるため)14664ではなく14665でした。優先順位を変えて試したところ、そこに他のIVSコレクションを加えるのに+9631グリフ、CJK統合漢字を加えて+8233グリフ、康煕部首及びCJK部首補助を加えて+44グリフ、CJK互換漢字を加えて+79グリフ、CJK互換漢字補助を加えて+261グリフ、拡張Aを加えて+5999(ここまでで38912)、拡張Bを加えて+33382(ここまでで72294)…という感じになりました。--turgenev 2022年12月22日(木) 16:41
    • すみません、「グループページで生成されるものとは構造が異なります」の部分は私の勘違いでした。グループページのものもリリースされている花園フォントと同じような状態になっているようですね。--turgenev 2022年12月22日(木) 16:45
    • なお私は主に自作の改造エンジンを使ってフォント生成をしていて、そこで使っている3次ベジェ曲線に対応するためCIDキー方式・PostScript形式のOpenTypeを主に扱っているので、TrueType形式のフォントについてはあまり詳しくありませんが、 https://itouhiro.hatenablog.com/entry/20141004/font やkesuukoさんのフォントからttxで取り出したcmapテーブルなどを見る限り現状で重複して収録されているグリフを統一するのは特に問題なくできそうに見えます。--turgenev 2022年12月22日(木) 17:01
    • 「CJK統合漢字+CJK統合漢字拡張A+CJK互換漢字+CJK互換漢字補助+康煕部首+CJK部首補助」だけでカウントしたものと、そこにIVSを加えたものを比較すると差は10603でした。これは最新のUnicode15.0及びIVDの2022-09-13のデータを使っているので少し増えていますが、最新の花園明朝と同じくUnicode10.0.0とIVDの2016-08-15のデータを使った場合でもこの値は10057でした。花園フォント関連ページの10211や8828といった数字は何か間違いがあるような気もします。
    • 花園フォントAに関しては外字の内訳がよくわかりませんが、FontForgeで見る限りF137~F6B0の間だけとすると1402個しかないので、http://fonts.jp/hanazono/ の通りに非漢字(9806)+CJK統合(20902+69)+拡張A(6582)+CJK互換(472)+CJK互換補助(542)+IVD(8828?)+外字(1402?)と足しても48603にしかなりません。ページには花園フォントの収録文字数は51991と書かれています(FontForgeで開くとnotdef覗いて52007に見えます)が、それより3400個ほど少ないです。従って、実際にはIVSは8828ではなくそれに3400を足して12232グリフくらい消費しているかもしれません。
    • 総じて、今の花園フォントで完全な同一字形が重複して収録されている個数は、(12232-10057で)2000前後くらいなのではないかと思います。--turgenev 2022年12月22日(木) 18:44
      • グリフの統合について、私は非漢字(例えばu0041u0391u0410)も対象にすることを想定しているので、節約できるグリフの数はもう少し多くなると思います。--kesuuko 19:55, 22 December 2022
      • 私は「実際にはIVSは8828ではなくそれに3400を足して12232グリフくらい消費しているかもしれません。」の文は誤っていると考えています。この差分は字表:SourceHanSans-nonBMPなどによって収録されているSIPの漢字に由来すると思われます。--19:55, 22 December 2022
    • 以下返信です。
      • 非漢字については考えていませんでした。どれくらいあるかわかりませんが、ある程度は減らせそうですね。
      • 字表:SourceHanSans-nonBMPに関しては全く認識していませんでした。(趣旨がわからなかったのですがノートページを読んで理解しました。)これも集計時に利用してみます。
      • 字表-讨论:花園フォントのHanaMinAの表のうちCJK部首補助、康煕部首、拡張A、CJK統合漢字、互換漢字、互換漢字補助、IVS("IVD-SIPベース文字"と"IVD")を全て足すと40460になります。同じ文字集合をこちらで集計したのが前述のように38912であるため、1548個節約できることになります。
      • この「"IVD-SIPベース文字"」というのがどういう意味なのかよくわからないのでご存じの方がいれば教えてください。
      • ちなみに、前述の外字1402個はここに書いてあるCDP外字の数と一致しているので正しそうです。--turgenev 2022年12月22日(木) 21:28
      • 「IVD-SIPベース文字」は、文字通りIVDの基底文字となるSIPの漢字のことです。異体字セレクタのついた文字をフォントに収録する場合、対応する基底文字をフォントに含めないとフォントの生成に失敗してしまいます(字表:kesuuko_sandbox7@13)。--kesuuko 22:56, 22 December 2022
      • 理解しました。ありがとうございます。となると、それも数え忘れていたことになりますね。(ここまでの話を総合して、忘れていたのは字表:IVD-20120302-SIP-ベースコード字表:IVD-MSARG-SIPベースコード字表:IVD-MojiJoho-SIPベースコード字表:SourceHanSans-nonBMP字表:AfterNormalization-nonBMPの5グループにあたるものということで合っているでしょうか。)といっても、現実にはどのIVSグリフとも同一字形でない基底文字はあまり多くないような気もするので数十個~数百個程度の差になるのでしょうか。いずれやってみます。
      • 花園明朝AではなくB(やC)の話になりますが、ここで収録される基底文字の分を拡張B-Hとして重複して収録することをやめれば多少の節約ができそうですね。--turgenev 2022年12月22日(木) 23:33
      • 上記の議論で必要と判明したグリフを入れて改めて集計しました。以下の表の通りです。なお、昨日からの議論で使用しているdumpデータはすべて2022/12/22の2:00のものです。
追加するグリフ追加個数累計
AJ1の漢字(+ルビ用の注)1466514665
AJ1以外のIVS963124296
メインのUCS※1461638912
互換漢字(補助)SVSの基底文字5238964
IVSの基底文字22139185
SourceHanSansに含まれるUCSコードポイント185541040

※メインのUCS…統合漢字、統合漢字拡張A、康煕部首、CJK部首補助、互換漢字(補助)2ブロック

      • SVSの基底文字が「IVD-SIPベース文字」の念頭にあるのかわかりませんが、数も少ないので入れるとすると、40460-39185=1275文字は節約できます。--turgenev 2022年12月23日(金) 22:07
    • 別件で、是が非でもグリフを節約するためということであれば、差異の少ない異体字を統合することは可能に思えますが、どうなんでしょうか。やり尽くされた議論かとは思いますが…
      • 例えばAJ1のIVSなど、字形の違いというよりは規格票のデザインに忠実であることを意図した結果として無印のUCSグリフと異なるデータになっているものはそれなりにあると思います。
      • 字表:turgenev_異体字シーケンス・Adobe-Japan1に関する矛盾にあるu91d3-ue0100u91d3などが一例です。
      • 規格票デザインもデータとして重要だと思うので字形自体はこのままでいいと思うのですが、グループページで置き換えを指定するといった戦略はアリかもしれません(既にあるのかもしれませんが)。--turgenev 2022年12月23日(金) 22:07
      • 字表:kamichi_備忘録の「字体差データベースについて」の項目に、関連する内容が書いてあるようです(しかしまだ実現してはいないようです)。こちらは統合のためというよりは純粋に字体差を明示するという目的かもしれませんが。
      • メタ情報やグループページ以外だと、例えばu91d3-ue0100-alternativeというような名前でu91d3のエイリアスを作成するようなやり方も考えられそうです。--turgenev 2022年12月24日(土) 17:27

Unicode地域ソース字形の命名の判定について

  • Unicode地域ソース字形の命名「uXXXX(X)-Y(Y)」のY(Y)の部分において、-kp(北朝鮮)、-s(大正新脩大藏經)、-uk(イギリス)をソース名として判定してください。--kesuuko 2020年1月11日(土) 00:32

(non title)

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

  • 以下検討します。これ以上ページ生成時のSQLクエリー発行をしたくないので、スキップは若干優先度を下げます。--kamichi 2019年5月22日(水) 14:47

関連字を1グリフに2字まで設定できるようにしてほしい

関連字を1グリフに2字まで設定できるようにしてください。irg2015-03152に対する(u7cd6/u42af)のように、必要であると思われるグリフが存在します。--kesuuko --kesuuko 2018年10月28日(日) 15:01
  • さすがにそれは設計思想の修正を伴うので無理だと思うのですが、興味深い実例ですね。すこし考えてみます。--kamichi 2018年10月29日(月) 14:43
    • 符号化された故に既に問題解決ですが、irg2015-03152を対象とするu7cd6u42afの「○○-itaiji-NNN」式エイリアスを作成したら済むのではないか。sz 2020年10月31日(土) 17:02

aj1-命名に前後の番号を表示してほしい

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

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

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

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

字表:フォントに含まれるべきでない符号位置に関して

  • 字表:フォントに含まれるべきでない符号位置に対応することは可能でしょうか。もし可能でしたら、対応はいつ頃になるでしょうか。--kesuuko 2018年7月17日(火) 18:58
    • すみませんが、何がどう対応するのかが把握できていません。またそれを考える時間も現状ありません。もう少し具体的な提案をしてくださると助かります。--kamichi 2018年7月17日(火) 21:18

字表:フォントに含まれるべきでない符号位置に関して(再提案)

  • 再提案ありがとうございます。私の認識では、GlyphWikiにおけるGroupページに列挙したグリフのフォント生成について、その生成対象コードポイントから字表:フォントに含まれるべきでない符号位置に列挙されているものを自動的に除く機能を実装してほしいと解釈しましたが、それで正しいでしょうか?そうすると逆に質問が3つあります。(1)そもそもGroupページに列挙しなければ生成されないのではないか?(2)自動的に除くと困る人がいるのではないか?(3)除きたい人が取り消し機能を使うのと何が違うのか?以上、いかがでしょうか。--kamichi 2018年7月18日(水) 11:22
    • kamichi様の質問にお答えします。まず(1)に関しては、字表:グリフウィキに収録されている非漢字などを引用する場合は、Groupページに列挙しないことは不可能です。また(2)に関しては、本機能をオフにする機能を実装すれば回避可能です。またこの機能は、わざわざ取り消しの記述をする手間を省くための機能ですので、(3)も特に問題ありません。--kesuuko 2018年7月18日(水) 16:07

    • 自動=おせっかい、なので、ちょっと納得できない部分もありますが、それでしたら取り消し対象として別のグループページを引用できるというのはいかがでしょうか。つまり「字表:グリフウィキに収録されている非漢字」と書けば実現できる、というイメージです。これであれば従来のドキュメントにも影響が出ないと思います。--kamichi 2018年7月18日(水) 16:18
      • 賛成です。そうすれば事実上対応と言えると思います。--kesuuko 2018年7月18日(水) 16:42

Group:NegativeCharactersの更新について

  • 字表: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対応済み全角の文字に対して合成

(non title)

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

(non title)

  • 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

(non title)

  • CJK統合漢字拡張FのJソースとなるIPAmj明朝の「酉」の部分字形では,第5画の折れの終筆が縦画に接続しています。例えば,jmj-060255jmj-060256jmj-058887です。u9149-01-var-003u9149-04-var-004のような既存の部品も同様です。現在,「折れ」の尾形状は開放と上ハネしかないため,開放が使われていますが,横に縮小すると突き抜けてしまいます。「接続」があると便利なように思います。 --ziyang 2016年7月11日(月) 21:09
    • どうやらkesuuko_sandbox3@26のように「3:*:32:……」とすると接続扱いになるようです。もっとも、これは正規の筆画ではないようですが……--kesuuko 12:18, 29 December 2021
    • 「3:」は内部では「1:」などの組み合わせで処理されるので、kesuukoさんがおっしゃる通り末端形状「32」番でうまく処理されますね。仕様としてOKと定義すれば、解決になりますでしょうか。--kamichi 2021年12月29日(水) 15:33
      • それで解決すると思います。--kesuuko 13:44, 30 December 2021
      • さっそく、最新の kage-editor で「折れ」の尾形状に「接続」(32) を選べるようにしてみました。( ) ―twe 2022年1月1日(土) 17:06

(non title)

  • 関連字の無いページ(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

(non title)

  • 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

(non title)

  • ストレッチ境界に「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

(non title)

(non title)

(non title)

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

(non title)

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

(non title)

  • フォント生成時の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
      • すみませんが、[u####][u####-g u####]という記述がよくわかりません。字表:test@167字表:test@168で試してみましたが、うまくいきませんでした。 --johotogoshinentai 2014年4月5日(土) 18:48

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

(non title)

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

(non title)

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

(non title)

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

(non title)

  • 今、旧部品引用グリフの数が多いので、「旧部品引用グリフ」ページをロードするのに時間がかかりすぎ、サーバにも負荷を与えていると思われます。分割を提案したいと思います。 --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

(non title)

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

(non title)

  • 「末端にウロコがついている折れ」を表現できるようにしてほしいです,具体的には「折れ」の尾形状に「開放ウロコ付き」を追加してほしいです。現状では「折れ」の尾形状が「開放」と「上ハネ」しかなく,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

(non title)

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

(non title)

(non title)

  • 「左下 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

(non title)

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

(non title)

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

(non title)

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

(non title)

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

(non title)

  • 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

(non title)

  • 曲線も直線と同様に周囲に合わせて細くなりませんでしょうか。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

(non title)

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

(non title)

  • 四つ要望させていただきます。
  • 一つ目。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

(non title)

  • 一度話題になっていたと思いますが、曲線の右撥ねの角度は固定した方がいいですよね、やはり。私は今は複曲線の二つ目の制御点の縦座標を終端と揃えて一応固定していますが、この場合の角度より少し外側に傾けた辺りで固定するのがいいと思います。撥ねの根本から少し外側にずらした方がいいかも知れません。— 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

(non title)

  • カカトって呼ぶんでしょうか、例えば「口」の右下と左下のカドで縦画が下に突き出すところ、左右の長さを同じにした方が扱い易いのではないかと思います。今は左下が右下よりも長くなっていますが、どちらも右下ぐらいの長さに揃えてはどうでしょうか。「門」@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

(non title)

  • エディタで部品検索をする際に、原規格分離などがなければ本来包摂されていたペア(刃刄・即卽・既旣・食飠・眞真・吳吴呉などなど)についてはどちらも表示してほしい。--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:ソフトウェアへの要望-保存を参照してください。