GlyphWiki logo
ナビゲーション
ヘルプ
検索

ツールボックス
他の言語
利用者ページノート編集履歴

利用者-会話:turgenev

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

目次

新グリフエディタへの対応

  • とりあえず、https://test-e65c5.web.app/ にて、tweさんのエディターに改変後のエンジンをつなげたものを公開してみました。早期公開を優先したためゴシック体に未対応だったりと雑なところはありますが大まかに動きはわかると思います。
  • 小規模な改変として、細入り→止め の曲線（複曲線は含まず）について、長さに応じて微妙に太さを変えるようにしてみました。また、右上カドから開始する曲線について、カドのポリゴンを少し大きくしてみました。u5b50などの不自然な突起がなくなります。このあたりは実験的な変更であり、先述のとおりまだ方針が決まらず洗練されていないところもあるのでgithubへの公開は見送っています。
    • もし一部取り入れていただけるような形になれば、それに合わせて整理していきたいとは考えています。
  • u5f59などでちょっと縦画ウロコを大きくした副作用が出ています。もう少し水平に近い角度にして薄くしたりしてもいいかもしれません。--turgenev 2020年8月26日(水) 09:54

KAGE engineのリファクタリングについて

KAGE engineの内部実装（機能ではありません）の大幅な変更を行いました。成果物はGitHubにアップロードしてあります（プルリクエストはしていません）。→https://github.com/ge9/kage-engine

  • デザインは変更していません。ミスがある可能性はありますが、KAGEフォーマットから具体的なパスデータへの変換は、回転・反転なども含めて同じように行われるはずです。一応テストデータとして、かなり原則を逸脱したグリフも含めたKAGEデータをいくつか作って、それをsample.htmlのほうに付加してあります。この範囲内では違いが出ていないように見えます。なお、ポリゴンの生成順序が変わってしまっているので、オブジェクトとしてまるごと比較検証するのは難しいかもしれません。ただ、動作が異なっている場所が仮にあったとしても、それを修正するのは容易だと思います。ただし、簡潔さを優先し、ゴシックの場合は全くAdjust系の関数を適用しないようになっています。これも修正は容易ですが、この状態のほうが理想に近いと思われる（Adjust系関数は明朝体の字形の調整を目的にしているため）のと、コードが整理されるメリットがかなり大きいのでこうしました。
  • KAGE engineの動作ロジックは、①Adjust系関数により各ストロークのウロコやハネの大きさを調整し、そのパラメータを開始・終端を表すデータ（数字）の100の位や1000の位に加算しておく(kage.js) ②ストロークの種類ごとに細かい部分（たとえば折れストロークであれば、最初の縦線&曲がっている部分&最後の縦線）に分割して取り扱う(kagedf.js) ③分割したそれぞれの曲線あるいは直線を描画する（kagecd.js）となっていました。
  • パラメータの加算を伴うデータの流れが特にわかりにくく、cdDrawCurve、cdDrawLineの両者に課された機能が多すぎるのが問題だと感じたので、以下のような変更をしました。ただし、動作を揃えることを大前提とし、本来であれば削ったり統合したりできる部分でも残してあるので、この理想の通りに行っていない部分もまだ多くあります。
    • Kageオブジェクトは部品に関する管理（ストローク番号99（引用）の処理など）のみ行うことにし、フォントのデザインに関する一切（kage.kWidthなどなど）を関知しない。
    • Minchoオブジェクト（mincho.js）とGothicオブジェクト（gothic.js）を作り、それぞれのフォントに特有の処理は完全にファイルを分ける。例えばkAdjustUrokoXなどのパラメータはGothicのファイルには記載せず、ゴシックデータの描画では一切使わない。Adjust系関数もMinchoのファイルに入れる。細部はかなり変わっているが、大枠としては旧kagedf.jsが元になっている。
    • 両者から利用されるFontCanvasオブジェクト（fontcanvas.js）を作り、これがもっと具体的な図形データの描画を行う。MinchoとGothicは処理の大半が違うとはいえ、例えば直線（=長方形）を書くなどの操作まで分解すれば共通化できる。原則として、kagecd.jsが元になっている。
    • Adjust系関数はストロークのデータに直接適用しない。今までは数値を100か1000倍したものをストロークデータに加算していたが、100倍や1000倍する前の数値それ自体を戻り値として返す関数に変える。例えば、AdjustUroko（にあたる）関数はウロコの必要なストロークが現れた場合のみ動作し、戻り値は加算せずcdDrawLineの別の引数として渡す、といった処理に変更した。例外は開始の132（水平線に接続）と終了の左下ZH新旧（313,413）に関する処理のみのはず。
    • cdDrawLine、cdDrawCurveの本質とはあまり関係のない、限られた場合しか呼ばれない処理を、できるだけ関数として外に切り出す。例えば、"左下ZH用新"の下の四角を描画する処理は、今まではcdDrawLineに対してこの四角を"追加で"描画するよう指示を出していたところを、この四角を予めmincho.js側で描画してからcdDrawLineを呼び出すように変更した。
    • 線分の終点を、指定された長さの分だけ移動して線分を長くし（負の値が指定されたなら短くし）、変更後の終点を返す関数get_extended_destをutil.jsに定義した。このファイル分割はあまりよく検討されたものではない。
    • 変数の名前はできるだけ変えず、細かく見れば元のコードと似た部分がわかりやすくなるよう配慮した。例えば端点の丸を描画する関数の引数は、本来ならradiusなどの名前にしてしまっても良いが、kMinWidthTなどの名前を維持した。コメントなども原則保存されている。

  • 個人的には、この変更後のものをベースにベジエ曲線のデザイン改良などに踏み込んでいきたいと考えています。
  • 曲線の近似で今使おうと思っているライブラリは3次ベジェ曲線を用いるものです。現在の花園明朝は2次ベジエしかサポートしていないTrueTypeフォントにて提供されています（し、実際に直線しか使っていないので問題はない）ですが、3次ベジエにも対応したOpenTypeが今後広く使われる可能性が高いこと、そもそも膨大な字数、字体の差異などの情報を扱えるOpenTypeに花園フォントが切り替わっていく可能性も考えられることから、3次ベジエも積極的に使う方針でデザイン変更を行います。--turgenev 2020年3月27日(金) 22:49

  • さらに整理し、fontcanvas.jsからkageという文字列を完全に取り除くなどして、ベジエ曲線周りの見通しを良くしました。その過程で明らかなバグ的動作を一部修正し、大きく形も変わったのでリポジトリを新設しました。https://github.com/ge9/kage-engine-refined
    • このリポジトリもここで一旦止め、デザインの改良（曲線の近似など）を目論んだものを更に新設する予定です。このような使い方が正しいのかは分かりませんが…--turgenev 2020年4月4日(土) 00:14
  • 以前言及した https://github.com/soswow/fit-curve を使ったベジェ曲線の近似を追加。今まで直線近似で表されていた部分を曲線近似で表せるようになりました。ストローク末端の丸については、まずは曲線・複曲線の「止め」のみ曲線データになるようにしました。他の部分については今後考えてみます。ソースコードは https://github.com/ge9/kage-engine-2 にあります。その他いくつか変更点です。
    • 上記の曲線近似のため、3次ベジエ曲線を扱えるようにpolygon.jsとpolygons.js(generateSVGのみ)を変更しました。
    • 太さが変化するストローク（「開放」→「左払い」や「細入り」→「止め」など）については、変化を表す関数を新たに定義しました。指数関数ではなく円周を使っています。このほうが今までの「0.15より小さければ0.15にする」という補正方法より曲がり方に統一が取れると思います。ストロークが長いほど弧の角度は大きく（つまり太らせ方が大きく）なります。結果的な見た目としては今までとそれほど変わらないと思います。ここは暫定的な措置であり他のデザインも考えられると思います。
    • 曲線ストロークについて、太らせる方向ベクトルを、今までベジェ曲線の法線ベクトルを取っていたのに対し、始点から終点まで一定の速度で変化するようにしてみたところ、割と綺麗だったので、とりあえず「細入り」→「止め」の曲線に採用しました。
    • 縦払いの曲線を僅かに今までより太くしました。これも暫定的です。
    • 「接続」の曲線ストローク末端では角度がギリギリだとおかしくなる場合があります。今後修正します。
    • 今まで対応していなかったゴシックの複曲線に対応しました。
    • これはあまり関係ありませんが、サイズとして小数を指定すればそれに応じてパラメータを調節してフォントのウェイトを変えられるようにしてみました。調節のしかたは既存のパラメータを参考にしています。サイズ指定がなければ今までと同様になります。
    • 現在パフォーマンスについてはあまり考えていません。今後改善していく予定ではありますが、以前に比べると少し処理速度は遅くなっています。
  • 今後の見通しとしては、やや近似直線の目立つ上ハネ・左ハネあたりを中心にデザイン変更を検討します。フォント生成（OpenType）も自前でやってみようかなと思います。その他変更・機能追加の提案も募集しています。
  • 以上、--turgenev 2020年4月8日(水) 09:41
  • 先述の通り、Adjust系の関数については完全にパラメータをKAGEデータから分離したので、u004bのような、調整用のデータを直接入力しているようなグリフは表現できません。それ以外にも曲線で無理やり接続しているような非漢字グリフへの影響はある程度避けられないですね。
  • それとは別の個人的な意見ですが、Adjust系関数に関しては、閾値を設定した段階的な調整ではなく、もっと連続的なものにしても良いのではないかと思っています（これは分離により可能になったことでもあります）。部品をわずかに近づけたり角度を変えたりしただけで見た目が大きく変わるというのは、漢字の骨格データとしての一貫性に欠けるような気がします。そのギリギリを攻めたようなグリフが増えるのは望ましくないでしょう。ここを根本的に改善できれば、GlyphWiki:ソフトウェアへの要望のページ最下部にあるような議論でもある程度見通しがつけやすくなるかも、という気もします（いずれにしろ改善するのが難しいことに違いはないのですが）。
  • ゴシック体エンジンに関しては、ストローク末尾を太くする、斜めに切る、などのオプションをいくつか付ければある程度のデザイン性は担保できるかもしれない、と漠然と構想しています。--turgenev 2020年4月11日(土) 12:24

  • さらに大幅なデザイン変更、コード整理など。
  • リポジトリはkage-engine-2のままです。
  • 以下を曲線的なデータに
    • 縦直線、曲線などの開放時の起筆ウロコ
    • ハネ（左ハネ、上ハネ（右ハネ））
    • 乙線・曲げの終端の丸
    • これらのデザインはあまり詳細な検討をしたものではありません。他の明朝体も参考にしながら、とりあえずは現在のデザインと同等の形状で適当に作りました。ただ、起筆ウロコについては小さいという意見を以前見かけたのでわりと大きくしてあります。角度に応じた形状の調整は大枠を維持してあります。自然な仕上がりになったとは思っています。
  • 一方、横画末端のウロコや右上カドなどは直線のまま（現状維持）です。特に現状で不自然に見えないからです。ただし、u4ea8のように明らかに不必要な突起が出ているのは良くないので改善の仕方を考えています。
  • 起筆ウロコとのバランスを考慮し、右払い画を太くするkL2RDfattenパラメータを1.1から1.2に。さらに、細入り→止めのストローク（曲線・複曲線ともに）も全体の太さを1.1倍にしました。
  • 曲げ・乙線の水平線の太さを0.9倍にしました。
  • このあたりも完全に試験的なもので、明確な根拠はありません。なお、前回更新時のパラメータ調節も（size=1.9として）そのまま利用し、それを基準にデザインを考えました。
  • sinとcosをまとめたオブジェクトを導入し、描画の過程を大幅にわかりやすくしました。
  • ポリゴンの向きを時計回りに統一
  • 1つのパスとしてSVG生成する関数を追加
  • 動作はさらに重くなったかもしれません。
  • 取り急ぎ、今回テストデータとしたいくつかの漢字について、生成データの画像を添付しておきます。https://drive.google.com/open?id=1KLbNIwta-nEajNgp0UJWs0HGMbpHhuJT
  • なお、様々なデザイン変更を実験的に行ってはいますが、とりあえずは現状のままのほうが良い部分があればそこだけ動作をもとに戻すことはそれほどの手間なくできると思います。

  • 右上カドを調節し、少なくともu4ea8では突起が出ないような形状にはしました（という書き方からも分かるように、極めて適当にデザインをしています）

  • おそらく気になる人の多いu6c35をはじめ、現行KAGE engineでややデザインしにくかったりサイズ変更で不自然な突起が出てしまったりしているグリフについては、開始/末端の形状に「曲線接続」のようなものを設ければ改善するかもしれない、と思いました。すなわち、接続部分にある曲線の傾きに合わせて切り口の角度が調節されるような形状です。とはいえ「接続部分にある曲線の傾き」をただちに求めることは難しいので、以下のようにすれば比較的容易に実装できると思います。
    • 該当の端点をバウンディングボックス内に含む曲線をすべてリストアップし、各曲線の始点と終点とを結んだ直線それぞれについて端点との距離を計算する。そのうちで最も距離が近かったものを、該当の端点が接続すべき曲線と判断する。そしてその曲線の始点と終点の傾きに合わせて端点の切り口を調整する。
    • 曲線を選ぶ部分については、単にバウンディングボックスが最も小さいものということで選んだほうが安定するかもしれません。
    • 「バウンディングボックス」ではなく、曲線の構成点でできる多角形（通常は三角形、複曲線なら四角形）のほうが良いですね。

  • 今後の課題
    • u98a8-02-var-001などで、かなり詳細な手動のAdjustが入っている→右ハネ画が全く縦線扱いされていない
    • Adjust系関数も見直しをすべきか（厳密に縦、横でなくてもそれに近いストロークには調整を入れる）。個人的には、同じ近さの縦線が一つから二つに増えたら幅もさらに狭くなる、というのは一貫性にやや疑問があるのではないか、と思っています（その機構を維持するにしてももう少し影響を小さくしても良いのではないか）。
      • しかし影響が出る（デザインの基準となる）字をもう少し幅広く探しておきたい。

  • 近況
    • kageデータ自体にはそのまま対応しているので、tweさんのkage engineに合わせるようにわずかに表面的な修正をすれば新エディタ（ https://github.com/kurgm/kage-editor ）のほうと連動できそうです。
    • 本家kage engineの最近の更新については、バグ（挙動が明らかに一貫していない）に分類されるものは既に修正したはずですが、機能追加などに関しては随時追っていきます（もちろん、スイッチされることとなれば新engineのほうに直接修正をすることになると思います）。基本的に、ストロークの種類ごとにソースコードは分離したので、同等の修正自体はすぐできると思います（ただ、旧ソースコードとの対応を探すのはある程度労力が要るかもしれません。）
    • 8月下旬あたりから時間が取れそうなので、できれば実際にエディタとの連携の様子を公開するところまでやってみたいとは思っています。--turgenev 2020年7月29日(水) 23:54


最終更新 2020年8月26日(水) 09:54。 データ・記事のライセンス プライバシー・ポリシー グリフウィキについて 免責事項