As a Tech Writer, UX tester, and newbie Inkscape user: Regarding Bit Barrel’s comments, I agree about not having both ‘Save As’ and ‘Export.’ Confusing. Photoshop uses Export for saving pieces of the art such as paths.
Also, the User Manual (or Guide?) looks very good BUT it is not searchable. It would be easy to take the current pages (.html or .xml) and import/convert them into a navigable, searchable compiled Help file (whether Web Help or compile .chm file).
And, even though I’ve set preferences to Remember Last Window Geometry, it doesn’t remember the dialog layout, i.e., Layers Dialog, the Undo Dialog, etc. ( Version 0.48).
Sharpart
On 2015-03-06 01:46 (+0100), Roger Sharp wrote:
And, even though I’ve set preferences to Remember Last Window Geometry, it doesn’t remember the dialog layout, i.e., Layers Dialog, the Undo Dialog, etc. ( Version 0.48).
The feature to restore the dialog layout from the last session is new in Inkscape 0.91 and not available in Inkscape 0.48.
See also: http://wiki.inkscape.org/wiki/index.php/Release_notes/0.91#Dialogs
Regards, V
El jue, 05-03-2015 a las 16:46 -0800, Roger Sharp escribió:
As a Tech Writer, UX tester, and newbie Inkscape user: Regarding Bit Barrel’s comments, I agree about not having both ‘Save As’ and ‘Export.’ Confusing. Photoshop uses Export for saving pieces of the art such as paths.
Whatever the final decision is, I think this is an issue that has to be discussed enough to evaluate the pros and cons of such change. What Photoshop does is completely irrelevant since it's a completely different program and although it's very popular and considered some "industry de-facto" we shouldn't be making decisions based on how PS or any other program does things.
The argument for save/export separation has pretty compelling reasons, keeping one format for the "project", which keeps all the data and it's 100% editable being the most important.
It's all about avoiding the unadverted destruction of editable data. Everytime you save to a lossy format, you're storing a version of your artwork that doesn't keep all its original features and its editability.
GIMP devs understood that and implemented save/export as separate functions. Not everyone liked this change, but after some time things seem to have settled and people got used to it. I can tell that I've never saved a lossy format accidentally again, and it was something that happened to me several times with Photoshop and GIMP (before the change). But as I said above, we shouldn't care what other programs do. We should discuss what's good for inkscape.
In my honest opinion, since Inkscape is mainly an SVG editor, the save command should save SVG. Inkscape SVG is not exactply plain SVG, so it could be an option for the save command. However, any other format that doesn't keep the SVG tags should be considered a lossy output that should be treated in a different way.
I'm not even saying that separating save and export is the right way, but even if the features for exporting to lossy formats is stuffed in the same save dialog, there should be a special design that never confuses users into saving their valuable original art in a format that doesn't preserve the editability and data of what they created.
Gez.
On Sat, 2015-03-07 at 01:54 -0300, Gez wrote:
Not everyone liked this change, but after some time things seem to have settled and people got used to it.
Not really. I'm still aggrieved by it every time I open gimp and I tend to avoid using gimp because of it. It just makes editing workflows costly because xcf is a useless format outside of gimp and it's a nonsense to save an xcf to edit a png or jpeg you've just colour corrected.
At least svg is a web format which can be said to be useful and editable. So we'll have fewer issues if we did that. We don't have a PDF editing workflow for example, just PDF-page importing & creation as separate jobs.
Rather than go all Gnome on the design, we should test different workflows for something so important. Know what we're giving up if anything.
Martin,
FWIW Here is my considered opinion.
1. Save - should only offer formats where no information is lost. - it should not prompt for a new name if the file has been loaded and the location is writeable. 2. Save As - should always prompt for a new name (dialog) - use as default the load directory. If user saves to a different directory, use this new directory as the default for 'Save As' and Export operations. 3. Save Copy - should act like save but use an auto-incrementing version number as a suffix before the extension. 4. Export - means save to a file format that will lose data (all formats not available in Save) - prompt for directory, name. Use same name if already saved (different extension) - if user exports to a different directory than the Save directory, then remember this directory next time export is offered. 5. Import - means import a file into the existing scene. change nothing else indicated above.
FWIW - this system is consistent, clear and allows the user to control what they are doing. I think candidates for Save formats are SVG(inkscape), SVG. There may be others. The order they appear on the list should be by 'Importance'. Not alphabetical.
Cheers, Mark...
On 3/7/2015 6:09 PM, Martin Owens wrote:
On Sat, 2015-03-07 at 01:54 -0300, Gez wrote:
Not everyone liked this change, but after some time things seem to have settled and people got used to it.
Not really. I'm still aggrieved by it every time I open gimp and I tend to avoid using gimp because of it. It just makes editing workflows costly because xcf is a useless format outside of gimp and it's a nonsense to save an xcf to edit a png or jpeg you've just colour corrected.
At least svg is a web format which can be said to be useful and editable. So we'll have fewer issues if we did that. We don't have a PDF editing workflow for example, just PDF-page importing & creation as separate jobs.
Rather than go all Gnome on the design, we should test different workflows for something so important. Know what we're giving up if anything.
Martin,
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5751 / Virus Database: 4299/9241 - Release Date: 03/06/15
El dom, 08-03-2015 a las 16:01 -0400, Martin Owens escribió:
On Sun, 2015-03-08 at 16:28 -0300, Gez wrote:
it's just matter of getting used to it.
As designers of interfaces, we can not let ourselves fall into the
trap
of thinking our users 'can just get used to it'.
If you take that line out of context, of course. But that's not what I meant to say. So let me rephrase it: The change implemented by GIMP devs doesn't match your expectations. You expect that the save command does a certain thing but it doesn't. The reason why you expect what you expect from the save command is not the result of a careful interaction design that dictates that the best route is to stuff all the possible output formats in a single command, but your previous experience with programs that do that. That's what I meant you should get used to.
Part of the research arm is working out workflows. Our users will always invest in getting around our poor designs when they have to, but we should be on the lookout for such things before they ship.
And that's what Peter Sikking did while he was involved in the GIMP project, as far as I know. The save/export separation was the result of a research, and the distinction between those functions was what they considered the best way to provide a saner workflow and reduce the accidental destruction of data. From my vantage as a user, it worked. Can it be improved? Maybe, but despite the negative reaction of a portion of its user base, the new GIMP UI enforces a workflow where it's harder to screw hours of work on a complex file by accident. That meant that some simpler workflows had to be modified slightly. And yes, I do think that invoking a different command and learning a different keystroke is a minor annoyance that users can get used to and the problem just fades away once they do.
A lot of what I see in this thread are people choosing what seems like the more logical setup. But what is logically pure might not be good
for
human interaction. That's why we must test.
I agree that we must test and that the result has to come from a careful research of what works and what doesn't. Please, don't get me wrong: even though I don't agree with your perception of the impact that separating save and export had in GIMP I really do agree on that any decision taken regarding user interaction should be *designed* and not chosen just because of what others do or what users are used to.
Gez.
The "just get used to it" argument is good only for people that can use a single program. I use plenty of programs and all of them implement the same old, widely-accepted-and-expected paradigm for File->Open and File->Save as... This means "switching your mind" whenever you move from a program to another. How can you develop a strong and safe behavior if every single program does such a basic operation in its way? You can't say you worry about user's data safeness and still ignore such obvious considerations. Do you know how many times I absently hit the F1 key in a program and open the Help window? It's Inkscape's fault.
-- View this message in context: http://inkscape.13.x6.nabble.com/Save-and-User-Manual-tp4973054p4973103.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
9 марта 2015 г. 12:10 пользователь "LucaDC" <dicappello@...1761....2144...> написал:
The "just get used to it" argument is good only for people that can use a single program. I use plenty of programs and all of them implement the same old, widely-accepted-and-expected paradigm for File->Open and File->Save as...
In other words, you don't use:
- digital audio workstations; - non-linear video editors; - visual effects compositors; - 3D authoring applications; - 2D bitmap and vector animation apps.
And that's just off top of my head.
All of them do separate saving and exporting. It is a widely accepted and expected behavior. It's how they work.
We can go on discussing it like this forever :)
Alex
Alexandre Prokoudine wrote
In other words, you don't use:
- digital audio workstations;
- non-linear video editors;
- visual effects compositors;
- 3D authoring applications;
- 2D bitmap and vector animation apps.
Well, not all of them. So what? The point is: do you feel these are the most widely spread pieces of software that most people use? Can you say for sure that these are a good reference for what the largest part of Inkscape's users in general expect?
Anyway, just for completeness, I do use programs that implement the separate saving and export paradigm but there's no point in listing them here because...
Alexandre Prokoudine wrote
We can go on discussing it like this forever :)
this is exactly one of the point I wanted to rise with my previous post, and I'm referring to the "like this" part as I hope that the constructive part of the discussion will go on. Another point was that what people find "logic" is usually simply what they are used to. And we are not all used to the same things (well, fortunately, let me say). :)
I think that this argument deserves a real and serious discussion about what it really means saving your document in a different format and what it means exporting your document in a different format. It's not just a matter of personal taste, neither a mission to preserve superficial users from wasting their work. Also, being opening and saving basic operations that almost all softwares implement, it's wrong to consider what people expect just as an annoying constraint to be taken into consideration, so better ignore it (as I've read around about and just wanted to contradict). I suppose that everybody has an opinion on what 'open' and 'save' and 'save as' do or should do; I think that less people have about what 'export' do or should do and very few about 'save a copy'. And their opinions come, for sure, from the experience they've had with how these operations have been implemented in the pieces of software they use. Please, don't forget or try to ignore the "Principle of least astonishment".
Now, let me expose my <opinion> Personally, with the experience I've had with different softwares in different fields, I've developed the idea that if you "save as" you get a document that you can later reopen and edit without losing the peculiarities that the software you're using has; while if you export you somehow "translate" your work in something that cannot be easily taken back to the "intrinsic form" it had before the export from the point of view of the software. To be more explicit: if I save an Inkscape's SVG into PDF, I'll still be able to open it and edit it with Inkscape as its vectorial nature has been preserved; but if I export it to a PNG I'll no longer be able to open and edit it with Inkscape: I could still import it as a bitmap image in Inkscape but the vectorial form has gone and I cannot change the radius of that circle or the color of that transparent star with Inkscape's tools anymore. It's clear that saving a PDF will cause the loss of some properties of the document, as there's not a 1:1 correspondence between (Inkscape's) SVG and PDF, and it's even worse with other formats. That's why putting a delimitation line between which formats can be "saved as" and which should be "exported to" is not a trivial issue. And it strictly depends on the nature of the software we're dealing with. Consider a word processor: if you save as text you lose all formatting, but you can still reopen the text and edit it and apply another formatting as you need; sometimes this is even convenient. I wouldn't be too much purist nor conservative about which particular features could be lost when saving to a different format: this should be up to the user that chooses a format because he needs it, not because he's too stupid to know what he's doing. I think that what should be preserved is the big picture of the software's purpose. And, anyway, the already implemented "lossy save" warning is protective enough to me.
Personally, in a word processor I expect to find the ".txt" extension under the "Save as..." dialog. At the same time, in a word processor I expect the ".pdf" extension under the "Export..." dialog, because once the document is saved as PDF I'll no longer be able to open it with the word processor to edit it. (Of course, this is not true for a word processor that can seamlessly open and save PDF files: apply the next paragraph to it). Personally, in Inkscape I expect to find the ".pdf" extension under the "Save as..." dialog. At the same time, in Inkscape I expect the ".png" extension under the "Export..." dialog, because once the document is saved as PNG I'll no longer be able to open it with Inkscape to edit it. (Of course, this is not entirely true for, as an example, a multipage PDF, as Inkscape cannot autonomously deal with it; or even simply for a purely textual PDF given that Inkscape's abilities to deal with text are not (yet) up to a word processor).
IMHO, having Inkscape saving only in Inkscape's SVG format and exporting in everything else, hence putting PDFs and PNGs at the same level, would be a wrong decision.
These are only my thoughts. I'd be glad to hear also others'. </opinion>
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Save-and-User-Manual-tp4973054p4973145.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
11 марта 2015 г. 13:43 "LucaDC" wrote:
In other words, you don't use:
- digital audio workstations;
- non-linear video editors;
- visual effects compositors;
- 3D authoring applications;
- 2D bitmap and vector animation apps.
Well, not all of them. So what?
Let's not allow the conversation degrade to "so, what?", shall we? :)
The point is: do you feel these are the most widely spread pieces of software that most people use?
That is simply _not_ the point. My feelings are irrelevant. Inkscape shouldn't do what _someone feels_ is right. Inkscape should do what _is_ right. And that involves analysis and UX design.
For starters, you would need to define, what audience Inkscape should try to serve in the first place.
You can't say "we want everyone" (well, you can, but it makes no sense), because then every time you design a new feature, you would have to go for the common denominator, which is someone who got his/her first laptop yesterday and has very little idea about anything. You can't design UI/UX that is great for both novices and professionals, both map makers and desktop publishing folks etc. You can make it great for a few groups of users and more or less bearable for others.
Can you say for sure that these are a good reference for what the largest part of Inkscape's users in general expect?
No, and neither can you. There was no study, see?
In my experience listening to feedback from GIMP users after the v2.8 release, people who complained the least were people who GIMP has been targeting in the first place: people who work on challenging tasks and, by nature of their work, need to save XCF files (to retain layers etc.) to go back and edit them later. People who complained the most were people who either used GIMP for quick editing (for which GIMP is like a hammer to a bolt in the absense of a screwdriver) or were so sure they would never make a mistake that they would rather blindly click OK in the "Not safe to save to this lossy file format" and then close without saving to XCF.
And that's also another perspective on defining your audience: do you expect them to go back and polish their work, or do you expect them to mostly do quick edits of arbitrary file formats?
I think that this argument deserves a real and serious discussion about
what
it really means saving your document in a different format and what it
means
exporting your document in a different format. It's not just a matter of personal taste, neither a mission to preserve superficial users from
wasting
their work.
Exactly my point :)
It's clear that saving a PDF will cause the loss of some properties of the document, as there's not a 1:1 correspondence between (Inkscape's) SVG and PDF, and it's even worse with other formats. That's why putting a delimitation line between which formats can be "saved as" and which should be "exported to" is not a trivial issue.
Again, we agree here.
IMHO, having Inkscape saving only in Inkscape's SVG format and exporting
in
everything else, hence putting PDFs and PNGs at the same level, would be a wrong decision.
It also depends on how you define Inkscape. Is it a generic vector graphics editor where file formats are treated equally? Or is it more of an SVG editor, with *some* support for other file formats?
Alex
Alexandre Prokoudine wrote
Let's not allow the conversation degrade to "so, what?", shall we? :)
Sorry, it had to be a joke, maybe I should have placed a smile after it. I'm sorry you have taken the beginning of my reply as a provocation or, well... more than I intended to. :) After all we agree on almost everything.
Alexandre Prokoudine wrote
That is simply _not_ the point. My feelings are irrelevant. Inkscape shouldn't do what _someone feels_ is right. Inkscape should do what _is_ right. And that involves analysis and UX design.
I agree. It's what I was saying. Also if I'm not so sure that defining 'what _is_ right' is so easy. Actually, I'm not so sure that such an absolute definition can really exist, even after a very careful 'analysis and UX design'. That's why users' feedback is always welcome, after all.
Alexandre Prokoudine wrote
Can you say for sure that these are a good reference for what the largest part of Inkscape's users in general expect?
No, and neither can you. There was no study, see?
Sure, I can't and I didn't intend to. I've simply read about people saying that there's no point in looking around to what others have done because it's so clear what should be done that it's the only reasonable way to go. It seems that we both agree that a study would be welcome and individual personal impressions don't count too much until they are put together in significant numbers. IMHO, looking in the meantime to what other relevant software houses have done in the last decades could be a good starting point: there's a big chance that many people are already used to such behaviors.
Alexandre Prokoudine wrote
And that's also another perspective on defining your audience: do you expect them to go back and polish their work, or do you expect them to mostly do quick edits of arbitrary file formats?
I don't think this point is relevant. Everybody is free to use the software as they wish and as they can. We should focus on what the software can and cannot do: people will behave in response to this.
Alexandre Prokoudine wrote
IMHO, having Inkscape saving only in Inkscape's SVG format and exporting in everything else, hence putting PDFs and PNGs at the same level, would be a wrong decision.
It also depends on how you define Inkscape. Is it a generic vector graphics editor where file formats are treated equally? Or is it more of an SVG editor, with *some* support for other file formats?
This is the central point to speak about. My opinion is that Inkscape doesn't have only *some* support for other file formats. Or if it has, it's a limitation due to the development still in progress that will eventually be overcome. I won't say that Inkscape is only 'an SVG editor'. Even if it started like this, personally I don't use it as such: I use it as a good vector graphics editor, still with some bugs but a lot of workarounds too and an active community working to fix them and continuously adding new features. Surely the SVG format will always play a central role as it's the only one that will guarantee that all the features are going to be saved correctly and its structure partly dictates what Inkscape can and cannot do. But there are also extensions to the format so I won't say it's the only one that Inkscape can manage. Also, not everything can be saved in 'plain SVG' so you may say that there's no real vector graphics editor around as every one has its own "full-features" only format. There should be a survey on how many users do effectively use Inkscape for its SVG output only and how many just consider SVG as Inksape's internal format, then regularly produce their work on a different one.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Save-and-User-Manual-tp4973054p4973151.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Wed, Mar 11, 2015 at 8:48 PM, LucaDC wrote:
There should be a survey on how many users do effectively use Inkscape for its SVG output only and how many just consider SVG as Inksape's internal format, then regularly produce their work on a different one.
The problem with online surveys is that you might never be sure whether your sampling is right. So while I'm not against surveys (who am I to tell you, anyway?), I think it should be very carefully planned and seeded.
Alex
On 11 March 2015 at 11:20, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
In my experience listening to feedback from GIMP users after the v2.8 release, people who complained the least were people who GIMP has been targeting in the first place: people who work on challenging tasks and, by nature of their work, need to save XCF files (to retain layers etc.) to go back and edit them later. People who complained the most were people who either used GIMP for quick editing (for which GIMP is like a hammer to a bolt in the absense of a screwdriver) or were so sure they would never make a mistake that they would rather blindly click OK in the "Not safe to save to this lossy file format" and then close without saving to XCF.
I believe you are right. But Gimp risks a fork if it isn't interested in targeting edit workflows. This is up to the developers and designers of course. But there isn't anything on the Linux desktop that can do cropping and colour tasks. So we have to use gimp and we have to fork it in order to turn it into an edit tool instead of an art tool.
Of course if you ask gimp developers, they'll tell you gimp is great for cropping and colour tweaking tasks... Except it isn't because they've focused on designing for a different workflow. As you've identified.
It would be nice if they had said "don't use gimp for this, use X". But instead the argument (which is poor community communication) was to "get used to it". Utterly failing to differentiate their users and their workflows.
But I think you know all this.
Martin,
On Wed, Mar 11, 2015 at 9:32 PM, Martin Owens wrote:
I believe you are right. But Gimp risks a fork if it isn't interested in targeting edit workflows.
GIMP has been forked probably half a dozen of times, as far as _I_ can recall (that is, not all the way to its inception). So far none of those forks survived.
This is up to the developers and designers of course. But there isn't anything on the Linux desktop that can do cropping and colour tasks.
While Krita focuses on digital painting, it has working cropping and basic color grading tools. They have the basics covered. You are most welcome to use it.
It would be nice if they had said "don't use gimp for this, use X". But instead the argument (which is poor community communication) was to "get used to it". Utterly failing to differentiate their users and their workflows.
I'm not sure, where you were when this change was communicated to users, but you were clearly absent. Because we told people on many, many occasions that they a) have a choice other than GIMP, b) can install Akkana's plugin, c) can use existing forks that specifically bring back the old behavior.
Ignorantia non est argumentum, Martin :)
That said, I'm quite interested how you are going to deal with this in Inkscape.
Alex
2015-03-11 19:32 GMT+01:00 Martin Owens <doctormo@...400...>:
Of course if you ask gimp developers, they'll tell you gimp is great for cropping and colour tweaking tasks... Except it isn't because they've focused on designing for a different workflow. As you've identified.
There is a separate item in the menu called "Overwrite foo.png" which covers edit tasks.
Regards, Krzysztof
El sáb, 07-03-2015 a las 00:09 -0500, Martin Owens escribió:
On Sat, 2015-03-07 at 01:54 -0300, Gez wrote:
Not everyone liked this change, but after some time things seem to have settled and people got used to it.
Not really. I'm still aggrieved by it every time I open gimp and I
tend
to avoid using gimp because of it. It just makes editing workflows costly because xcf is a useless format outside of gimp and it's a nonsense to save an xcf to edit a png or jpeg you've just colour corrected.
I think that's just a case of muscle memory, and the fact that you're avoiding GIMP is a good explanation of why you never got used to the change. I use GIMP everyday for my work, and although I have to admit that for a couple of days it bugged me a lot that every time I tried to "save" my work I got only "save to XCF", the CTRL+E shortcut became more natural after a while. What I did to facilitate the transition was to assign a keystroke to the overwrite command, which is something you want to use if your typical workflow consists on doing minor tweaks on lossy formats. Y used CTRL+ALT+SHIFT+E for overwrite, and it became part of my regular workflow. Now I suffer a bit everytime I use a GIMP without that macro. Give it a serious chance, it's just matter of getting used to it.
At least svg is a web format which can be said to be useful and editable. So we'll have fewer issues if we did that. We don't have a
editing workflow for example, just PDF-page importing & creation as separate jobs.
I agree. SVG is a better case for that separation, since SVG is both the native format of Inkscape and likely the most frequent output format for project files.
Rather than go all Gnome on the design, we should test different workflows for something so important. Know what we're giving up if anything.
I'm not sure what you mean with "all Gnome", but yes. This is a really important issue and it has to be studied carefully. The current implementation is not good enough since it's error prone and somewhat confusing. Something has to be done but all the pros and cons of the proposals have to be considered. Maybe a good start is to gathering some good real-life use cases, checking what different users need, but I'm pretty sure that most of the users choose inkscape SVG as their usual "project" file format.
Gez
On 7-3-2015 6:09, Martin Owens wrote:
We don't have a PDF editing workflow for example, just PDF-page importing & creation as separate jobs.
There is a PDF editing workflow: Inkscape opens a PDF, you edit a bit, you save and close. It's been a while since I've used that though. Don't know if perhaps only a few people use it.
-Johan
Johan Engelen <jbc.engelen@...2592...> writes:
On 7-3-2015 6:09, Martin Owens wrote:
We don't have a PDF editing workflow for example, just PDF-page importing & creation as separate jobs.
There is a PDF editing workflow: Inkscape opens a PDF, you edit a bit, you save and close. It's been a while since I've used that though. Don't know if perhaps only a few people use it.
I use it sometimes as well. It usually works pretty well.
-Johan
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2015-04-15 22:45 (+0200), joakim@...1974... wrote:
Johan Engelen <...> writes:
On 7-3-2015 6:09, Martin Owens wrote:
We don't have a PDF editing workflow for example, just PDF-page importing & creation as separate jobs.
There is a PDF editing workflow: Inkscape opens a PDF, you edit a bit, you save and close. It's been a while since I've used that though. Don't know if perhaps only a few people use it.
I use it sometimes as well. It usually works pretty well.
Based on my experience in user support and bug triage, I never recommend such a workflow with Inkscape, mainly for two reasons:
1) High risk of destroying data: If this workflow is applied to a multi-page PDF file, Inkscape will happily overwrite the original PDF file with the single page just edited. All other pages in the original PDF file are lost (and can't be restored, unless the user kept a backup copy of the original PDF file).
2) Round-trip editing file formats like PDF repeatedly in Inkscape can quickly result in corruption or changed appearance which is hard (or impossible) to fix (often involving displaced gradients, masks, or pattern fills originating from the first PDF -> SVG conversion) - likely small incompatibilities between PDF support in poppler and cairo contribute to this, apart from the obvious differences between the supported feature set of the two file formats (PDF, SVG), and bugs in Inkscape's own conversion routines, as well as in poppler and/or cairo.
Inkscape cannot edit the PDF content directly, and we should not pretend it does (or ever will).
My recommendation to users: 1) open/import the PDF file 2) edit as needed 3) save as Inkscape SVG 4) export (save a copy) as PDF when needed 5) always edit the Inkscape SVG, never the exported PDF file
The cited workflow might be "ok" for one specific use case: one-time editing of a single-page PDF file (with varying results).
Regards, V
El jue, 16-04-2015 a las 00:23 +0200, su_v escribió:
On 2015-04-15 22:45 (+0200), joakim@...1974... wrote:
Inkscape cannot edit the PDF content directly, and we should not pretend it does (or ever will).
My recommendation to users:
- open/import the PDF file
- edit as needed
- save as Inkscape SVG
- export (save a copy) as PDF when needed
- always edit the Inkscape SVG, never the exported PDF file
The cited workflow might be "ok" for one specific use case: one-time editing of a single-page PDF file (with varying results).
I agree.
What I'm going to add is implicitly present in V's comment, but it also makes a case against one-time editing of a single page PDF: Even though the appearance of a PDF imported in inkscape file may look right, some important information could be discarded. That's specially relevant in press-ready PDFs. CMYK PDFs will be converted to CMYK, "special" PDF versions like PDF/X-3 are going to lose all the features that make them "press-ready" like reference icc profiles, overprints, spots colors, etc. This also applies to Adobe Illustrator files that are based on PDF. Those files are widely used for distributing corporate logos and designs, and it's not rare to find features that are not supported by inkscape, like blending modes (applied for instance to make shadows transparent, by blending a black to white gradient with multiply over color).
Being able to overwrite a PDF you just open is more likely to case troubles than not. And that's another case for separating export and save, but I'll leave it for now :-D
Gez.
On Thu, 2015-04-16 at 09:11 -0300, Gez wrote:
Being able to overwrite a PDF you just open is more likely to case troubles than not. And that's another case for separating export and save, but I'll leave it for now :-D
In this case, I agree. PDF isn't a format we edit, it's something we import. Maybe something like an `Import New...` menu item would help with the separation there.
Martin,
El jue, 16-04-2015 a las 09:29 -0400, Martin Owens escribió:
On Thu, 2015-04-16 at 09:11 -0300, Gez wrote:
Being able to overwrite a PDF you just open is more likely to case troubles than not. And that's another case for separating export and save, but I'll leave it for now :-D
In this case, I agree. PDF isn't a format we edit, it's something we import. Maybe something like an `Import New...` menu item would help with the separation there.
Why are you so against separating saving and export but you don't have problems about making a distinction between open and import? They are opposite ends of the same issue.
Inkscape already has an import command, but it inserts the contents of external files into an existing document. Adding an "import new" is probably confusing, "import as a new document" is probably better but a bit long. And in any case, it would be partially replacing the function that the open command already has, and adding an extra command to the file menu. That's exactly what people complain about regarding GIMP's save/export separation: "that destroys my workflow, I always use the x command to do y, why was it changed?"
The thing is that there are real and compelling reasons for having a proper distinction between the procedures of opening and importing, and the same reasons apply to saving and exporting. The program should make clear when it's doing one or the other. Failing to do that causes data loss and endless headaches.
Combining open/import and save/export has worked for some time, makes menus more compact and people got used to that combined function, but it also creates problems that have to be addressed. Maybe there's a way to fix that without separating those commands, but nobody seems to have found it without cluttering menus or adding several options to dialogs. All the existing attempts to fix it cause some annoyances, usually modified or slower workflows. People will complain. But preserving editability of project files and avoiding data corruption on existing assets should be sine quibus non.
Gez
Sona si Latine loqueris.
Combining open/import and save/export has worked for some time, makes menus more compact and people got used to that combined function, but it also creates problems that have to be addressed.
Most design does. The previous email wasn't a design blueprint, it was a suggestion.
People will complain. But preserving editability of project files and avoiding data corruption on existing assets should be sine quibus non.
Gimp's lack of save function for single layer pixmaps is a hamfisted restriction, applying the fear of loosing data to situations where there is no data to loose. It's not well designed.
Inkscape can only edit svg files. The data loss just /importing/ a pdf is sufficient to design caution. Saving them just adds weight. The closest comparison to gimp is if Inkscape said saving as plain svg was an export, and only inkscape svg would be allowed in the save as.
These are not the same programs and one can't simplify those designs into the same strict pattern. And I admit going on about gimp's export design was a poor choice in venue, so I'm sorry for bunging up inkscape's devel list with it because all we have to do here is learn to be considerate to all our users when we design things.
Martin,
7 марта 2015 г. 8:56 пользователь "Gez" <listas@...3059...> написал:
GIMP devs understood that and implemented save/export as separate functions. Not everyone liked this change, but after some time things seem to have settled and people got used to it.
Not quite so.
There are people who praised the change.
There are people who hated it, then got used and loved it.
There are people who keep hating it.
And there are people who are rather indifferent and couldn't care less.
Should Inkscape introduce the hardcoded (non-configurable) save/export separation, you can realistically expect the aforementioned variety of opinions. There will also be raving maniacs and stampeding crowds.
Also, don't get me started on all sorts of amusing conspiracy theories I've heard since 2012 :)
Alex
On 10-Mar-2015 20:47, Alexandre Prokoudine wrote:
There are people who keep hating it.
Bingo.
Another way to achieve this, without the extra "export" menu option, is to put an option in the open/save dialog that is "native only" (or something to that effect). That does pretty much the same thing as "export" does, and is, I think a more logical way of going about it. In both instances the user's intent is to open or save a file, and the option further clarifies the format(s) that are to be considered / used. Inkscape almost has this now, in that it has a "file type" field which has "All inkscape files" etc., and it has "Inkscape SVG *.svg", but it doesn't have "Inkscape SVG (native format) *.svg". That is, the end user has to know that SVG is the native format, it isn't spelled out anywhere. We all know that, however, I suspect many of the end users don't think of SVG that way. Many of them probably think of Inkscape as a drawing program and do not concern themselves much with the file formats.
My other problem in this arena concerns "open". By symmetry if other formats must go out through "export" then they should come in through "import", rather than "open". However "import" is not a common option, and when it does appear, it often means "open this file into the current drawing/document" and not "open this other _type_ of file". The former is the current meaning in Inkscape.
Rather than fighting about this endlessly, it would probably be best to provide a user configurable switch that sets things up however the end user wants, so that everybody can be happy the UI on their machine, and they don't have to live with somebody else's view of how it should be. Something along the lines of:
INKSCAPE_SAVE_MODE: promiscuous: save works on all file types with no "special" status other than that the first time default is inkscape svg. It always opens to the last save file type. This is what we have now. conservative: save always opens with "Inkscape SVG (native format) *.svg" selected, but other file formats can still be selected. segregated: save is Inkscape SVG only (plus any other completely lossless formats, of which I think there are probably none), export is used for all other (lossy) formats.
I'm not wedded to those terms, they are just suggestions.
It would be good if that switch was also configurable from within the save/export dialogs, because many of the end users would really prefer one or the other of these, but they may not be sophisticated enough to find and modify the configuration file.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
El mié, 11-03-2015 a las 06:47 +0300, Alexandre Prokoudine escribió:
7 марта 2015 г. 8:56 пользователь "Gez" <listas@...3059...> написал:
GIMP devs understood that and implemented save/export as separate functions. Not everyone liked this change, but after some time
things
seem to have settled and people got used to it.
Not quite so.
There are people who praised the change.
There are people who hated it, then got used and loved it.
There are people who keep hating it.
And there are people who are rather indifferent and couldn't care less.
Sure. I didn't mean that now anyone loves it. It's just like you said, but after a while the heat about the change sort of went down. People who praised the change are still happy. People who hated it, then got used to it and started to see the benefits (my case) are happy too.
People who keep hating it probably can be separated in different groups too: - Some of them got used to it, still don't like it but use GIMP anyway (so probably it's not accurate to say they "hate it", they just would prefer it to be the old way). - Some of them who never use XCF probably changed the keystrokes to map export and export-as to CTRL+S and CTRL+SHIFT+S and sort of got used to it, although overwriting is not immediately available. - Some of them used Akkana's plugin. - Some of them stopped using GIMP because of that.
To be honest, I haven't heard many people saying they stopped using GIMP because of that change. Some of the people who switched to krita, for instance, changed for other, more compelling reasons.
I'm not generalizing, but most of the people saying that they can't work with GIMP after that change are people who don't use GIMP regularly anyway and they are not the target user defined in gui.gimp.org
Should Inkscape introduce the hardcoded (non-configurable) save/export separation, you can realistically expect the aforementioned variety of opinions. There will also be raving maniacs and stampeding crowds.
It all boils down to defining an audience or not. Choosing one and making (probably hard) decisions to allow good practices won't be as popular as plaguing the UI with choices to allow every possible workflow out there. You can't make the high end professionals and total beginners happy with the same UI (or even the same program). Everyone who tried that failed, no matter what trendy mobile apps makers want us to belive :-)
Also, don't get me started on all sorts of amusing conspiracy theories I've heard since 2012 :)
Sounds like a good subject for an fun OT-thread :-)
Gez.
participants (11)
-
unknown＠example.com -
Alexandre Prokoudine -
Gez -
Johan Engelen -
Krzysztof Kosiński -
LucaDC -
Mark Schafer -
Martin Owens -
mathog -
Roger Sharp -
su_v