パスワードを忘れた? アカウント作成
13186128 journal
日記

m_nukazawaの日記: ベクター・グラフィックス・エディタ Vecterionをリリース 6

日記 by m_nukazawa

リリースしました。よろしくお願いします。

Pixiv/BOOTHのページ
GitHubのリポジトリ

本体のソースコードが17000行くらい。
GTK3、C言語のデスクトップ・アプリケーションの経験がかなり溜まったと思う。

リリース後、早速いくつか反応を頂いた。感謝。
しばらくはフィードバック内容をissueとして解決する等するつもり。

開発作業をTwitterにあげていたので雑にTogetterまとめを作ったのだけれど、200viewちょっとで、ダウンロード数にも影響はなかった模様。
Togetterの編集画面にバグっぽい挙動もあって編集が面倒くさいし、次回はまとめは作らなくてもいいかな、といったところ。

GitHub上にあげたVecterion配布パッケージがあるので、GitHubでダウンロード統計を取る方法を調べないと。

で、Vecterionリリース後は別のことをするつもりだったのだけれど、何をするかはまだ決めていない。
フォント作りたいけれど、作るならフォントデザインはドッグフード兼ねてVecterionでやりたい。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2017年03月11日 9時47分 (#3174499)

    100000以上のノード数のあるSVG画像をInkscape並みに処理できるかどうか

    《条件》
    1: パスではなくストロークで描画されている
    2: 透過なし
    3: キャンバスサイズ18000x11000ピクセル
    4: 塗りつぶしやグラデーションは無し
    5: レイヤ数は200程度
    6: レイヤのグループ化の有無
    7: 自動バックアップ機能の有無

    • 質問ありがとうございます。申し訳ないですが、処理できません。

      ざっくり回答しますと、以下のような実装状況です。
      1. No:Stroke Element の読み込みは、まだ未実装です。
      2. No:SVGドキュメント全体のAttributeか何かでしょうか。対応した覚えがないので、多分非対応です。
      3. No:railmapsを読み込むとヒイヒイ言うので、メモリさえあれば落ちませんが実用には耐えないと思います。
      (railmaps: https://github.com/hashcc/railmaps [github.com] 結構大きい。次回以降対応予定。)
      4. No:(グラデーションを使ってない画像を読むという意味だと思いますが、)Vecterionはグラデーションはまだ未実装
      5. Yes: 200くらいなら対応しているはず。
      (LayerViewが仮実装のため、個数が多すぎると定数個でLayerView表示を打ち切る。もちろんドキュメント描画はする。)
      6. No: 読み込みますが、Group 編集機能は未実装です。
      (現在、Group Elementは多くの場合にLayerと同じ扱いをされます。)
      7. No: 是非付けたいと希望していますが、未実装です。

      Inkscape、そんな大きい画像に対応していましたでしょうか。
      (そうだとしたらすごい。)
      もしInkscapeの巨大ドキュメント対応、実装の概要をご存知でしたら、Vecterionでも巨大ドキュメント対応を検討しますので、お教えください。

      親コメント
      • by Anonymous Coward

        大きいキャンバスサイズで複雑な画像は難しそうですね。
        完成後の出力はPNGで出してから別の画像処理ソフトウェアを使っておりますが、細かな表現を入れる場合にどうしても大きなキャンバスサイズでの描画作業になってしまいます(主に再レンダリングで超絶に重くなる)。
        少しでも作業中の動作が軽いエディタがあればいいなと、ただ単純に渇望しているだけですので身勝手なわがままな欲求だということで、わがままな機能要求について失礼しました。

        手元の作業ファイルですと、レイヤ数250枚強で非表示レイヤ上のオブジェクトを除外してもノード数は膨大です。SVGファイル単体で17MB強。こういったファイルをサッと表示できればいいなと。

        プレーンなテキストファイルでのSVGではなく、バイナリ化したSVGファイルを扱えて入出力できれば…… いや、なにも言ってないです。

        • 出来るできない、やるやらないはこちらでの判断になってしまいますが、何も反応が無いよりは要望などが来たほうが、私は嬉しいです。

          見てみましたが、次回以降に対応する予定のrailmaps/tokyo_en.svgも、以下のようなサイズ感のようです。
            tokyo_en.svg 2.3MB
          対応する、というのは、この規模のsvg画像の編集に耐えうるよう処理の軽量化を目指す、という意味です。
          努力目標だったりします。
          17MB強の巨大SVGファイルはrailmaps/tokyo_en.svgよりも処理が重いと考えられます。
          申し訳ありませんが、それを処理するための高速化は、将来的にもしないと思います。

          少なくとも、今後しばらくは足りない機能の追加が優先になります。

          バイナリ化したSVGファイルというのは、svgzのことでしょうか。svgzには対応予定です。
          (これもずっと先のことになりそうですが。)

          親コメント
  • by Anonymous Coward on 2017年03月11日 10時12分 (#3174513)

    ライセンスはソースコードのヘッダにも書いておいた方がいいと思います

typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...