Scrolling & Zooming not working for SVG imported from dvisvgm
TobiasZawada opened this issue · 6 comments
The paths for the formula from the following svg (generated by dvisvgm) are not visible in Edraw:
So scrolling and zooming is essential to make the paths visible and to edit them.
But, scrolling and zooming the view does not work for those paths.
That is because the paths are not part of the group with id edraw-body which gets the transform property for moving the view.
For reproduction download the above SVG-image, open it with Emacs and edit it with edraw-mode.
(Translated Message)
It is intentional that the editing target of edraw is limited to g#edraw-body. As I wrote in the README, edraw can only handle a small subset of the SVG specification. The sign that it conforms to that subset is the ID edraw-body and (although I don't really like it) the extension .edraw.svg.
If you try to forcefully edit any SVG with edraw, the behavior is not guaranteed at all. There are a wide variety of SVG notations that edraw does not support, and I don't know all of them. This behavior is a safety measure to prevent SVGs created with other than edraw from being easily opened with edraw.
If you want to use edraw components from elisp, you need to make sure that SVG can be handled by edraw, and then convert it to g#edraw-body. There was an idea for a function called edraw-edit-svg to perform this conversion process, but it was too troublesome to implement.
I also want to be able to handle general SVG, but there is no set policy yet.
(It's a bit complicated, so I'm not sure if it will be translated correctly. When I machine translate Japanese into English, "I" may be written as "You" or "We", which is really troublesome.)
(Original Message)
edrawの編集対象が g#edraw-body に限定されるのは意図的な仕様です。READMEにも書きましたが、edrawが扱えるのはSVG仕様の小さなサブセットに限定されます。そのサブセットに準拠していることを示す印がedraw-bodyというIDであり、(私もあまり好きではありませんが).edraw.svgという拡張子なのです。
任意のSVGをedrawで無理矢理編集しようとした場合の挙動は一切保証されません。edrawが対応していないSVGの表記は多岐にわたり、私もその全てを把握していません。この挙動はいわばedraw以外で作成したSVGを安易にedrawで開かないようにするための安全策です。
elispからedrawのコンポーネントを使う場合は、edrawで扱えるSVGであることを確認した上で、g#edraw-bodyへ変換する必要があります。 edraw-edit-svg という関数ではその変換処理を行うアイデアがありましたが、面倒なので実装には至っていません。
一般的なSVGを扱えるようにしたいという気持ちは私にもありますが、まだ定まった方針はありません。
(ちょっと込み入った内容なので正しく翻訳されるか不安です。日本語を英語に機械翻訳すると"I"と書くべき所が"You"やら"We"やらになることがあって本当に面倒です)
There is an idea to nest SVGs, but even in that case, you would have to temporarily rewrite the attributes of the imported svg elements, so I don't think it's a method that will make everything go well ( However, in the future we may use such a structure). How to handle the defs element is also an issue (I didn't want to place it in the same hierarchy as the shape elements).
SVGを入れ子にするというアイデアもあるのですが、その場合でも取りこんだsvg要素の属性を一時的に書き替えなければならないため、そこまで全てがうまく行く方法(全くの変換無しで済む方法)でも無い気がしています(しかし将来的にはそのような構造にするかもしれません)。defs要素をどう扱うかも問題です(あまり図形要素と同じ階層に置きたくなかったのです)。
The above SVG image can be edited to some extent by changing to .
However, I am worried that the path may contain multiple subpaths (edraw does not support paths where one path data contains multiple subpaths).
It also doesn't support the pt unit, so if you save, you'll lose that unit.
So this is not a problem of not being able to scroll and zoom, but rather a problem of not being able to edit general SVG.
上のSVG画像ですが、をへ変更したらある程度は編集できるようになります。
しかし私はそのpathの中に複数のサブパスが含まれてやしないか心配でなりません(edrawは一つのパスデータに複数のサブパスが含まれているようなパスに対応していません)。
ptという単位にも対応していないので、セーブすればその単位は失われるでしょう。
なのでこれはスクロールとズームが出来ないというよりも、一般的なSVGを編集できないという問題なのです。
The current state is not really satisfying since it is possible to switch to edraw-mode for any SVG image. But, one does not get what one expects.
What about an import feature, that allows to transform SVG images into Edraw-images?
That function could filter out unsupported SVG-features. The user is aware that features of the SVG image might be missing since the function is just an import and does not promise to "load" the full SVG-image into Edraw.
I assume that the current specification of Edraw-images is just the Elisp-implementation of Edraw. Is that right? (Akyiama-san, I want to make very clear, that no offense is meant by this statement. Your work is great! And it is fine the way it is.)
Just want to make sure that I do not miss something.
The current state is not really satisfying since it is possible to switch to edraw-mode for any SVG image. But, one does not get what one expects.
それならエラーを出して切り替えられないようにすれば満足するのでしょうか。
In that case, would it be satisfying to issue an error and prevent switching?
まぁ、結局編集できないのだから、エラーにすべきなのかもしれません。(意図的に既存のSVGの上に何かを書き足したいという人がいたら別ですが、おそらくいませんよね)
Well, since it can't be edited after all, maybe it should be treated as an error. (Unless there is someone who intentionally wants to add something on top of an existing SVG, but there probably isn't.)
そもそもEmacsのメジャーモードは、対象では無い形式でもある程度有効に出来てしまうものではあると思いますが。
In the first place, Emacs' major mode allows you to turn-on to some extent even if it is not a target format.
README.orgのedraw-modeの説明には「Emacs Easy Draw cannot edit general SVG data」と明確に書かれています。その後に書かれていることも、一般的なSVGをedraw-modeで開いてしまわないようにするための措置です。
The edraw-mode description on README.org clearly says "Emacs Easy Draw cannot edit general SVG data". What is written after that is also a measure to prevent opening a general SVG in edraw-mode.
ここまで書かれているのに任意のSVGが編集できることを期待するのはいかがなものかと思いますよ。
It seems rather unreasonable to expect the ability to edit any SVG file despite the clear explanations provided here. (Note: There are doubts about the accuracy of the translation)
What about an import feature, that allows to transform SVG images into Edraw-images?
それは十分考えられる方法です。
That's a method worth considering.
ちなみに、todo.org(日本語なので読まないとは思いますし、私も他人が読むことを前提に書いていませんが)に「SVGのルート直下を直接編集できるようにする」という項目があって、「インポートコマンドを作る」というアイデアもそこで少し書きました。また、「別ファイルの内容をインポートする機能を追加する」という項目もあります。
By the way, on todo.org (I don't think people will read it because it's in Japanese, and I'm not writing this with the assumption that others will read it), there is an item called Enable direct editing of the SVG root.'' I also wrote about the idea of creating an import command'' there. There is also an item called ``Add the ability to import the contents of another file.''
That function could filter out unsupported SVG-features. The user is aware that features of the SVG image might be missing since the function is just an import and does not promise to "load" the full SVG-image into Edraw.
一般的なSVGをインポートできるようにするなら、そのような安全対策が必要になるでしょう。ただ、そのような関数を書くのは思っているよりも面倒くさいでしょう。
Such safety measures will be needed when allowing generic SVG to be imported. However, writing such a function may be more troublesome than you think.
また、filter outするかそのまま残すかは判断が難しいところです。多くの未対応機能は残していてもあまり害を及ぼさないかもしれませんし、その方が応用範囲が広い可能性があります。
Also, it is difficult to decide whether to filter out or leave it as is. Leaving many unsupported features may not cause much harm, and may have a wider range of applications.
I assume that the current specification of Edraw-images is just the Elisp-implementation of Edraw. Is that right? (Akyiama-san, I want to make very clear, that no offense is meant by this statement. Your work is great! And it is fine the way it is.)
edrawは一般的なSVGを編集するために作られたのでは無く、Emacs内で気軽に図を書き始めるために作られました。読み込めるのはedrawで作成した図だけです。
edraw was not created to edit general SVG, but to easily start drawing diagrams within Emacs. Only diagrams created with edraw can be loaded.
edrawで作成できるSVGはedrawで読めます(誰もがそれを当たり前のように期待するでしょう)。edrawで何が作成できるのかはedrawのElisp実装で決まっています(そしてユーザーはedrawを使っていくうちに何が作成できるのか分かってきます)。ある意味とても明確ですし、ある意味曖昧です。
SVG that can be created with edraw can be read with edraw (everyone would expect that). What can be created with edraw is determined by the Elisp implementation of edraw (and users will learn what they can create as they use it). In some ways it's very clear and in some ways it's ambiguous.
(括弧の中のご配慮ありがとうございます。翻訳の手間と相まってなかなかストレスが溜まります)
(Thank you for your consideration in parentheses. Combined with the translation effort, it is quite stressful)
私が一般的なSVGのインポートが欲しいと思ったシチュエーションにはいくつかあります。例えばSVGのコピー・アンド・ペースト機能というアイデアがあります。SVGのxmlテキスト(形状部分だけの断片でも可)をコピーして(killリングに入れて)、それを直接edrawにペーストする(インポートする?)ことができたら便利ではないでしょうか。ちなみに現状では、(編集する前の)画像を右クリックしてコピーし、edrawエディタやシェイプピッカーでペーストすることが出来ます。
There are several situations where I would want a general SVG import. For example, there is an idea for a copy and paste function for SVG. Wouldn't it be convenient if you could copy (put it in the kill ring) SVG xml text (even just a fragment of the shape part) and paste (import?) it directly into edraw? By the way, currently you can right-click the image (before editing), copy it, and paste it using the edraw editor or shape picker.
まずはedrawが対応しないSVG機能を検出する仕組み(関数)が必要そうです。
First of all, it seems that we need a mechanism (function) to detect SVG features that are not supported by edraw.
問題はedrawが何に対応しているのか、していないのかが明示的にまとめられていないことでしょう。大ざっぱに書けば次のような制限があります:
- 対応していない要素
- 対応していない属性
- 属性の中で対応していない書き方
- 対応していない構造
The problem is that there is no explicit information on what edraw does or does not support. Broadly speaking, the limitations are as follows:
- Unsupported elements
- Unsupported attributes
- Unsupported format in attribute
- Unsupported structure
edrawはsvg要素直下にある g#edraw-body を編集対象とします。その中で使う別途定義が必要な物は、svg要素直下にある defs#edraw-defs の中に配置します。defsの中にある要素は一定のルールに従ったIDを持ちます。そしてそのIDによって g#edraw-body 内から参照されます。
edraw targets g#edraw-body directly below the svg element. Items that require separate definitions are placed in defs#edraw-defs directly under the svg element. Elements in defs have IDs that follow certain rules. It is then referenced from within g#edraw-body by that ID.
g#edraw-body内に書ける要素は、現在のところ rect、ellipse、path、text、image、gのみです。circleは少しだけ対応するコードを書いていますが、あまりテストはされていませんし、それを描くツールも存在しません。polylineやpolygon、その他は一切考慮していません。
Currently, the only elements that can be written in g#edraw-body are rect, ellipse, path, text, image, and g. I've written some code for circle, but it hasn't been tested much, and there aren't any tools to draw it. It does not take into account polylines, polygons, or anything else.
SVGの属性は沢山あり私はその全てを知りません。基本的にはプロパティエディタで編集できるもの以外は未対応です。
There are many attributes of SVG and I don't know all of them. Basically, anything other than what can be edited with the property editor is not supported.
属性の中で対応していない書き方は多数ありますし、私もその全てを把握しているわけではありません。前にも書いた単位(pt等)やパスデータ(複数のサブパスやAコマンド)もここに含まれます。マーカー(矢印等)は特に制限が強いです。テキストに関連する属性は未対応の物が多いです。style属性はプロパティエディタで自由に編集できますが、その結果問題が発生する可能性があります。
There are many formats that are not supported among attributes, and I am not aware of all of them. Units (such as pt) and path data (multiple subpaths and A commands) that I mentioned earlier are also included here. Markers (arrows, etc.) are particularly restrictive. Many attributes related to text are not supported. You can freely edit the style attribute in the property editor, but this can lead to problems.
テキストは内部構造に制限があります。テキスト内の任意の場所を装飾するためにtsapnを使うことはできません。複数行テキストは .text-line というクラス名が付いたtspan (tspan.text-line) に分割する必要があります。対応していない構造はプロパティエディタでテキストを編集する時に破壊されるでしょう。
Text has limited internal structure. tspan must not appear to decorate anywhere within the text. Multiline text must be split into tspans with the class name .text-line (tspan.text-line). Unsupported structures will be destroyed when editing the text in the property editor.
これが全てかは分かりません。
I don't know if this is everything.
このようなものを検出して、エラーを出したり、警告を出したり、あるいはedrawが対応する代替の要素へ置換したりするような仕組みがあれば、一般的なSVGを読み込む際に役に立つことでしょう。
If there is a mechanism that detects such things and issues an error or warning, or allows edraw to replace them with the corresponding alternative elements, it would be useful when loading general SVG.
とても面倒くさいと思いませんか？ 私はそう思うのでこれまで実装しませんでした。検出するのはまあ何とかするとして、その後どうするかです。実際のところ、ほとんどはそのままでも動いてしまうかもしれません。編集しなければ破壊されず維持される場合も多いと思います。これは安全策に過ぎないわけです。でも何も安全策を設けずに問題が起きてここにIssueが立てられても私は困ってしまうわけです。
Don't you think it's very troublesome? I think so, so I haven't implemented it until now. Even if it is possible to detect it, what to do after that? In fact, most of them may work as is. I think that in many cases, if you do not edit it, it will not be destroyed and will be maintained. This is just a safety measure. However, if a problem occurs and an issue is created here without any safety measures in place, I would be in trouble.
それよりも「編集できるのはedrawで生成したSVGだけです。それ以外は私は知りません」と表向きは言っておく一方、「あなたが自己責任で g#edraw-body に好きな要素を入れて使う分には止めはしないよ」という方が私にとって得ではありませんか？
(Even machine translation could not translate it well)
まぁ、そのうち暇なときに何らかの対策をしてみます。待っていてください。
Well, I'll try to do something about it when I have some free time. Please wait.
本当はもっといっぱいいろんな事を書いたのですが、翻訳するのが難しすぎて消しました。
I actually wrote a lot more, but it was too difficult to translate so I deleted it.