From: Krzysztof Kosiński <tweenk.pl@gm...> - 2009-12-27 02:13:18
W dniu 24 grudnia 2009 18:49 użytkownik Jon Cruz <jon@...> napisał:
> Therefore a simple solution would include just placing a file "PastedImage001.png" in current SVG document's image location.
This is what happens now (only the name is different), and it is what
causes broken documents when sending over email. I have received a
document broken because of missing pasted images at least once. So
it's not a solution, it is the problem. Users will still only send the
SVG, and be surprised by broken images, because they didn't remember
creating any links.
> OK. What I'm trying to point out here is that I don't see the program behavior you do.
You did not answer the critical part of the question, which is "Why
you want links, contrary to how every other application works". I
remember an earlier response along the lines of "it's more SVG", which
I find irrelevant to the non-expert user. The expert user which values
"SVG purity" will be more than capable of finding the appropriate
options for linking.
To reiterate, I do not want to remove link support. I only want the
user to be aware of the fact that he is creating a link, with the
action being described as "Create Link" not "Paste". Otherwise he will
end up with broken documents.
>> You can propose some magic code to fix those links but what if the
>> person I'm sending to doesn't have Inkscape and won't be able to run
>> this link-fixing code?
> This is more of a non-issue. Once we have the use cases page filled out it should become clear. In the meantime hints are "web archive" and "Web page, complete".
Providing a different save mode that includes all linked documents in
an archive is interesting, and an useful feature in its own right, but
I think it does not address the e-mail case: the user doesn't know he
created a link, so it will not occur to him to use the provided save
mode. He will just send the bare SVG, like he does with OO.o
documents. Finally I don't think many non-expert users think of an
Inkscape image as a web page.
> I keep stating many reasons, but you continue to ignore them.
If I remember correctly, the arguments against embedding on paste
were: 1. SVG gets large, 2. editing the original image externally does
not change the display. In my opinion neither is as severe as
unexpectedly broken documents. Furthermore, both are fixable.
1 is a minor problem that can be solved by suggesting the user to save
in SVGZ if the file is larger than X MB. We should address the problem
of large SVGs even when we decide against embedding.
2 is IMO solved appropriately for now: the "edit externally" link is
grayed out for embedded images. Editing an embedded image is not
trivial, but it can be done using temporary files. I highly doubt your
earlier statement that users expect to see the changes in Inkscape
after editing the original images, because no other application they
can paste images into creates links on pasting.