W dniu 28 grudnia 2009 02:16 użytkownik Jon Cruz <jon@...18...> napisał:
- This expectation comes from knowing Inkscape behavior. Even if a
Nope. Not a blocker. In fact, that is easily addressed by correcting behavior and *keeping*linking. In fact, it will make things easier since you won't have as much bloat being sent over the wire at runtime.
If the protocol is Jabber, we must base64 encode the image anyway. No gain from linking, and a few complications (the URI has to be different on both sides). http://en.wikipedia.org/wiki/Jabber#Weaknesses
As I look over this, it actually strengthens my opinion that we need to support "linking *plus* media management".
This is my opinion as well! But better media management and the default paste/DnD behavior are not the same.
Guess what? This one actually cries out *explicitly* for proper linked media management. As the user requests in that report: "... simple right click on a "broken image" and then be able to update the path for all the images that are in selection?"
Was the user aware of the fact that images can be embedded in the SVG? I think not many users are aware of this because this feature is very poorly discoverable. Also consider that in the email case there is no way to fix the document once the incomplete document is sent - better media management won't help.
I believe that is exactly what I pointed out would solve use cases you added initially. This appears to be the "Sara" use case, and would be solved by the "Sara" solution.
So, what is the "Sara solution"?
https://bugs.launchpad.net/inkscape/+bug/415374 (User uploaded an SVG with image links to a website, surprised by broken images. Read the first comment, because the reporter misuses the word "embedded". Apparently linking by default is sometimes confusing even in the Web context!)
Nope. Not a blocker either. *IF* you had done a scan of bugs with the "big picture" in mind, you would see that related issues come up with an *unsaved* document not having a fixed location.
The last bug is not related to the default save location, it was related to users not aware of links. Only the 2nd bug was related to the Sara case.
I see you changed the descriptions of the bugs I mentioned to describe your solutions, which I think are not addressing the fundamental problem, which is: average Joe doesn't know what a link is, and will not benefit from any advantages they might give. Links can only hurt him, by breaking his documents. Embedded images can't, and they are only a very minor nuisance for more advanced users, who will find the commands to create links and will know what they do.
In particular, the "embed on save as" option will be ineffective, because the unsophisticated user will not know he has to choose it. If we default it to on, then it is completely equivalent to embedding on paste/DnD, but the latter has the advantage of being simpler to implement and not modifying the document when saving (which is a very important conceptual consideration).
Finally, I see you want to fix each bug with a different and specific solution, while the very simple change of embedding by default on paste and DnD + providing "embed/link" radio buttons in the import dialog would solve them all in one go.
How? How in the world is it possible to break an embedded image? (Provide an example.)
I have. Since you don't care to actually address that, it is clear you really are more interested in arguing rather than in fixing
I don't recall this example being mentioned, please repeat it. I think it's not possible unless you go into the XML editor, but using the XML editor you can also break linked images, or any other element for that matter.
A simple fix that addresses this includes what others have proposed. The first time a potentially confusing situation is encountered we just notify the user so that it won't be a surprise. Simple users can choose their most helpful setting, but non-simple users can get the more beneficial one.
The default for this dialog box would have to be embedding, so it's equivalent to my solution, but with an extra nuisance of a dialog box.
Moreover it disregards a well known fact that users don't read message boxes, even if they say "WARNING, CLICKING CANCEL WILL DESTROY YOUR COMPUTER"; this is particularly true for unsophisticated Windows users, which this solution targets. So your solution does not match the target persona (Charlie). What was the point of writing all the stuff on the wiki if you just ignored it?
Here's a Microsoft account of how dialog boxes are ineffective at informing the user or prompting him to make a choice. http://blogs.msdn.com/oldnewthing/archive/2003/09/01/54734.aspx Another informative blog post. http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
I also don't like things like "don't show this again" boxes. How do I change the setting I'm asked for later? Even if it's written in the dialog box I'm disabling, I might forget what it said. We should avoid them if possible (and my solution does avoid them).
Ah, but then we have the problem you've already pointed out. User A create artwork and hands it off to user B. User B then suffers the pain.
When we look at the case for this perspective, embedding is an obvious winner. In the "Charlie" case, embedding significantly decreases the pain for B. (In fact that was my primary reason to propose it in the first place.)
With linking, it is likely that user A would not send all the needed data. User B would have to contact A, explain to him that he has image links in his document, and prompt him to send them. Then user A might have trouble remembering where is the image he pasted (for example if he DnDed it from a 10000+ photo collection which have camera-given names like "DSC_2657.JPG"), and the whole matter drags out; then user A blames it on Inkscape and never uses it again. User B can text edit the document, but loses a lot more time getting the missing data, and then has to cope with proprietary CDR or AI files user A is sending him.
With embedding, user B has to extract the images before text-editing the document, but he does not need to contact user A and explain anything. We slightly inconvenience the user B, but still do better than in the linking case. User A is completely satisfied.
Also, you mention the system you tried to edit on, but what about the size and number of embedded images? We will need to collect up info on ranges so that we can set proper cutoffs or warnings, much like we had to do with our preview dialog.
Definitely could help. My image wasn't very large (a few hundred KB). On my main desktop, which has 6GB of RAM, opening a file containing a large JPG photo (several MB) is effortless; gedit uses 32.9MB for this, so I suppose it's perfectly possible on a modest machine. I'll follow up with more tests later.
The reason is that the statement is really taking an opinion and a mistaken assertion at that. There are several different implementations we could choose between to solve the problem, so we'll need to be able to list them out so we can consider them well.
Re-read this statement. It doesn't exclude solutions other than mine. Other solutions that are compatible with it are saving to a ZIP archive by default and embedding on save. It is a necessary requirement, because if there is more than one file, someone will inevitably not send one of them.
(In fact, I've even written code to bundle things into MIME multipart many times, so that is a completely viable option for solving an "e-mail problem".)
This is irrelevant because we have absolutely no control over how the e-mail is sent, that's why I added that requirement. If you want to invent a new container format that uses MIME multipart, then a more standards compliant and more space-efficient way is just to use embedding. Or you can submit a proposal for SVG 2.0 to include your new container format.
Regards, Krzysztof.