On 06-Mar-2013 12:59, Alexandre Prokoudine wrote:
On Thu, Mar 7, 2013 at 12:03 AM, mathog wrote:
Let's discuss this within the context of a simple example, a drawing which consists of just three rectangles: red, green, and blue. Currently "Save as" to a file "all.(type)" will save all 3 objects to a file. If I want to "save as" to another file (by name or type) I select "save as" again and choose a different option for the type and/or just change the name.
If I wanted to save just red and green would I not have to remove blue from the drawing first? Or was the proposal to have "export" work only on selected objects, versus "save as" working on all, regardless of selection. I can see a place for a "save selected as...", which would be a minor modification of the current "save as..." that, as it says, only saves the selected objects. (And presumably anything in <defs> that is also needed by those objects.)
You are trying to complicate things :)
The currently existing dialog is a very nice solution for exporting various bits and areas of a document to a delivery file format. Except it's only capable of PNG output right now. Add support for more file formats there, and you don't need any extra menus or extra shortcuts.
Plus the "Save As" command is often misunderstood. Saving to a different file format isn't its primary function, it's one of the two primary functions (and to me it's always the second important one).
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.
You are defining a "save as" as the case where Inkscape->file->Inkscape results in exactly the original drawing. Save as to plain SVG would be, by that definition, an export. Right?
99.99% of things are saved to Plain SVG will be recovered, but not meta information like the disposition of the viewer, or some aspects of the text handling. But if plain SVG _is_ a "save as" and not an export, then what about EMF, which in my experimental code is 99.95% of inkscape SVG, can keep the text handling aspects that plain SVG loses (on reopen the cursor can move smoothly through a multiline text object), but cannot save/open gradients or filters without losing something. You mention PDF. One of the things that makes PDF import different is that formatted text is broken into little pieces on export into PDF, and stays that way on reimport. That was the way EMF was originally, but I wrote code to reassemble it back to the way it was originally in the Inkscape SVG (it works for any reasonable text) and that same code would work just as well for a PDF import, or basically any other text import that has text fragments in (font, xy position, angle, color) encoded chunks, and where these chunks occur in a sane order.
Finally whether a particular drawing is an "export" or a "save as" is dependent upon what it contains. The hypothetical three rectangle drawing described in my last message would be a "save as" in pretty much every supported format, since it would be unchanged in a round trip through the other formats.
The import/open distinction in Inkscape is even more mysterious to me. As near as I can tell they do exactly the same thing. There is no question of whether or not something will be retained in that round trip (file->inkscape->file) because I believe that pretty much every file format supported can make that claim. (Excluding bugs, of course.)
I can see (judging by similar GIMP threads) how this is going to annoy certain people, so with all due respect I won't comment on this any further.
The export/"save as" distinction is annoying in this instance because near as I can tell the only thing that is 100% guaranteed to be round trip unchanged is Inkscape SVG, which would mean that everything else would have to be an export. That would be a silly outcome because Plain SVG is the standard, Inkscape SVG uses extensions. I am happy enough with the warning in the "save as" that something might be/would be lost - and one less entry on the file menu.
On the other hand, implementing "save selected as..." might actually be quite helpful in some instances, certainly better than making a copy and then editing out the unwanted pieces, and it should not be particularly difficult to do.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech