
W dniu 27 grudnia 2009 03:46 użytkownik Jon Cruz <jon@...18...> napisał:
What you pointed out was a specific program of a very specific type (MS Word) and a clone of that same program. Thus those really don't even count as two as far as behavior goes.
Other programs include GIMP and other raster editors - maybe this example is more convincing, because
Now... one has to remember that this is initially a *web* graphic format. So we really should compare to *web* document programs.
I think this is in fact our main point of contention. You think of Inkscape as web graphics editor, while I think of it mainly as a general-purpose vector graphics program that uses SVG. For you using SVG as the output format is the goal, for me it's merely an advantage. The correct default depends on how we answer this question. This is where your survey data could help. How many users use Inkscape as a general purpose vector editor, compared to the number of people who use it as a web editor?
Here are some points to consider. 1. Wikipedia doesn't count as "SVG for the Web", because it doesn't use any Web-related features of SVG. Submitting an image with links to external media to Wikipedia would result at best with a misrendering and at worst the image would be rejected for security reasons (I didn't test it). 2. SVG has Web-related features, but it is a general purpose format that is often used outside of the Web context, for example for GIS data, in mobile applications, and on the Linux desktop (icons). 3. "Inkscape is a general purpose vector editor" doesn't equal "Inkscape should not have Web-oriented features". It only means that the Web-oriented features should be available for users that explicitly want them.
- you might highly doubt users behave that way... but I have *observed* users behave that way again and again and in many different contexts.
- Many many many programs out there *do* paste links. They might be more common with workflows different than the workflows you personally use... but that does not mean they do not exist.
Please mention examples! There are indeed several programs that do paste or import links, but we must also consider how they relate to Inkscape. Video editing programs almost always use links, but I don't think this is relevant for a vector editor. The other example you mentioned is web design tools, see above.
Instead I would say a better solution is: "Make the UI convey link vs. embedded constantly and consistently so the user is never surprised."
This would require everyone to understand the difference between a link and an embedded image, and the concept of a link between two files. There might be lots of potential Inkscape users that don't understand the link concept (not to say that they wouldn't understand it if explained, just that they never used it). In this respect, embedding is bulletproof and idiot-proof.
2009/12/27 Donna Benjamin <donna@...2182...>:
Bundling the file together with the linked images the way ODF does makes some sense for file storage and transportability - but embedding the file, by UUencoding or Base64 or something doesn't make sense to me, because it can't be edited with a text-editor
SVG with embedded images can be edited in a text editor. The image element will have a very long URI, but it should not be a problem for a decent editor.
What does the SVG standard suggest? What's wrong with the current 'save as' compressed svg with media (*.zip) option... perhaps some documentation or asking heathenx to do a screencast on this topic would help those users who are unfamiliar with this standard practice?
SVG doesn't define any compression methods or container formats, but the de facto standard is SVGZ (a single SVG file compressed with gzip). SVGZ is opened directly by many vector applications. The ZIP archive requires decompression, and as said before the user is not aware that he should choose this option before sending the file to a friend.
More screencasts and more documentation can't hurt, but it's better if basic features of a program do not require explanations - this is called usability :) So we have a dilemma: we either adapt pasting so that average Joe, who doesn't bother watching screencasts or reading docs, doesn't break his documents, or try to teach him that SVG images are more like web pages, and the images should be external. The former has a better chance of success.
Regards, Krzysztof