On 08-Mar-2013 11:44, Guillermo Espertino (Gez) wrote:
El 06/03/13 17:59, Alexandre Prokoudine escribió:
Basically what I guess I need is a (much) clearer understanding of what distinguishes an "export" from a "save as". To me they seem to be very much the same thing.
But they are not. We can't claim to be able to save something if we can't open and edit it later exactly as we had that something prior to "saving". E.g. you cannot really save a PDF file, when you have SVG filters inside, because you lose the ability to tweak filters' settings; you can only export PDF and keep the original in SVG. You can't retain various metadata (like names of objects) either, and that's not great.
I think this is the most important point to keep in mind. Also I'd like to ask that maybe our poor distinction between save and export comes from an import strategy that isn't properly defined.
If the process of opening a file destroys some of its original data, then it wasn't opened, it was imported.
One issue with the "need" for Import and Export is that the fidelity of the operation is not a constant, it depends upon what is in the file (in) or drawing (out). Consider WMF, which is a very primitive vector graphics format. Consequently it is quite often the case that an WMF file is "imported" with perfect fidelity, and can then be "exported" with perfect fidelity. So why is that not an Open/Save instead? Import/Export always assume the worst case scenario. The better the support for the file type the less likely this scenario becomes.
I am apparently preaching to the wrong choir here, but the problem you are all trying to solve is not perceived as a problem by the majority (or I suspect _any_) of the "normal" end users. If you really do care about protecting this class of user from data losses, which is I believe the only valid reason for even considering implementing "export", then these end users would be better served by an automatic backup scheme. As for "import"/"open" dropping things on the way in, that happens all the time with all sorts of programs, and end users are used to it. All that is necessary to deal with that situation is a warning dialog along the lines of "some features of the file could not be used by Inkscape". It is hard to imagine an end user who has not seen this sort of message, for instance when a .docx is opened in older versions of MS Word. More detail would of course be better, and in the case of Inkscape it would be relatively simple to supply it, as in "Some Raster Operations and Gradients were dropped during input". I mean, "import" is no better than "open" for this sort of loss, but "import" does require that the end user be aware that it could occur so that they can choose "import" instead of "open". How does having to choose between "open" and "import" benefit the end user??? Either way the exact same drawing results, and presumably the exact same warning messages are shown.
I now have to go drive 800 miles in the next couple of days and so won't be posting for a while. My silence does does not mean that the pro export/import arguments have beaten me into submission!
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech