On Dec 28, 2009, at 9:37 AM, Krzysztof Kosiński wrote:
W dniu 28 grudnia 2009 02:16 użytkownik Jon Cruz <email@example.com
2. 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
But did you finish reading that paragraph you cite?
The limitation is for *in-band* data transfer. There standard ways that Jabber does *out-of-band* file transfers. This is common for most any instant messaging protocol.
*HOWEVER* you missed the main point. If linked images already exist on both sides, then there is no need at all to exchange them.
And if a linked image does not exist on one side, it is easy to transfer that image once and only once, and for *any* sessions that those systems engage in, including editing many different SVG files in a collaborative manner.
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.
Again, this is exactly where you are not seeing the forest for all the trees.
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.
Please look over what has been said... even by you in this last paragraph.
Let me try to spell it out for you:
"Was the unser aware..."
"...no way to fix... once ... is sent..."
Those all call out as signs of a usability issue. There are a few approaches. These include:
* It is tricky, so don't do it at all
* It is tricky, so make it clear and simple
Right now the media management is poor in that it does not convey things to users and users get surprised. We *need* to address it so that it is not surprising. Actually that is what you are doing when you suggest to *always* embed images:
Problem: some users are confused by linking vs. embedding of external media assets.
Solution: never link external media assets, only embed them. This results in 100% consistent behavior.
That proposed solution *is* better media management. It probably is not the best way to improve it, but it is doing just that. So your assertion that "better media management won't help" is false.
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"?
Please go back and read things again. Or drop into the chat room like the other developers and users. That *REALLY* helps with communication.
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
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
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.
Yes. But my point is that taken in a "big picture" view (i.e. the forest, and not just the trees) a single solution *can* solve both. Taken in the localized view (i.e. trees, and not the forest) it can't.
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.
You are the one who changed the *one* description away from the descriptive end-user problem and instead to describe the bug in terms of the proposed solution as you see it. I just put it back.
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).
No. This is where you are just not getting it. That is also why we *NEED* to have things spelled out clearly in the wiki. A comprehensive solution that solves the whole problem in its entirety will address that.
What you are proposing is a micro-fix that solves things for one group of users at the *expense* of another group. That is the main problem there.
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.
No. You are seeing that completely wrong.
First, "embed" will not solve 100% of things for 100% of people as you claim. Just ask the people on IRC. Or re-read these threads.
More importantly is that again you are incorrectly stating my intent. The key thing is that I do *NOT* want to fix each bug with a different and specific solution. You are the one doing that.
My intent, on the other hand, is to collect up *all* facets of this problem *overall* and then solve them in a comprehensive manner. When combined together, a *few* changes can solve many, many problems.
Look again. "Always embed" may fix some of the use cases you added to the wiki, but it will piss off Sara with her use case.
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.
This may or may not work, depending on which user you have. That is critical to grasp. It might solve things for user A, but break things for user B. We need to cover all cases.
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?
Not true. At least not the way you state.
Different users look at things to different degrees, and there have even been good presentations and research done on just this point. Go review the work Michael Terry has been doing, especially what he presented at LGM.
Remember, Microsoft is the epitome of bad user interaction. So most anything they present will be discounted.
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
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
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.
Again. PLEASE, PLEASE actually enter these use cases you keep coming up with into the wiki.
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
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.
Thanks. A table in the Wiki will be of immense value. Also we should check it on a few editors, not just gedit. Notepad comes to mind right off hand.
(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.
No, it is relevant. There are many ways to get things packaged and sent, and you might be surprised at how the various mail programs behave.
Also... I *HAVE* cited existing container formats, but you keep ignoring such information so I'll will stop now.