On Dec 23, 2009, at 5:57 PM, Krzysztof Kosiński wrote:
The question is moot because the second solution is unimplementable. We cannot "fix the pasting of links" because when we paste pixel data, for example copied from GIMP, there is no file we can link to.
No, not at all. Just because you can't see the solution doesn't mean that others can't.
In my observations and in various testing, the case you mention of pasting raw image data straight from a drawing program is a minority case. If you happen to do that most of the time, just be aware that you are a user who could be in the minority.
However... you are wrong that there is no file we can link to. In fact, in one of your earlier mails you complained about the location the pastefile was located at. Therefore a simple solution would include just placing a file "PastedImage001.png" in current SVG document's image location. (note that in the simple case this would be the location of the SVG file being pasted to, but not in other cases)
The "common background" thing is a legitimate use of links, but pasting is not an obvious way to do this. When you're pasting something, you do not create links to the original, you make copies of the thing you're pasting. Why you want links, contrary to how every other application works, is completely beyond my comprehension.
And I personally never see an image in the documents folder linked.
???
OK. What I'm trying to point out here is that I don't see the program behavior you do. Most likely it is due to me using things differently. Or it might be a difference of operating systems. Whatever the case, the key point is that I myself (notice that I'm not projecting my experience to be the universal one) do not see the problem you describe encountering.
So, as we refine this and get more of the details on the problems you personally are seeing, it sound more and more like you are being adversely affected by misbehaving pasting/linking. If we fix that, then most of those use cases will be solved... with no need to resort to embedding.
The problem will not be solved by proper linking, it will be made worse (not to mention that it cannot be consistent with the behavior for pixel data as outlined above). Let's go back to the e-mail case. Let's say I paste 3 images from 3 different folders into my document. Now I want to send this to another person. Instead of having all the images in the document's directory, I now need to look for those files around the filesystem, and moreover the links will be broken on the other person's system, because they likely point to different directories.
No, it will be solved. And as for the pixel data case, that is an edge case. We shouldn't have the main uses dominated by an edge case's behavior. Four of the five use cases currently on the wiki fall square in the main case (as opposed to edge cases).
The rest of that paragraph sounds like a good use case. Can you please be sure it gets into the wiki page for them? That's really the place to raise and answer such concerns.
Oh, and what you describe is covered by the combinations of changes/features that I've been working out to fix the situations. It fits squarely in the "big picture" problem, and will be solved by the "big picture" solution.
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".
What exactly is wrong with embedding that makes you refer to it as some kind of last resort measure?
I keep stating many reasons, but you continue to ignore them. This makes me believe you are not so interested in fixing Inkscape as you are in continuing an argument. Since this seems to be hard for you to track, I'll try to get the wiki page on use cases filled out with these details as soon as I have time. (bit busy with family these couple of days)