As you may know (or now know ), the next major Inkscape version is planned to be the magical 1.0.

It will probably go through a longer beta (testing) phase, before it will be published. The Inkscape 0.92.x series will presumably be continued, and receive bug fixes, for still quite some time, even after 1.0 has been released. This is because 1.0 will introduce some major changes that might cause new issues that need to be solved.
Inkscape developers will be working towards this goal during the next hackfest (which is going to be in Kiel in September).

Aside from CMYK support (which is a much too comprehensive task to be done in the foreseeable future), what is the one thing you would you like to see fixed or added in Inkscape 1.0?

For the love of all that is still good in this world...

PLEASE

Release the default.svg with px as units, and scale of 1.

That one thing will fix so many broken bits for so many users.

That's all. Thanks for asking!

@tylerdurden Thank you for your answer! I will collect these, and will make sure they reach devs. No promises!

I'm going to pick two things, because the first is wishful thinking that is actually far too much effort for the next release.

1) A new filter editor, with a more graphical approach to laying out the filter chains. Each filter primitive would be a node in the layout, with a popup for its parameters. Connectors would be drawn between nodes to create the filter chains. Most importantly it should be possible to feed in some test imagery (a circle, square, star, bitmap image) and optionally see a preview at each individual node of the filter. That would make creating and tweaking complex filters so much easier.

2) Better support for installing additional "things" that Inkscape can use. E.g. I'd like to be able to drag-and-drop a *.gpl file on Inkscape and have it automatically put the palette file into the right directory and make it available immediately. Similarly for extensions (probably as a single zip file). Dropping an SVG file, perhaps onto a specific dialog or whilst holding a modifier key, should give me the option to save the file as a template, to extract any filters/symbols/patterns in it and save them to disk. So on for any other file types it can use as a resource (even fonts, maybe?). An integrated browser for extensions and other "things" would be a boon, too, but raises questions about where it should source them from.

Basically the idea is to avoid all of those support posts which have to explain to users where to find their Inkscape directory. Inkscape already knows where it is, so those support requests should just become something like "drop this zip file on the Inkscape window to install the extension".

I beleive the answer for the question will heavilly depend on what each user do with Inkscape.

I mostly use Inkscape for drawing schematics, and I always use layers.

Top two most annoying bugs
1 : Sometimes object disappears when moving through multiple layers and one layer in the middle has visibility turned off.
https://bugs.launchpad.net/inkscape/+bug/168636

2 : Program crashes (windows only) when Shift+Click on rectangle corner radius node.
https://bugs.launchpad.net/inkscape/+bug/1594877

Just ONE?
When it took 15 years getting to 1.0?

Aside from CMYK support???

OK, let's see the rest of the burdens.

• Customizable coordinate system. At least a way to produce backward compatible svg-s that match with the svg specs.
• An interface which works. And it's not just the design flaw of the cartoony icons or the white theme. The current document settings panel cannot be set on a small screen.
  Screen resolution independent, responsive design. That's what svg is taking places in, why the inkscape interface is stiff as a brick?
  Something of blender's alike would be fine. Every part is dockable, window layouts can be saved, icons, text field can be zoomed in, multiple viewports can be generated of the same document...
• A decent, reliable renderer. Not something where objects fade or flicker, parts missing from a png export, text cut off, parts blackened out, not what melts right away before exporting a filtered image. That is
• PERFORMANCE. The lack of performance of inkscape is unacceptable. Maybe that's just I'm still using 0.92.2 and win, BUT an interpolation between two simple paths shouldn't take 10 seconds to pull off. Or more to open the lpe panel. OR even more opening the document browser.
• multiple page support
• Higher zoom range. Affinity designer does it already, with a cad program's precision.
• Drawing in scale. So that we can draw maps with km or mile as a base unit. Or photolithography.
• web support, web animation support -currently there is no way to render external data from a file except using symbols.
  No way to draw over an existing webpage for example.
  And no way to render animations.
• Texts, fonts. They need to be fluent. No more missing font files, preferably a built in font manager and no font caching misery.
  TEXT OBJECTS that won't hang inkscape and which can be dragged around the same way as simple paths.
• Spot colour support. Oh wait... ....svg fonts, when?
• More renderer options. Introducing dithering to gradients. "Additive alpha cut" rendering option to groups, overcoming 90% of the anti-aliasing issues.

That's ten off the top of my head.

@Grobe Thank you! The click+crash thing sounds like it shouldn't be too difficult. For the layer thing, it would need Inkscape to treat layers even more differently from groups than it does now. I don't know how hard that is, but I agree it shouldn't be like that - the effect is on the layer, not on the single object inside. It's different for normal groups...

@Lazur: Yes, just 1, this is overwhelming (Just FYI: I have two of the major performance issues already on my list; the document settings dialog has already shrunk; theming is currently under way; making the whole interface customizable will still take some time; the renderer won't change, but it can be fixed; multi-page support has been moved to a volunteer project and out of the roadmap; for the zoom range, please provide more details; you can already use km or mile as a unit, but it's not widely known that units are customizable in Inkscape; rendering animations is out of scope; rendering external data is supported for static images (or what did you mean?); the coordinate flip is scheduled for 1.2 currently, but someone had already started to work on it - however, it's more difficult than they anticipated, and I'm not sure they are still working on it - could use some encouragement and testing from passionate users; font dialogs are continuously being improved; for the others, I can't say much, sorry)

@Xav: thank you, those are good ideas - I think Lazur may know more about the status of the filter editor. He has been involved in talking about UI for it, but I don't know the details. Making it easier to install new stuff is a great idea - I don't know how hard it is, though. Especially for extensions, that are non-uniform. Having a dialog for 'Add a new addon to Inkscape' perhaps, then asking the user to select a file and what kind of thing it is, then putting it into the correct folder, would probably already be progress...

Well, then the performance. Speeding up the underlying algorithms.

-Currently trying to edit an autotraced image with 80000+ nodes. Can delete a few nodes fine with the node tool, then deselecting the object hangs inkscape for minutes is no way to go.Had emergency quit a dozen times working on this image.-

On the filter editor, raised voice for adding a node based editor and pointed out features largely missed yet the official direction was made up already after the hackfest, claiming it'd be best if it was shrunk into a dropdown list...
will have to revive my filtering project sometime and get that cookbook finished and simultaneously make a gui suggestion.
So far there hasn't been serious interest in that panel as far as I could see, not that I'd seen a general interest in filtered svg-s anyway.
And honestly with the available rendering capabilities I wouldn't suggest using too much filtering either.

Native, true, CMYK and spot color support, (and the ability to export it with the color profile in an industry standard, (pdf.)) Fixing many PDF issues probably goes along with this.

Lazur wrote:On the filter editor... the official direction was made up already after the hackfest, claiming it'd be best if it was shrunk into a dropdown list...

Argh! I certainly hope it doesn't go down that route. At least not exclusively. I don't mind a dropdown list, so long as it's still possible to get to a full editor.

Lazur wrote:So far there hasn't been serious interest in that panel as far as I could see, not that I'd seen a general interest in filtered svg-s anyway.
And honestly with the available rendering capabilities I wouldn't suggest using too much filtering either.

Unfortunately it all plays back into itself: a poor UI and slow rendering mean that people quickly get frustrated when they start trying to create their own filters. If the results were more immediate, the UI was more intuitive (i.e. node-based) and it was possible to see a preview of the output from each node independently, I suspect more people would play around with it. Of course there's only so much that can be done about performance - but that's one place where a separate editor dialog with some standard source objects would help: it's a lot faster to render a filter on a single star with a background colour than to do the same on a complex drawing with multiple layers and opacities going on.

If we just have one choice, then I'm with TD.

tylerdurden wrote:For the love of all that is still good in this world...

PLEASE

Release the default.svg with px as units, and scale of 1.

That one thing will fix so many broken bits for so many users.

That's all. Thanks for asking!

Please make px the native units, as it was before. Despite some claims that most people use mm anyway, so why not (which seems to be the only reasoning for it, as far as I've been able to learn) it seems to cause more problems than it solves, in my opinion. There's been no survey, or any way to know which units are used the most.

To me, it makes more sense to make px the native units, because it's much more flexible. And then provide a custom doc for those who want mm or other units.

Aside from that, the only thing that particularly bothers me as a user, is not being able to expand the docked Layers dialog, unless it is the only dialog that's open. https://bugs.launchpad.net/inkscape/+bug/1001739

The reason that simply scrolling inside Layers dialog won't work, is because it only shows 3 layers. The scrollbar barely fits in that small space. The bit that you drag is tiny, and the available space is small. It's hard to find the layer you want to access. So it's easier to have the dialog expanded.

The fix would either be making it longer, or allow it to expand.

If I had a 3rd choice, I'd say native multiple pages support. I know there is at least one extension for this, but it results in PDFs, not SVGs, as far as I understand. https://bugs.launchpad.net/inkscape/+bug/170369 I don't have the technical knowledge to speculate on how to do it.

____________________________

If it can be explained in a very general and not too technical way, why is CMYK support so difficult to implement?

@phiscribe and @brynn CMYK pdf export with preflight checking is a huge project. In the background, Bryce (the head of the Inkscape board of directors) is working hard on putting together a viable way to implement it. The draft is several printer pages long... and it's far from finished. He is incorporating lots of feedback from the various experts. I think he plans to make this the first 'real' funded project, to be executed with the help of the Vectors team, with many subtasks, so it can be divided between many developers. I'll try to remember to let you know as soon as a first public version is available.

@Lazur I think I've got good news for you: node deselection 'speed' has been addressed already, see http://wiki.inkscape.org/wiki/index.php ... tes/0.92.4 - you could test with a development version of the 0.92.x branch. Let me know if you need help with finding the right file (and also let me know which OS, and if it's 32 or 64bit).

@brynn In master, the layers dialog seems to expand automatically, at least, after first usage, it gets larger (11 layers visible). Yet, the dock has some new quirks now... Like: minimizing making it necessary to do two clicks to un-minimize, first from a too large button with vertical text on it to one with horizontal text, and then to the dialog. But: dialogs actually open (on the second click, when they have been minimized... I think minimizing can be put to rest, instead have the whole dock slide in or out...) when you select them from the menu!!! (Tried this for the first time today, it's a huge improvement ).

As I've already used up my slot (twice), I'm posting this one... erm... on behalf of a friend. Honest. Mind you, unlike some other requests it should actually be a fairly simple one to implement:

He would like to see multi-line textboxes that flex to fill the available space in a dialog.

Consider the Document Properties dialog (which I'm sure I used to be able to resize, but don't seem to be able to any more). The "Scripting" tab has an "Embedded Scripts" tab within it, complete with a "Content" field for you to enter or edit some JavaScript in. But that field is limited in height, so you can only see a tiny amount of your code at a time. Nobody wants to write JavaScript through a letterbox.

The Metadata tab has a "Description" field that is fixed in height. That's probably fine in most cases, but I... err I mean, my friend... uses it to hold a transcript of his comic strips, which can run to a dozen lines or more. Currently he types the transcript up in a text editor then copies and pastes it into the field.

Finally, in the Object Properties dialog, there's an expandable section for "Interactivity" (i.e. more JavaScript). This contains several single line fields, but would probably be better implemented as several tabs, each with a multi-line field in, for similar reasons to the Scripting tab in Document Properties.

There may be other areas with similarly constrained fields, where something larger or more flexible would be good, but these are the ones that have most directly affected my friend.

Hello, long time I don't log here
Moini, thank You for asking:
I had many ideas in my mind. But I'll try to brief in 2 big ones:
1.- What about a new or improved system from the current MACRO/Scripting/ Extension system?. I'd wish to point to the one used in Excel tables, where You record or catch Your actions or commands in a script that then You can modify adding "IF ELSE", or "REPEAT" orders. I think It could help to many of Us in different tasks, like preparing our files to exporting in other formats, changing the styles or attributes of many elements, etc.
2.- What about a new improved Vector Graphics file format? One open, easily to read and improve, which takes the best of SVG, or PDF; EPS, AI, etc formats?

And many other ideas:
- A stroke tool
- Keep or convert the style attributes in different, separated attributes
- Improve the find and replace command, using expressions or similar
- Improve the Path effects dialogues
- Improve the filter dialogues
- Use CDATA blocks for scripting, to keep "<", ">" and similar
- Yes, I agree, better handling of selection and de selection, rendering, etc.

And maybe I'm leaving many others. Hope You don't mind I could come with more... or no

hulf2012 wrote:What about a new improved Vector Graphics file format?

I also think that a new and open format would be the best but it won't happen with the inkscape project.
Which was, built upon the svg specs and intended to be the closest to it -abandoning sodipodi. So it's quite surprising to have gradient meshes...

Lazur wrote:So it's quite surprising to have gradient meshes...

Not so surprising really, given the way that W3C specs work. Before a spec becomes a recommendation (the closest they ever get to being a "standard"), there must be two independent implementations of it. There's also a rather annoying rule that one of those implementations must be a web browser - though they seem to have relaxed that to also allow polyfills for some specs.

The result is that nothing new will be added to SVG unless someone's prepared to actually put it in their software first - and hope that another project (which might have to be a browser) also does the same. As Tavmjong Bah is on the SVG working group, and was the main proponent of gradient meshes, it made sense for him to produce an implementation in Inkscape.

Now it could have been left in development builds only, but in order to get a browser vendor interested in implementing it you need to show some real-world adoption (catch 22 situation there, I know). So it went into release builds and he also created a polyfill so that mesh gradients can be used online. But still no browser has implemented them, and until that happens it can't be in the SVG spec, or it would prevent the entire spec (or at least that module) reaching REC status.

The best thing that users can do is to create content using mesh gradients and put it online using the polyfill. With enough of that, the browser vendors might see the need to implement the feature. Unfortunately this requires more technical ability than just uploading a file to a social media site.


FWIW I see the use of SVG as both a blessing and a curse. I love the idea that there's a fairly powerful, cross platform, cross browser STANDARD format that's free and open for anyone to implement. But there's no doubt that it holds Inkscape back in terms of what the developers can implement. In the grand scheme of things though, I think I'd prefer to have a good editor for an open format, than a great editor for a proprietary one. If you want the latter there are already plenty of commercial programs that can fulfil that need.

@Xav : Your friend's wishes about larger, vertically scrollable text fields seem very modest. I think that would be something that maybe even a beginner could implement. (You don't accidentally know how to program? I think you're a javascript person, but not sure. Or you could ask your friend ) Seriously, those are good, small improvements that make a lot of sense.

@hulf2012 Hey, good to see you again Thank you for sharing your suggestions. Unfortunately, I don't think those have a large chance to be made reality. We are going to have 2 heavily involved extension writers and 1 Inkscape extension developer at the hackfest (at least they registered). Chances are that extensions might be getting access to more internal Inkscape functionality as a result. I do not expect we will ever see programming work be replaced by point-and-click, though. As for the file format, I think Xav has given a good overview of the general mindset of the Inkscape devs. Although there actually are some people among the devs who would like to extend the SVG file format a bit more.

I'm sticking with my simple, single issue... that alone will resolve a multitude of confirmed bugs.

Symbols Bug #1670913
DXF (fixed downstream) Bug #1660967
Browser scale Bug #1670913
Inset/Outset Bug #1673924
Font/glyph creation Bug #1670913
Stroke width scaling Bug #1742659
Copy/paste clones Bug #1679428
Transform attribute Bug #1716197

It doesn't get more simple than using the default.svg units that were used for years. It doesn't require any code change to the program at all. Besides, px are the basis for all the code and the lingua franca for all the other units.

My runner-up...? Probably This. (first discussed here: viewtopic.php?f=5&t=33071). This may require a bit more work than the above, but it does make Inkscape look fundamentally broken to new users.

Xav wrote:I'd prefer to have a good editor for an open format, than a great editor for a proprietary one

Where is Maestral when we need him?




But seriously. Would it be that hard pairing up an open vector drawing project with an open browser? Then the standard could come straight from the gnuheads.

Lol, cool idea, Lazur How about talking with Tav about that? He's going to be able to give you a better impression of the interests and different backgrounds involved in the SVG working group (what I think is that they are probably already working together as well as they can, given their enterprise philosophies, money, etc. ).

TD, it's not going to really fix the issues, they'd still be present in the other templates The bugs need proper fixes, too, not /only/ a strong mitigation.

Getting quite off topic.

Moini wrote:@Xav : Your friend's wishes about larger, vertically scrollable text fields seem very modest. I think that would be something that maybe even a beginner could implement. (You don't accidentally know how to program? I think you're a javascript person, but not sure. Or you could ask your friend ) Seriously, those are good, small improvements that make a lot of sense.

Yeah, mostly JS these days, but I've dabbled with a few other languages over the years.

I've thought about getting the Inkscape code and trying to fix those fields more than once. But I write code all day at work, so it's the last thing I want to do in my spare time. That's why I "contribute" by writing tutorials - it still flexes my technical muscles, but doesn't feel so much like my day job.

Lazur wrote:But seriously. Would it be that hard pairing up an open vector drawing project with an open browser? Then the standard could come straight from the gnuheads.

If only that were the case. Firefox should be the standard bearer for FOSS, but that doesn't seem to help much when it comes to specs. Perhaps support for new features could be added to a smaller FOSS browser engine to get them past the "two implementations" requirement - but history has shown that, unless a feature is widely adopted across browsers, it will still get dropped from the specs. Witness SVG fonts, and the ongoing deprecation of SMIL, for example, even though both had pretty good adoption. In both cases a single holdout (Firefox for one, MS for the other) was enough to effectively kill the standard.

What I'd like to see is the SVG spec split into two "profiles". There would be a "web profile" and a "non-web profile". Work would be undertaken in the non-web profile first, and require two implementations but not necessarily a browser. That would allow (for example) Inkscape to get new features so long as Adobe also add them to Illustrator, or they're also added to Scribus. If a browser also chooses to implement the feature, it would be promoted to the web profile. That would allow for work on features that will never be needed in a browser (CMYK), but also for things that would be useful in general and if we could use them on the web then that would be even better (Mesh gradients). It would also allow Inkscape to clearly flag when you're using a non-web feature, so you don't end up surprised when your image doesn't display on browsers properly.

Moini, seems you were already in the air, and flew right over my head, with "preflight checking" in relation to CMYK. Does that refer alpha or beta testing, before it's available in a stable release? Or is that something about previewing colors when it's working? Will the several pages long draft be public at some point?

Preflight checking is checking if all features in the (SVG) file you have (e.g. transparency, objects outside the page border, colors outside of the color space) are exportable to the selected pdf format, or if there are any changes required, if you want the exported pdf to look the same as the SVG.

Yes, as I wrote, as soon as it's published, I'll notify here - I think Bryce will probably post a link to it to the devel mailing list as soon as it's ready.

Oh sorry. I though you meant you were going to notify when the feature is released.

Thanks for the info!