On 06-Mar-2013 13:49, John Cliff wrote:
Unless its a fully reversible operation we shouldnt be describing it as a save. If its non reversible, ie bitmap, pdf etc then it should be an export.
I _loathe_ the "purity of the save" argument: "If it is not a perfect save, it is not a save". The first corollary of which is typically "we can only save to one format, everything else is an export". The second corollary is "the users must employ the nonintuitive 'export' instead of the 'save' they have all been perfectly happy with since the first PCs, even though this change in the interface benefits them in no way whatsoever and requires that they relearn the interface."
The only "perfect save" that Inkscape can do is to "Inkscape SVG" (and the compressed form, but that's a minor distinction). Plain SVG is an "export", because it is NOT round trip compliant through an Inkscape "save as". That is clearly the wrong design choice for an SVG editor. (Just as making "save as" only for xcf was the wrong design choice for Gimp, where the majority of its users _never_ save an xcf file, but just use the program to quickly modify PNGs or JPGs. This issue was blithely dismissed by the "purity of the save" faction by classifying such a light user as "not a targeted GIMP user".)
Here is a simple demonstration of the plain SVG issue:
1. Launch inkscape and create a text box with the following three lines of text in it (with carriage returns at the end of the first two lines):
This is one sentence spread over three lines of text.
2. Save as (inkscape SVG) -> text.svg 3. Save as (plain SVG) -> textplain.svg
4. Now open both files. Place the cursor on "This" and hold down the right arrow key on the keyboard. For "text.svg" the cursor will move in order from the T in "This" to the "." after "text", in every case moving as it should to the next letter. For "textplain.svg" the cursor will move to the end of "sentence" and then jump back to the "T" in "This". Basically it is moving properly in X but incorrectly in Y. Diff the two svg files to see why. The bottom line, plain SVG does not go unchanged through a "Save as" "open" cycle. There are other differences, but this is one of the easiest to see.
GIMP has already been through this export vs. "save as" nonsense, which I think can well be described as a case of some developers thinking they knew what was best for everybody, despite the end users trying to disabuse them of their misconceptions.
http://www.gimpusers.com/forums/gimp-user/14339-hate-the-new-save-vs-export-...
Let's not repeat that mess with inkscape, please! In review, what happened in GIMP is that the developers gutted "Save as" and moved all of the standard image formats into "Export", while breaking the convenient default keyboard shortcuts. There too the better solution would have been to leave well enough alone and just add "Save as XCF", and a keyboard shortcut for it, since that is all the new "Save as" in GIMP does (besides inconveniencing and pissing off the end users!)
(I should add that the "purity of the save" argument is based on the unstated assumption that the drawing was originally created in Inkscape and uses features that are not present in the target file format. That is quite often a false assumption. A user might open an EMF, PDF, etc. file, modify it slightly, and then save it back to the original format, having introduced no features that are not supported by that file format. Yet that save would be classified as an "export" because the user had the ability to introduce such a feature into the drawing, even though they did not actually do so.)
Going from a file menu with just two options "save" and "save as..." to one that also has "export as...", where all but one file type (and its minor variants) are in the last option, does not help end users. Period. It just adds complexity to the interface. If the end users have even the vaguest idea what the various file types are they already know that a "save as" to a PNG, or most other formats, is not conservative, and just in case they don't there is already a warning in Inkscape to tell them. They may not know specifically that a save to "Inkscape SVG" is the only conservative save (in the completely general case, where every possible feature is employed), but they do not need to, since that is the default "save" format. The "purity of the save" police (you know who you are!) already made Gimp less friendly for the end users, and they are trying to move Inkscape down the same wrong path. "Save" and "Save as" are fine as they are. Go poll the end users, for once, before stuffing an unwanted change down their throats - they aren't complaining about this issue at all, just like they weren't in GIMP. The complaints will come _after_ this change, as they did there. Rather than redefining "Save as" away from what it has meant for the last 30 years in pretty much every program that had a similar option, and making "Export" do everything "save as" used to, a better course would be to leave "Save as" well enough alone and to add the menu option that does exactly what the "purity of the save" police really desire: "Save as Inkscape SVG". Or is there some subtle distinction between the proposed new "Save as..." and "Save as Inkscape SVG" that I am missing? I cannot think of any other format that supports every single SVG feature, plus inkscape extensions, if there is one, please name it.
The proposed changes seem perfectly pointless to me since one can already "Save as Inkscape SVG" through the existing "Save as" menu, and then with ^S or "File->Save" subsequently, and all of the "purity of the save" people know that. For some reason the existence of "imperfect saves" seems to rub these folks the wrong way, so that they feel compelled to rearrange user interfaces to fit their theoretical ideals, but only succeed in making them less convenient for everybody else.
Bottom line, can one of the people who supports these changes please explain exactly what the real benefits would be, and how and why these outweigh the costs (the end users having to relearn an important part of the user interface). And by real, I mean real. Something most be done faster, or fewer errors made, and so forth. Some tangible benefit must accrue or the change is not worth putting in.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech