GlyphWiki logo
導航
幫助
搜索

工具箱
其他語言
用戶頁面討論編輯歷史

用戶-對話:turgenev

字形維基(GlyphWiki), 自由的字形數據庫

近況・意見陳述(?)

  • ひととおりの目的は達成したのと方針を決められないため本質的な作業はここに書いてある状態からはほとんど進めていません。
  • (私がgitを用いた変更の管理に熟達していないのもあって)現状ですぐに自分のエンジンを使用することはできないと思います。用戶:kamichiにも「整合性をどう担保するか」との指摘があります。
  • 自分の改変にかぎらずKAGEエンジン、花園明朝のグリフに関する最大の懸案は(特に漢字用のストロークをイレギュラーなかたちで使用している)非漢字グリフだと思います。過去の議論としてはGlyphWiki:井戸端-保存2012年までの「非漢字グリフについて」やGlyphWiki:井戸端-保存の「グリフウィキで共有したい漢字(文字)とは何か」があります。つい最近のものでは用戶-對話:kamichiの冒頭もあります。適宜引用します。
  • KAGEエンジン・GlyphWikiの大きな特徴は、複数のグリフを組み合わせたグリフを管理するシステム(及びそれを維持管理するコミュニティ)があることだと思います。これによって漢字を(比較的)低コストで統一的にデザインすることができています。
    • 平仮名やラテン文字、数学記号のような非漢字ではこのメリットを享受することはあまりできず、漢字用のストロークしか使えないデメリットが目立つことになります。
    • 一方で(特に漢字を使った)囲み文字や、ハングルなどの部品の組み合わせを含む多言語の文字・記号については、GlyphWikiの(ような)システムで管理したいというモチベーションがあります。
    • ただ、組み合わせで記述できるとはいえ本来は漢字のストロークが使えない文字まで同じシステムで管理しようとすると、(kamichiさんの)本来の目的からは外れて負担が大きくなってしまうことは考えられます。
      • 例えば、GlyphWiki:井戸端-保存2012年までにある通り、パスデータを自由に登録できるようにすると「ライセンス違反のデータを受け付けやすくなる」という問題があります。またGlyphWiki:井戸端-保存では政治的問題のあるグリフに関する懸念が表明されています。
  • 別の問題として、「フォントとしての利用価値」を考える必要があるという点があります。すなわちGlyphWikiの成果物を一般に使ってもらうにはフォントという形をとることになり、そのためには(ひらがな・ラテン文字・記号を含む)一定の文字集合をカバーする必要が出てきます。
  • まとめると、今ある大きな課題・目標としては「漢字といえるものはできるだけ幅広くカバーしたい」「漢字のデザインは改善したい(その一例が曲線データ)」「フォントとして利用しやすくしたい」「(フォントとしての統一感の観点から)漢字を使った組み文字はGlyphWikiのデザインを使いたい(そうなると組み文字用の丸や四角もすべて統一したい)」「GlyphWikiのシステムが活かせるなら非漢字にも手を出してみたい」「でも非漢字に(法的問題含む)余計なコストをかけすぎたくはない」(そして個人的には「ゴシック版エンジンも活かしたい」があるのですが…)あたりになると思います。
    • そうすると、GlyphWiki:井戸端-保存2012年までにある通り「等幅の線と数種類の幾何学模様を使えるようにする」という「ホワイトリスト」的なアイデアは現実的にコスパが良く、多くの問題を解決に導けるのではないかという印象です。法的な問題がほぼ心配なく、組み文字に対しても(白抜き文字の対応などは自明ではありませんが)現在のGlyphWikiのシステムが上手く活かせます(現状でも単純な丸などは一見それほど不自然でない形でデザインできてはいますが…)。
    • ゴシック体にもかかわる話なのですが、FontforgeやInkscapeにもあるような、曲線・複曲線の端点が直線状につながるように自動で調整されるインターフェイスがあると、対応できるストロークが大きく増える気がしています。
    • フォーマットは考えていませんが、いずれにしろKAGEエンジンの漢字(明朝体)に関する部分をいじらずに追加することができると思います。
    • 丸や四角よりもっと複雑な(「等幅の線と数種類の幾何学模様」でデザインできない)図形を含む記号もありますが、それらについては「フォントとしての統一感」を気にする必要のない場合が多そうです(例えばu266cのようなイメージです)。そうなると、フォントとして提供する際には用戶-對話:kamichiの"Kage Console"のように他フォントからグリフを取ってくるという選択肢も取れるようになります。
    • ただ、例えば他フォントのアルファベットをGlyphWikiと同じ丸や四角に入れて組み文字にしたいといったことが技術的・法的にどうスマートに実現できるかといったことは未知数です。フォント生成時(GlyphWiki内の機能ではなく、花園明朝をビルドするとき)のみGlyphWiki上のラテン文字等を他フォントの(GlyphWikiのアルファベットと出来るだけ位置やサイズをそろえた)データで置き換えるようなことができると良い気がしますが色々と一筋縄では行かなさそうです。
    • 「非漢字にも手を出してみたい」あたりについては、GlyphWikiのユーザーでも様々に意見があるところだと思います。場合によっては、GlyphWikiと全く関係なく「不特定多数の有志が共同でフォントをデザインするサイト」があってもいいのかもしれません。
    • いずれにしても、各論点について必要な知識が大きく異なってくるので、「漢字字形・デザイン」「記号向けストロークの追加」「ハングル等の"部品の組み合わせをもつ非漢字の文字体系"について」「花園フォントの生成・他フォントの取り込み」あたりに分けて議論できるといい気がします。
  • ここまで --turgenev 2021年10月26日(火) 21:10

追記

  • 現状、「実際はGlyphWiki上でなくてもできるにもかかわらずその方法がよく案内されていない」ことが多くて、それが問題を難しくしている気がします。自作グリフのデザインやフォントの生成などは特に公開したいわけでなければローカル上でできるので、そのようなことがもっとやりやすくなるように案内を充実させると良いかなという気もします。
  • 昨日の内容も含めて、自分がある程度貢献できそうなのは
    • 記号向けストロークの設計・実装
    • 漢字向けストロークの設計の(デザイン的ではなく)技術的な検討・実装
    • GlyphWiki外でのKAGEデータ作成・フォント生成(の案内)
  • あたりだと思います。
  • ここまで turgenev 2021年10月28日(木) 20:46

花園フォントの収録文字について

  • 字表-討論:花園フォントなどを読んで考えてみたのですが、なかなか難しいですね。そういえば、CIDキー方式のOpenTypeフォント(AFDKOでビルド可能)ならば同一字形を複数のUCSコードポイントやIVS・SVSのために使えますが、これは現在の花園明朝のフォントフォーマットでも同じなのでしょうか?もし65536枠の中に重複したデータがあるなら、統一することで枠が空くかもしれません。康熙部首としても漢字としても収録されている文字や、AJ1とHanyo_Denshi/Moji_Johoで重複している字形などです。(ただ、字表-討論:花園フォントを見る限り、IVSは10211字と書いてありこれはAJ1のIVSより少ないくらいなので、重複は回避されている?)
  • GlyphWikiの非漢字グリフの質はやはりあまり高くなく、無駄な凹凸があるとデータ量も増えてしまうので、一般向け花園フォントの非漢字は(ライセンスは制限されますが)IPAやSource Han Serifあたりから取って、あとはエキスパート向けに(それ自体としては完全自由な)GlyphWikiデータを用いたフォント制作のドキュメントを充実させるという方針がGlyphWikiの成果を活かすにはやはり一番良い気がしています。
  • あとはユースケースを考えると、Adobe-Japan1やAdobe-Korea1などを参照して各言語の使用者向けに分けてリリースするのもアリかとは思います。--turgenev 2021年11月17日(水) 01:08

AFDKOを用いたビルド方法の検討

AFDKOを使って花園明朝のOpenType版を作ろうという話は過去にもありましたが、外部フォントの取り込みなども含めてすこし具体的に検討しました。せっかくなのでメモを公開してみます。実際に動かすのはKAGEエンジンの方針が決まってからにしようと思いますが、興味のあるかたはご覧ください。 https://turgenev.notion.site/238b833a2c7e4abdaa10503305f5798a

  • 思いっきりド素人質問ですが、前からわからなくて触手が伸びなかったのですが、AFDKOでUCS第3面も網羅したフォントは作れるのでしょうか。AJ#の文字種しかマッピングできないのかと思っているのですが。--kamichi 2021年11月15日(月) 12:18

  • Unicode規格の理解には自信がないのですが、「UCS第3面」というのはUnicodeの30000~3FFFFの間ということで合っているでしょうか?たとえばAFDKOでビルドされているSource Han Sansはu30edeu3106cを収録しており、少なくともAJ1に含まれないCJK統合漢字拡張A~Gなどを入れることは可能だと認識しています。該当するCMapの記述がこちらにあります: https://github.com/adobe-fonts/source-han-sans/blob/master/UniSourceHanSansJP-UTF32-H#L10938
  • OpenType自体の制限で65536文字までしか入れられないので例えば全てのCJK統合漢字の「網羅」ということになると難しいですが…--turgenev 2021年11月16日(火) 19:11
  • ↑更新を見落とされているかもしれないので、念のためここに追記しておきます(このような場合どうするのがkamichiさんにとってはご都合がよろしいでしょうか)。--turgenev 2021年12月15日(水) 22:52
    • どうもありがとうございます。実は書き込みを見ていたのですが、そのあと考えがまとまる前に失念してしまいました。こういう場合、どうすればいいですかね。一般的にはしおり機能みたいなものでしょうか。現状や今後のことを考えるとシステムにはもう手を加えないほうが良い(もとい余裕がない)と思っています。ブラウザの機能を活用すればいいのでしょうが、まずは習慣づけからになりそうです。ただ、機能は追加したくないと言いながら、GlyphWikiのフォント生成機能について、大幅な拡充をしたいと最近思うようになっています。--kamichi 2021年12月15日(水) 23:01
    • 機能の追加などに関しては、やはり用戶:kamichiにもある通り今後の方針についての議論ページを設けて「大会議」ができればと思っています。フォント生成については、たしかにGlyphWiki上での拡張の余地もあるかとは思いますが、色々手を加えようと思うと(そしてGlyphWikiのセキュリティを考えると)ユーザー自身のPC上でやってもらうほうが良いような気もします。具体的にはどのような機能を念頭におかれていますでしょうか? --turgenev 2021年12月16日(木) 00:48