On 01-Mar-2013 04:49, Martin Owens wrote:

On Fri, 2013-03-01 at 09:52 +0100, Maggio Mago wrote:

...

...

I took some liberty and I'd like to have your opinion on the

rendering.

There is a great deal of complexity in the design. The export dialog already contains quite a bit of complex kitchen sink, I'm not sure about the boxes for Save as PDF etc. The box is looking quite complex.

I would go further. I think "export as PNG" is already a mistake - why is everything else in "Save as" but only PNG in export as? Maybe "export as PNG" was used instead of "save screen shot" or "save image"? There is a "save as" that goes to PNG too.

Anyway, as it stands now one may do a "save as" and formats which require options can bring them up at that point. The options stick, so it isn't very onerous, just one extra click on "ok" if no options must be changed.

I know some programs like GIMP like to make the distinction between formats which are saved, and formats which are exported, but it always seemed to be to be a distinction that the end users wouldn't care about - they just want to save content as "filename" in "format". There should not be two places they have to look to do that. Inkscape already warns on "save as" when content might be lost.

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

On 06-Mar-2013 10:54, Alexandre Prokoudine wrote:

This has been discussed before. The plan was to separate saving from exporting and make more formats available in the current "Export to PNG" dialog. When you really think about it, it all makes a perfect sense. If you don't think so, try saving multiple objects of one document into separate documents :)

Sorry, I don't get what you are saying with that last part.

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.)

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.

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

just to put in my own two cents, I would expect to use "Save As..." only for those formats that are lossless and can survive a round trip, while Export to me means "lossy".

Alvin

-- View this message in context: http://inkscape.13.n6.nabble.com/Your-opinion-about-Save-as-expor-tp4966175p... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

(it seems that this Save as/Export discussion pops up every now and then dies out again. perhaps no-one really cares enough about essentially a change of wording? :)

Haven't thought too much about this, but think this will help the discussion:

To add an argument in favor of the current situation: one can open a PDF document, change it a bit, and then save it again *with Ctrl+S* without going to SVG or opening an export dialog.

To counter the accidental saving to "improper" format: note that if you saved to an "improper" format, there is a warning dialog upon closing the document.

Cheers, Johan

On 6-3-2013 23:22, Josh Andler wrote:

I'm in favor of us going the route that GIMP did. A) Because it makes sense and people won't accidentally only write to an "improper" format. B) For consistency.

Cheers, Josh

On Wed, Mar 6, 2013 at 1:42 PM, alvinpenner <penner@...1856... mailto:penner@...1856...> wrote:

just to put in my own two cents, I would expect to use "Save As..."
only for
those formats that are lossless and can survive a round trip, while
Export
to me means "lossy".

Alvin




--
View this message in context:
http://inkscape.13.n6.nabble.com/Your-opinion-about-Save-as-expor-tp4966175p4966224.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
<mailto:Inkscape-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Fri, Mar 8, 2013 at 5:07 PM, Martin Owens <doctormo@...400...> wrote:

On Wed, 2013-03-06 at 14:22 -0800, Josh Andler wrote:

...

I'm in favor of us going the route that GIMP did. A) Because it makes sense and people won't accidentally only write to an "improper" format. B) For consistency.

Ugh, do you hate your users? When has OCD Logic ever made good design before? The Gimp decision was poor judgment, ignoring many work-flows.

Change the logic round. If we must keep svg files for everything, then do so. Save them in `/.cache/inkscape/shit-people-saved-wrong/ and just open them back up when needed. svg.gz. It's not like the majority of svg files are huge (with exceptions).

I'd like to think we can sort out our definition first. I've heard no convincing rhetoric in favour of save meaning svg, nor that it 'means' lossy. I believe Save_As means 'remember this name and format for future' and Export_As means 'forget this name and format for future'. That's how many workflows consider those functions to work.

Martin,

http://dictionary.reference.com/browse/export

I've always taken export to mean what 3) on that page says -

3. Computers. to save (documents, data, etc.) in a format usable by another software program.

ie you have an SVG which is the format inkscape is natively using, you want something else.

whereas save http://dictionary.reference.com/browse/save?s=t

10. Computers. to copy (a file) from RAM onto a disk or other storage medium.

The file in memory is always a SVG, so you cant save as anything else...

like I said, I believe its wrong that we claim to open anything other than SVG, we dont, we import/translate them into an svg with varying levels of success. likewise, we can only save an svg, anything else is an export with a varying level of compatability.

On Fri, Mar 8, 2013 at 10:56 AM, mathog <mathog@...1176...> wrote:

By the strict logic you are espousing the only way to "save" a binary memory structure would be via a binary dump to a file.

What's that binary data representing though? SVG

I get the impression some of you have not spent a lot of time actually dealing one one one, face to face, with "typical" end users, by which I mean, people who have zero interest in touching the code of the programs they are using.

Doing helpdesk type work and providing IT consulting for many types of businesses certainly has given me no exposure to typical users. You know what I learned at a law firm? Really intelligent people who are typical computer users sometimes don't even know that you can grab a title bar to move a window. Seriously, who has technical knowledge in any given field that doesn't end up helping/teaching their family and friends who don't possess the same knowledge?

The people I deal with are very high end (look where I am) and but not once in the ~30 years I have been here has an end user complained to me that the "Save as..." in a program was unsafe because it let them choose a nonconservative file format!

Interestingly enough, you just disqualified yourself from working with "typical end users"... you deal with "high end" people, they're by definition not typical. Therefore your arguments about what typical people want or need have to be taken with a grain of salt.

Cheers, Josh

On 08-Mar-2013 12:28, John Cliff wrote:

(Speaking of bugs, your "reply" in Roundcube mangled the heck out the message you sent, chopping it off about 1/4 of the way down. I had not seen that before).

Right, cos non of us are the ones who admin user forums, have been responding to user emails, and talking to folk in chatrooms for

...

multiple years... oh wait we are.

Perfect, so you have lots of feedback from end users. In all that time how many nondeveloper end users have requested the proposed change to Save and "Save as...". Any? I maintain that Export and the redefinition of Save and "Save as..." are solutions in search of an actual problem.

I spent a while looking through the google results of: inkscape export "save as" searching for evidence of demand for this feature by the end users (as opposed to the developers). There was this:

https://bugs.launchpad.net/inkscape/+bug/171054

which (to my mind) revolved more around the implicit "and set 'Save' to also write to this file" in the current "Save as" issue than it did the core Export/Save as issue (conservative file formats only in save/save as). Ie, that's the "Save a copy as..." issue, not the "Export" issue.

I also found one example in the first 10 pages of that search of an end user requesting something like this:

https://bugs.launchpad.net/inkscape/+bug/170894

However that bug report to my mind completely skipped over the observation that Inkscape has neither a PS or EPS open function. That is, the issue was that EPS was a write only format.

And there were lots of developer discussions. No din of end users asking for export though.

...

once in the ~30 years I have been here has an end user complained to me that the "Save as..." in a program was unsafe because it let them choose a nonconservative file format!

So people who one would hope are highly educated and computer literate can use computers? no shit sherlock. Doesnt take a caltech >education to work that one out. The very fact your in an environment that is probably very much non average for inkscape users makes >your observations less useful. so yeah, I'll look where you are, and then take your observations with a pinch of salt.

The point was that these folks are about as technically sophisticated a group of software end users as you are likely to encounter. Yet even they have not been asking for the proposed changes to "Save", "Save As..." and the addition of "Export".

With for TSM until they hit save and get a warning they have no idea if its conservative or not. the other way its defined by the top level choice.

That tells us that the current warning message is poor (uninformative) and/or the function that generates it is primitive. I have not looked at the code, but I suspect the latter. That is, it emits the same message no matter what is in the original drawing. Inkscape can do a perfectly conservative save to other formats, EMF for instance, if the contents of the drawing are compatible with that format. Even the "round trip" requirement may be satisfied. Yet Inkscape still warns in these cases. With the possible exception of SVG filters it does not look difficult to actually make up a list of what has and has not been lost, such that the actual problems, rather than a hypothetical loss, could be accurately shown to the end user. For instance, at present in EMF export Inkscape's hatch patterns are all converted to a single EMF hatch pattern. This is because the SVG pattern method is not very compatible with EMF (the converse is not true, Inkscape imports all EMF patterns). So under "data loss", or whatever this would be called, the string

Inkscape hatch patterns were irreversibly converted to a standard EMF hatch pattern.

Could be added when this occurs. Others that would show up are:

Transparent and partially transparent objects are now opaque.

Gradients were emulated with multiple colored objects.

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

On 11-Mar-2013 12:44, Josh Andler wrote:

On Mon, Mar 11, 2013 at 10:44 AM, mathog <mathog@...1176...> wrote:

...

I also found one example in the first 10 pages of that search of an end user requesting something like this:

https://bugs.launchpad.net/inkscape/+bug/170894

However that bug report to my mind completely skipped over the observation that Inkscape has neither a PS or EPS open function. That is, the issue was that EPS was a write only format.

That bug report from a user explicitly made a request and you intentionally ignored part of it:

"Generally speaking, if the format used to save the current image handles less informations than the initial one, the export function is very useful..."

I ignored lots about that bug. The OP was clearly confused since he/she thought once a drawing had been saved in EPS it was necessary to close the drawing and reopen it. That is, he/she did not understand that everything was still in SVG within the program, no matter what the file name was at the top of the window.

You also ignored that another user added a +1 and explicitly spelled out the paradigm. Also, let's nullify part of your argument because I can open (import) EPS and PS files just fine here. You may have issues with that out of the box on Windows, so let's Google "inkscape windows eps"... hmmmm within the top 12 results I got for three results of different people asking how to import eps being asked by users. Three results for download sites all phrasing it as "import" for eps and the raster formats. Three results for the inkscape site which has no use of "import" or "eps" on that page. Summary: 6 results of which mention the import of the format explicitly without searching for it. 3 waste results (no mention of eps on page). And yes, 3 results that talk about opening eps. Either way HALF the number of results using "import".

Keyword hits are pretty worthless in this realm. People use "open", "import" and even "load' as synonyms, ditto for "save", "export", or "write". Pretty sure that the mental model most of these people are employing when they use import/export is analogous to import/export with regards to shipping commodities. Anyway, I had to read a bit in each thread to see which ones were using "export" in the manner proposed for the Inkscape interface change.

...

The point was that these folks are about as technically sophisticated a group of software end users as you are likely to encounter. Yet even they have not been asking for the proposed changes to "Save", "Save As..." and the addition of "Export".

Thank you for again reiterating that you know nothing about normal users. Apparently you only know the most advanced users on the planet.

You would be surprised at how many of them are not the cutting edge software techno types you would expect. Anyway, ignore my experience and consider Microsoft's. They have hundreds of millions of copies of their programs in circulation, and yet even their most sophisticated programs like Powerpoint, which has the exact same "data loss if not native file format" issue as Inkscape, use just "Save" and "Save as..." for each slide. (OK, within a slide there is also a "Save as picture..." for when some objects are selected.)

Never mind whether or not you agree with that choice, just consider that 80% (or whatever the actual number is this month) of all computer users think that style of "Save"/"Save as..." is the way computers are supposed to work.

Actually, the real goal is to NEVER have to warn users. That is bad design by definition. There were a number of discussions about this in the past and warnings mostly started showing up after a majority of most of our experienced software developers moved on. Note: By experienced I mean people who actually write user-facing software for a living. The key is, if you don't allow users to step on their own toes, no warnings are needed.

Would that it was that clear cut! There are always going to be trade offs between safety and utility. (Not just in software, pretty much everywhere.) If the program can keep the user safe without impeding productivity then yes, warnings should be avoided. But that is a huge "if", and the proposed Save, "Save as", Export changes do negatively affect productivity. If a user saves in a format other than Inkscape SVG they should be warned when something is actually lost, but not when it is just hypothetically possible that under some conditions that format might result in data loss. If a user chooses to work in some other format that is no reason that they should lose the ability to use Save (especially with ^S) and "Save as" just because somebody, somewhere, might screw up and lose some data.

Also, if you are all so hot to save the end user's data, why are you not jumping on the autobackup bandwagon, rather than riding off into the sunset on "Export" (to mangle a metaphor)? Making copies of input files when they are opened is the only sure way I know of to keep users from erasing their data while using a program. Otherwise they may delete something in a drawing they should have kept, and then save over the input file, losing that "something" forever. Neither "export" nor "save as..." can protect them from that common scenario.

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

It's discussions like this that make me glad that I'm just a cleaner. As far as I can see, any behaviour change that provokes such a polarised response from the devs is also likely to polarise users. Is it worth it?

Back to playing with compiler flags I go... On 9 Mar 2013 00:16, "Johan Engelen" <jbc.engelen@...2592...> wrote:

On 8-3-2013 19:15, John Cliff wrote:

...

http://dictionary.reference.com/browse/export

I've always taken export to mean what 3) on that page says -

Hi John,

I think a dictionary definition makes for a very bad argument, no? ;-) We stick/mold a word onto functionality, not the other way around.

...

like I said, I believe its wrong that we claim to open anything other than SVG, we dont, we import/translate them into an svg with varying levels of success. likewise, we can only save an svg, anything else is an export with a varying level of compatability.

You are correct that we translate everything to SVG. It is a good point. We have to translate to SVG, there is no other way for the code to handle things!

But, don't you agree that being able to use Inkscape as if it is a PDF-editor is nice? (I mean the open/edit/save workflow, in contrast to a (worst-case) open new/import/edit/export workflow, where the export button means you have to click more stuff to select file type, etc, and there not being a quick shortcut like Ctrl+S). We shouldn't advertise Inkscape as a PDF-editor, but it would be a shame to remove the functionality and it would make me very sad.

Cheers, Johan

---

Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 10-Mar-2013 00:18, Martin Owens wrote:

On Fri, 2013-03-08 at 18:15 +0000, John Cliff wrote:

...

we import/translate them into an svg with varying levels of success. likewise, we can only save an svg, anything else is an export with a varying level of compatability.

Does this mean we want inport to not insert into the current document, but open non-svg formats in a new document?

Since you brought up the insert issue...

Currently "Open" creates a new document for the file and "Import" places it in the foreground document. In many applications there is no "Import", or it is the complement of the sort of "Export" which is being discussed here. In my experience what Inkscape currently calls "Import" is more often called "Insert" in other programs, sometimes even as a top level menu. For instance, PowerPoint is that way.

In trunk under the file menu there are (many others left off)

Open Open Recent... Revert -------------------- Import Export to PNG Import Clip Art

The bottom 3 each have a little icon and an arrow to indicate direction. If I were setting it up from scratch I would have used Insert instead of Import, but since it has been Import for a while, and the meanings are fairly close there isn't a compelling reason to change it. Anyway, with "Import's" current meaning, by symmetry the file menu is missing

Import Recent...

but why should the "recent" list only apply to input? Why not also:

Save to Recent... Save a copy to Recent...

?

Implementation would not be hard, but nobody wants all 4 of those on the file menu, they would take up too much space. Seems like the sort of case where the options should be hidden in a submenu. This suggests using the more general single entry:

File->Recent Files...

which would bring up the submenu options: Open, Import, Save, Save a copy. (Maybe Save as... too? Probably only rarely used because the name sets the type, but it could be employed to change an existing file from Inkscape SVG to plain SVG, or vice versa, where the type is ambiguous.) Below each of these submenu options would be the same pull down list of file names as "Open Recent..." currently shows. The Inkscape menu system already has submenu items, like Object->Clip, so using a submenu here would not be introducing a new GUI element.

This change might be useful to a lot of users. For instance, in my work there are often lots of files in a directory, so "Open" or "Save as..." (if a file is to be overwritten) involves a lot of scrolling and clicking to find the right file. With File->Recent->Open/Save the list of files to select from would be much shorter. In other words, it should reduce clicks and mousing and make using the program more efficient.

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

On Sat, 2013-03-09 at 02:45 +0400, Alexandre Prokoudine wrote:

The GIMP team's decision didn't ignore anybody. You don't have to believe it, of course, and go on with your grievance. It's up to you.

I'm aggrieved every time I used Gimp and saved. I curse gimp developers every time. I wish to not buy them beer. I wish not to give them cake. Eventually I patched the menu so Export is called Save and moved up. Fixed.

Personally, I'm tired of explaining how and why it was done. If you don't want to listen, there's no helping you.

I'm not convinced by your rudeness that hurting users was really the best way to go. I've read plenty and it's just not convincing.

What's ironic is that Inkscape's change would effect me much less. I work in svg and export to png. I never work in xcf and that's why it had to be patched, because xcf is rubbish at being used on the web and I never had a usecase for saving them.

Martin,

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

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

Just my 2c.

First c. I'd consider also the 'import' point of view. That is, why there should be an 'import' feature if 'open' already manages the same file extensions?

From the user point of view either there are different extensions available

under the two dialogs or the two operations will be considered to be the same. Given this assumption, I think that 'export' should be for what has passed through 'import', to enforce the fact that the file has been converted to Inkscape format, edited and then reconverted back to the original one (or another). If I 'open' a file, I also expect to 'save' it in the original format, not to 'export' also if there is some sort of loss. The same applies for Windows' Paint: you can open and save JPG and you know (or are warned) that it's a lossy format. So, IMHO if you decide to move all save functions under 'export' to follow a point of view (rather than a real technical justification or a _common_ practice), to be fully coherent you should also move all open functions (but SVG) under 'import'. Doing otherwise would break the whole concept.

Second c. These features are not so young: many programmers have already implemented them in a lot of programs out there. I'd say that there is a "standard" for them or at least some behaviour that all more-than-the-last-year users already know or have got used to. Personally I have a very clear idea of how things should go and I don't like when programs chose their personal solution without a good reason for it. In other words, if someone has a great idea for improving what already exist then go for it! Hopefully other will see and start using it making it spread. But if it's only a matter of reinventing the wheel making it oval because circular already exists... :)

-- View this message in context: http://inkscape.13.n6.nabble.com/Your-opinion-about-Save-as-expor-tp4966175p... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Well, I agree and don't agree. :)

Alexandre Prokoudine wrote

However right now importing is mostly for adding any kind of files to the currently opened document, and hence that would be messing up two use different cases.

Good. So, if this is the criterion (on which I could agree, but it's not important), why not applying it to 'export' and 'save as...' too?

Alexandre Prokoudine wrote

Apps that mix various content and have concepts like layers or tracks [...] are project-based (just like Inkscape, really), and hence none of them saves back to original files. They export or render.

Actually I can't see Inkscape being project-based. I feel it being more document-based. And project-based programs only open 'projects' or 'import' contents while Inkscape can open many different 'document' formats converting them into Inkscape 'documents' (not 'projects' using them). Would you define saving a PDF a 'rendering'? Or would you define a BMP a 'project' to 'render' a JPG?

Alexandre Prokoudine wrote

Even though we tend to forget, Inkscape is an _SVG_ editor. That's its definition.

I agree. And, to me, an SVG file is a document, not a project.

I understand that an SVG file can be used in a workflow as a 'project' for producing a different outputs (e.g. a PNG file). But it's not the only workflow nor the main one (Inkscape is an SVG editor, no? So SVG in -> SVG out). Think about opening a PDF, slightly modifying it and saving back to PDF. In this case you don't need a project nor import/export. Inkscape _behaves_ as a PDF editor (also if it's not) and I feel this is a good thing. Why take it away? I think that many Inkscape users take advantage of it. I do.

P.S.: thanks for your reply. I don't want to push this too far too, just give some points to people to think about.

-- View this message in context: http://inkscape.13.n6.nabble.com/Your-opinion-about-Save-as-expor-tp4966175p... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Uhm... from our homepage:

About Inkscape

An Open Source vector graphics editor, with capabilities similar to Illustrator, CorelDraw, or Xara X, using the W3C standard Scalable Vector Graphics (SVG) file format.

I understand that we have people who have worked really hard to support lots of features in other formats, but realistically it's because those developers had itches to scratch. Bulia Byak, as a graphic designer, implemented tons of features and a better support of lots of things because he needed those things. Likewise, I bet your interest in improving EMF support is because it makes your life easier (and of course it's awesome that it will help lots of other people).

But let's not kid ourselves... if we just wanted to make the best object oriented vector graphics program, we wouldn't have chosen to limit ourselves by format. There is a lot that can't currently be described in SVG and to which there is no way to work around without raster hacks to support other renderers.

Cheers, Josh

On Thu, Mar 7, 2013 at 2:21 PM, mathog <mathog@...1176...> wrote:

On 07-Mar-2013 06:33, LucaDC wrote:

...

Inkscape is an SVG editor, no?

Actually, no, it is much more than that. Inkscape is the best free object based drawing program, and provides a good alternative to Adobe Illustrator. In most ways I like Inkscape much better than Illustrator. Inkscape happens to store its drawings in a slight variant of standard SVG, which is convenient in many ways, but that is not the end of the story. Often we need that drawing in another format, PDF, or EMF, or whatever. Inkscape is able to convert between many of these other formats and its internal SVG format, often with no or minimal losses. For instance, for EMF, which I am painfully familiar with, the majority of EMF record types can be imported into SVG with no loss, and then saved back out again to EMF, again with no loss. (Here I am describing the cross platform lp988601 branch, not the release branch, which has more limited EMF support, and then only for the Windows platform.) There may be some neutral conversions from one type to another (a rectangle might become a polygon of the same size and shape). There are a few areas that are not quite fully implemented yet (for instance BKMODE, or gradient import) and others which most likely will never be fully implemented (like the raster operation specifiers for BLT operations - which are not object based). But those quibbles aside, one could equally say that "Inkscape is an EMF editor". The statement is true so long as one avoids the drawing options within Inkscape that cannot be translated to EMF. One can easily imagine code modifications which would disable these functions when an Inkscape document is created by reading an EMF file, making the statement entirely true. (I am not proposing that, just saying that it would not be hard to do.)

Look at the two example EMF images here, which contain examples of most types of EMF records:

http://sourceforge.net/projects/libuemf/

Both of those can be loaded into Inkscape and written back out again, and the only parts that will be lost are the two little rainbow colored gradient regions at 9:00 in the unrotated image (gradient import is not yet implemented - there seems to be a deep bug in Microsoft's own software regarding the handling of linear gradient records from EMF files, which makes testing in this area very difficult.) Inkscape can already export its own gradients to EMF, but it is an emulation, sending out a colored gradient composed of overlapping thin objects that in sum looks like the original gradient. This is typical for EMF export in most programs, I think because others have also been unable to work around the MS gradient bugs. (It is not widely appreciated, but AFAIK no windows program can save and retrieve a simple gradient record to an EMF file. It just looks like they can because they all use this same emulation technique.)

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

---

Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Thu, Mar 7, 2013 at 3:40 PM, mathog <mathog@...1176...> wrote:

On 07-Mar-2013 14:59, Josh Andler wrote:

...

Uhm... from our homepage:

About Inkscape

An Open Source vector graphics editor, with capabilities similar to Illustrator, CorelDraw, or Xara X, using the W3C standard Scalable Vector Graphics (SVG) file format.

That does say "Vector graphics editor", not "SVG editor".

Or if you visited the homepage to verify my claim you would have seen this graphic above that text: http://inkscape.org/images/header-image.png

The language from it "Open Source Scalable Vector Graphics Editor" does indeed double down on it with that text I pasted which breaks down the SVG acronym.

Cheers, Josh

Illustrator is graphic design software. It is tailored to it. It's also used for technical work and in a ton of other fields/workflows. We don't need to argue that calling something a tool is a broad categorization. But just because you can whack a nail into a board with the back side of a screwdriver or the side of a saw doesn't make either one a hammer. It's a tool, it was created for a specific purpose. If you can and choose to use it for other purposes that doesn't change what it's original intended use was for.

On Fri, Mar 8, 2013 at 10:24 AM, mathog <mathog@...1176...> wrote:

On 07-Mar-2013 18:19, Josh Andler wrote:

...

The language from it "Open Source Scalable Vector Graphics Editor" does indeed double down on it with that text I pasted which breaks down the SVG acronym.

You guys need to set Adobe straight. All of these years they have been erroneously marketing Illustrator as "graphic design software" when apparently it is really just a ".ai editor"!

_Of course_ the core/native file format used by Inkscape, Illustrator, Powerpoint, etc. restricts each program's capabilities to those that can be represented by some data structure within the file. However, that is not at all how end users think about these programs. They categorize them by the sorts of things they do, and rarely if ever give a second thought to how the data is being organized within the files they save. Perhaps to some of the developers Inkscape is an "SVG editor", but to the vast majority of its users it is a "graphics editor" (or some variant on that term).

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

El 08/03/13 15:24, mathog escribió:

On 07-Mar-2013 18:19, Josh Andler wrote:

...

The language from it "Open Source Scalable Vector Graphics Editor" does indeed double down on it with that text I pasted which breaks down the SVG acronym.

You guys need to set Adobe straight. All of these years they have been erroneously marketing Illustrator as "graphic design software" when apparently it is really just a ".ai editor"!

As far as I can remember, AI has an export dialog too, and that's used for lossy formats. Also when you open non-native formats AI appends the name "converted" (it think it was converted, or imported. I can't remember) and when you save it will offer AI as fromat. You have to explicitly change the format if you want to save an imported project into a non-native format.

Anyway, to be fair I have to say that the save command allows other formats than .ai, but those are formats are vector formats (non-vector formats have to be EXPORTED).

So, I'd say that Adobe Illustrator doesn't actuall allow to "save" to other vector formats, it rather uses the save dialog to export.

You can't do rountrip open > save workflows with illustrator and not native formats (notice that the current AI format is a PDF with some extra sfuff, so it's treated more or less like a native file).

Your example doesn't exactly endorse your position. Illustrator imports bitmaps, export bitmaps, opens vector files but the actually imports them (it offers its native format for saving them back). It just "saves as" non-native formats if you expressely change the format.

I'd say the only high end example I know that does things as you say it's Photoshop, hence the huge debate when GIMP changed the way it works. The other programs I know and used seem to support open and save for their native formats and all the rest is supported through import/export.

Gez.

On 07-Mar-2013 15:41, Johan Engelen wrote:

I don't think there is anything wrong/superfluous with the functionality of the current state, there is only functionality missing.

Agreed. Obviously I do not think we need Export at all. However, there are things missing from "save as" which in many instances would be very helpful. By going this route we could also eliminate the snapshot "export" entry from the file menu.

"Save as" would have these extra options:

1. Objects: all, selected, !selected. 2. Layers: all, current, !current, list: [list of layers] 3. On save: overwrite, create higher numbered version 4. Region: all, drawing, area: [xul,yul xlr,ylr] 5. Formats: all, lossy, lossless

The default would be as now: all, all, overwite, all, all. These options might be kept hidden in the default "Save as", with a "more options button" that to expand the menu, but any that were not at the program default must be shown.

1. Explanation - self evident. I don't think a list of objects here would be very helpful, as the number of objects typically saved is so large. If an object is to be saved anything in <defs> that it needs would also be saved.

2. Layers - mostly self evident. This is almost perfectly analogous to the page print options in most print drivers. One issue would be that layers can have any name, so listing them by name would be a lot of typing. A good solution to that would be to allow them to be listed by index number (1 to N I think, not 0 to N-1). The indices don't need to be static through the session, and they should also be shown in the layers dialog, perhaps between the eye and lock symbols. A list like "2,5,7-10,13" should be allowed.

3. On save - implements a simple data protection scheme. Overwrite is what Inkscape does now, and it is certainly capable of amplifying an end user's mistakes. The "create higher numbered version" option would be a little tricky because our target platforms do not normally have file version support enabled. One way to do it here if file numbering was enabled would be:

open test.svg (no numbered versions present) work... save (copy test.svg -> test.svg.0, save as test.svg) work... save (copy test.svg -> test.svg.1, save as test.svg) save (do nothing, there have been no changes) work... save (copy test.svg -> test.svg.2, save as test.svg) exit (if no changes since the last change, do nothing. otherwise: copy test.svg -> test.svg.3, save as test.svg)

In other words, the version with no number is the highest numbered version, effectively it is +1 from the highest explicitly numbered version. Same mechanism for any other file extension, of course. The older copies would most likely not be recognized as .svg files, but that isn't really their purpose, they are there to serve as backups. Inkscape would have to know how to scan for those sorts of files and offer to open them with the "real" extension. The name could also be something like *.svg.inkback.1, which would likely make finding them a little easier. "test.svg" would have to be locked throughout the save, to avoid problems if another application, especially another copy of inkscape, tried to do the same thing simultaneously.

Where there are numbered versions there is usually a way to trim the list or purge older versions. We can discuss that issue if/when versions are implemented.

4. Region - self evident. The area could by two points (UL,LR as here), or point,W,H. This gets rid of the current "export as bitmap" (or whatever it is called), and generalizes it to all supported output formats.

5. Formats - to make the SUM proponents happy, yet keep the behavior optional. Could we all accept that? The terms "lossy" and "lossless" are not ideal, but you get the idea. When these are selected it would grey out or remove the excluded members from the file type list.

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

On 06-Mar-2013 16:55, Chris Mohler wrote:

On Wed, Mar 6, 2013 at 6:32 PM, mathog <mathog@...1176...> wrote:

...

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.

File->Save File->Close File->Open (same file)

If things are missing or changed from step #1, it's not really much of a "save". And I fail to see how using one shortcut instead of another is "having to relearn an important part of the user interface".

The 3 command sequence described above is fine, and that is what happens, and what should happen, when the document creation or Inkscape SVG open (both implicit step 0) has taken place. What we are debating is the meaning of "Save as" and its proposed _redefinition_ which is needed to allow the addition of the proposed "export". In my opinion, and a lot of other peoples', these changes are unnecessary and counter productive for the majority of users. Google for "save as vs. export" and you will find lots of unhappy end users when similar changes have been made elsewhere, notably in GIMP. What you won't find are lots of naive end users demanding these changes before they were implemented.

Historically, and I mean going all the way back to the oldest GUIs (some of which I am old enough to have actually used) the following meanings applied:

1. Save as... (no standard keyboard shortcut, often Ctrl-Shift-S, file menu selection is "Alt-F S" on Windows) Save the file with a new name and possibly also a different format. [Emphasis]It was never intended that these operations would all be conservative[/Emphasis]. Some were of course, but most were not. For instance, saving an MS Word file to plain text was obviously never a conservative operation. Most programs warned when something could or would be lost.

2. Save (keyboard shortcut ctrl-S or apple-S or the equivalent standard for the user interface, file menu selection is "Alt-F A" on Windows) If the working document started from an opened file, save back to it in that format. If a previous "Save as..." had been executed, save to that file in that format. If the document is "new" execute a "Save as..." with the default file format (always conservative) and sometimes a default file name.

3. Export Historically there was no such thing, only "Save" and "Save as..." were used.

I will refer to this for brevity's sake as TSM ("the standard model"). It is pervasive and describes the majority of all applications and notably, as far as I can tell, is used in all of the most common Microsoft applications. In other words, for a lot of people the first two operations have been trained into their wrist ganglia and they do not even think specifically about how they induce these operations, they sort of "just happen". (Similar to typing in one's password, where, at least for me, my hands do the work and I am not consciously thinking about the actual sequence of letters, numbers, and/or symbols.)

Recently the theory has been espoused that the ability to do a nonconservative "save" is dangerous, even if the user is warned, and that the code should "help" the user avoid this tragedy by altering the user interface away from TSM. This theory says that both "Save" and "Save as..." must be conservative. Unfortunately, as I mentioned in a previous note in this thread, the only way to accomplish this is to restrict the supported save formats to whatever the native file format is for the program, perhaps with a few minor variants (compression, older versions, and so forth). These special formats are rarely if ever the desired end format of the person using the program, but they do support every possible document feature. In this model:

1. Save as... (same shortcuts as above) Save the file with a new name in a conservative format. Naive end users will in many cases have no idea what these formats are (ai, xcf, and so forth). If the session was started by opening a file of another type this will change the type of the file stored back to disk to a conservative type.

2. Save (same shortcuts as above) Save the file with a conservative format and the same filename root as a prior "Save as..." or "Export". If the session was started by opening a file of another type, or an "export" to a nonconservative type has been performed, this will change the type of the file stored back to disk to a conservative type.

3. Export (no standard shortcut, no standard file menu selection) Save the file with a new name and a nonconservative format of the user's choice.

I will refer to this as SUM ("Stupid User Model"), since its purpose is to save a dumb end user from losing data by unknowingly saving data to a nonconservative file type.

If the user happens to be working in the program's native file type then "export" will never be used and the program will behave the same as in TSM. However, if the user is NOT working with the native file type, and they are used to TSM, then this is a radical change. From the end user's perspective "save as" is broken because it no longer allows selection of the desired output type. Similarly, "save" is broken in several ways. The first is that if a file of another type is opened, "save" will insist on converting it to the conservative type, which is typically not what the end user wants to do. The second is that when a previous "Export" has been applied to specify the desired output filename and type, save will override the chosen type and default back to the conservative type. The end result is that to save the file to disk as the end users desire they must always employ Export. There is no short form of Export analogous to "Save". Moreover, since "Export" is not part of TSM, there is no standard keyboard shortcut for it. In GIMP (2.8.2) they bound "Shift Ctrl E" to "Export", but there is no keyboard navigation to it, at least as I see it, since "Alt F" pulls down the file menu, but no letters under "Export" are underlined.

For myself, the net result of the SUM changes in GIMP were a degradation in the end user experience. I never had the problem these changes were trying to solve, since I knew already when to save in a conservative format, and when to save in a nonconservative one, so these changes did not "help" in that regard. What they did do is cause me to make numerous saves in the undesired xcf format when I reflexively did a "ctrl-S" followed by an "enter". Even though I know this change is present, since I do not use GIMP frequently, I still reflexively select "save as..." the first time in most sessions, then have to back out, and do "export" to get it to do what I want. I rarely remember the shortcut for "export", as it is nonstandard, and find having to select "export" with a mouse for all of my desired store to disk operations an obnoxious feature of SUM. In summary, these changes only degraded my interaction with GIMP, while providing me with no benefit whatsoever.

The proposed SUM changes to Inkscape would be even more annoying for me than the changes to GIMP were. A great deal of my work with Inkscape revolves around EMF files, I darn well want to be able to open and save those TSM style, and I want my intended end users to be able to do so as well. That we cannot save a filter (for instance) to this format is perfectly acceptable, and having to deal with "export", instead of the STM mechanisms is a net loss in usability for us.

Also, does anybody have evidence that SUM actually saves naive end users from damaging their data? Perhaps it might in some instances, but since there are so many other ways to destroy a drawing, I suspect that the users who were naive enough to lose data through the STM "Save" "Save as" mechanism are probably also degrading their drawings in countless other ways, including minimally, drawing something unintended and then not being able to undo, or applying excessive compression.

How pervasive is TSM and what sort of inroads has SUM made? That is, is there a clear trend from TSM to SUM? Below are the results of a quick survey of some programs on my PC and the first Mac I could find. This table will only look right with a fixed size font, notes are indicated by {number}.

Program Name Save as Export Platform Model MS Word (2010 & 2003) Y N WinXP TSM MS PowerPoint (2010 & 2003) Y N WinXP TSM Firefox Y{1} N WinXP TSM Internet Explorer 8 Y N WinXP TSM Opera Y{11} N WinXP TSM MS Paint Y N WinXP TSM MS Wordpad Y N WinXP TSM ImageMagick Display (1.0) Y N WinXP TSM ImageJ Y N WinXP TSM Chemsketch 12.0 Y Y{2} WinXP TSM Inkscape 0.48.4 Y N WinXP TSM Gimp 2.8.2 Y{3} Y WinXP SUM Scribus 1.3.7 Y{4} Y WinXP SUM LibreOffice 3.6 Draw Y{5} Y{6} WinXP SUM LibreOffice 3.6 Write Y{7} Y{8} WinXP ~SUM Adobe Illustrator CS3 (13.0.1) Y{9} Y{10} Mac SUM Adobe Elements 9 Y N Mac TSM Povray 3.6 Y N WinXP TSM

{1} slight variant: "Save page as" {2} In this program "Save as" and "Export" are synonyms, they list the same file types {3} variants of .xcf {4} variants of .sla {5} variants of .odg {6} 20 common image and object drawing formats {7} variants of .odf and many common word processor formats {8} PDF, .xml, and "MediaWiki" .txt {9} .ai, .eps, .pdf, .svg {10} many common image and object drawing formats {11} Top bar "Save" button invokes the same dialog as "Save as" from the Opera->Page menu.

The results of this limited sample indicate that TSM is pretty much everywhere on Windows and present on at least one commercial program on Macs. SUM is present in a single commercial application (AI CS3) and a few open source programs. There are a few which were a little hard to categorize: LO Write listed some file types in "Save as..." which are so old that I doubt they are fully conservative. I cannot but help wonder if the move to SUM for this group of programs is being advanced by a relatively small cadre of programmers, without benefit of any real analysis of the actual requirements of the end users, or of any demand for this on their part. (Some of the people pushing for this in Inkscape seem to have played the same role in GIMP.)

Finally, what is the evidence that the problem SUM addresses is really so serious that we should consider moving away from TSM? Have any of the developers ever had a naive Inkscape end user actually request the SUM behavior??? (We can count a report of an instance where data loss could have been avoided had SUM been implemented as a request.) Personally I think that if a user did lose data in this way they would learn from their error and not make that mistake again, obviating the need for that user for the SUM change going forward. (Conversely, if they are to dim to learn from this simple error, then SUM isn't going to save them from themselves in hundreds of other places in Inkscape, where plenty of other things can go wrong.)

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

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. We can "open" PDFs but some things can be lost in translation. Inkscape actually imports a PDF and converts it to SVG, and when it "saves" it back, it is actually exporting the SVG tree to a PDF document. Even making the process of importing and exporting that data perfect (which is not at the moment and I wouldn't hold my breath waiting for it to be so) it's still an import/export process. Data is translated into different data.

So, let's forget for a moment what programs usually do (although I'd like to see statistics about how many high end programs that support multiple formats do it through open and save commands and don't provide an export command for lossy formats). Let's focus on a reasonable workflow which minimizes the confusion and data loss.

GIMP devs did this and it resulted in popular outrage, but all the people ranting about it are ranting because their use habits had to be changed, not because the changed made the things worse. In fact, I don't think I heard anybody saying that now is more likely to loose your work or overwrite your original assets with edited than it used to be.

I think it's ok if Inkscape minimizes the risk of overwriting a multiple page CMYK PDF with a single page SVG. I think it's ok if inkscape prevents users from overwriting a JPG wih a SVG with jpg extension. Actually, I'm not only ok with that. I would prefer that Inkscape has a consistent command to open and save native, editable files and leaves the rest as import/export, because it would make more sense. Right now there's a weird mix: You can save and export to PNG, you can only "save" to PDF but the PDF format requires the rasterization of several editable objects (blurred objects, for instance) which will render them uneditable.

The only reasonable argument against this change is "hey, I'm used to it and I'd prefer to keep it this way", but it's not a compelling argument. It's just status quo and not necessarily the best solution for the problem.

Gez.

On Sat, Mar 9, 2013 at 12:14 AM, mathog wrote:

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.

:D

We actually did a thorough study around 2009, how well various software supports WMF. In short, no software is capable of opening WMF perfectly. Not even Microsoft's office suite, or Adobe, or Corel.

Alexandre Prokoudine http://libregraphicsworld.org