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.