Inkscape

W dniu 28 grudnia 2009 02:16 użytkownik Jon Cruz <jon@...> napisał:
> 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

> 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.