Seems SVG is more and more invisible to the big companies. Here's sad tale of Amelia Bellamy-Royds's experiences with SVG and its seeming demise. (http://codepen.io/AmeliaBR/post/me-and-svg)
I wonder how the Inkscape devs (et al.) feel about this. Could Inkscape not take a new route, perhaps bake-in some new features*, now that the SVG standards seem to be moot?
* Multiple pages in one file — and export to multi-page PDFs. A real symbol system — within and *between *documents. Custom colours that don't rely on that fake gradient trick (And make them work between documents too!) Animation time lines. Output to gif, video and so forth. Perhaps to HTML5 Canvas with some js framework too. Scripting, Blender-style, right there in the app. In Python and JS perhaps. Opening of Gimp native files (xcf) into layers, perhaps. Use of 3D objects and materials, from Blender (say) directly in the canvas — some kind of OLE layer thing.
I am sure there are many more.
I think Inkscape could have, by now, matched what Flash, Freehand and Corel et al. had 20 years ago! It did not go there because it, honourably, stuck to the SVG standards.
Inkscape is the best thing we have for graphic design on Linux (at least), but it's still way too primitive. Could we dare to think bigger? Start our own standard?
Just wondering. Is this a disaster or an opportunity?
/d
I'd be fine with Inkscape for graphic design use if it would just write out a CMYK PDF w/o jumping through hoops.
On Fri, Apr 21, 2017 at 10:06 AM, Donn Ingle <donn.ingle@...155...> wrote:
Seems SVG is more and more invisible to the big companies. Here's sad tale of Amelia Bellamy-Royds's experiences with SVG and its seeming demise. (http://codepen.io/AmeliaBR/post/me-and-svg)
I wonder how the Inkscape devs (et al.) feel about this. Could Inkscape not take a new route, perhaps bake-in some new features*, now that the SVG standards seem to be moot?
Multiple pages in one file — and export to multi-page PDFs. A real symbol system — within and *between *documents. Custom colours that don't rely on that fake gradient trick (And make them work between documents too!) Animation time lines. Output to gif, video and so forth. Perhaps to HTML5 Canvas with some js framework too. Scripting, Blender-style, right there in the app. In Python and JS perhaps. Opening of Gimp native files (xcf) into layers, perhaps. Use of 3D objects and materials, from Blender (say) directly in the canvas — some kind of OLE layer thing.
I am sure there are many more.
I think Inkscape could have, by now, matched what Flash, Freehand and Corel et al. had 20 years ago! It did not go there because it, honourably, stuck to the SVG standards.
Inkscape is the best thing we have for graphic design on Linux (at least), but it's still way too primitive. Could we dare to think bigger? Start our own standard?
Just wondering. Is this a disaster or an opportunity?
/d
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
This is more of an inkscape-devel discussion. But I'll add some thoughts here.
When SVG 1.1 was years and years old and no one except maybe Opera was doing anything with it at all, the Inkscape project added features, some from SVG 1.2 (flowing text etc), some from hacks (like the gradient stops) and some we just made whole cloth from our own xml namespace.
The problem comes when the SVG 2.0 specification really got going. We were left holding features which we'd probably have to keep being able to open, but other browsers and editors wouldn't ever be able to.
That's the core of the problem with doing things yourself.
What we lack here is a huge amount of developer time. We could do with having a whole brigade of selfless expert developers who follow instructions and produce amazing work. We'd also like it for free. This really is not realistic. We have instead is a small but amazing team of fairly even handed developers who follow their own passion projects and do it for sometimes free and sometimes outside contracts in a complex real world sort of way.
Making the call to add a feature is actually the fairly easy part. I have a plan for multi-page support using groups and a couple of inkscape attributes, but I don't have the developers to put it together. It's the kind of thing where a whip round in a hat would bring in a pile of gold enough to hire someone to do the work, but even doing the collection is work and that's a catch-22.
What we need is more inkscape-users who can really get involved in the project. Not development tasks (unless you want to ;-)) but some of these other tasks. Community projects that involve communication, news, asking for money, doing bug management. There's a lot out there, but a small chunk each and we'd have a more robust structure to build the next inkscape from.
So come join inkscape, your svg editor needs you.
Best Regards, Martin Owens
P.S. For animation, everyone should be paying attention to AniGen.org that's a single developer doing a strong job of putting an animation editor together.
On Fri, 2017-04-21 at 16:06 +0200, Donn Ingle wrote:
Seems SVG is more and more invisible to the big companies. Here's sad tale of Amelia Bellamy-Royds's experiences with SVG and its seeming demise. (http://codepen.io/AmeliaBR/post/me-and-svg)
I wonder how the Inkscape devs (et al.) feel about this. Could Inkscape not take a new route, perhaps bake-in some new features*, now that the SVG standards seem to be moot?
* Multiple pages in one file — and export to multi-page PDFs. A real symbol system — within and between documents. Custom colours that don't rely on that fake gradient trick (And make them work between documents too!) Animation time lines. Output to gif, video and so forth. Perhaps to HTML5 Canvas with some js framework too. Scripting, Blender-style, right there in the app. In Python and JS perhaps. Opening of Gimp native files (xcf) into layers, perhaps. Use of 3D objects and materials, from Blender (say) directly in the canvas — some kind of OLE layer thing.
I am sure there are many more.
I think Inkscape could have, by now, matched what Flash, Freehand and Corel et al. had 20 years ago! It did not go there because it, honourably, stuck to the SVG standards.
Inkscape is the best thing we have for graphic design on Linux (at least), but it's still way too primitive. Could we dare to think bigger? Start our own standard?
Just wondering. Is this a disaster or an opportunity?
/d
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
There is also plenty to fix before things like wishlist items get attention. The text handling system and gradient banding issues, etc.
All new features should probably take a backseat while what is already there is fixed.
-C
On 21 Apr 2017 4:41 p.m., "Martin Owens" <doctormo@...155...> wrote:
This is more of an inkscape-devel discussion. But I'll add some thoughts here.
When SVG 1.1 was years and years old and no one except maybe Opera was doing anything with it at all, the Inkscape project added features, some from SVG 1.2 (flowing text etc), some from hacks (like the gradient stops) and some we just made whole cloth from our own xml namespace.
The problem comes when the SVG 2.0 specification really got going. We were left holding features which we'd probably have to keep being able to open, but other browsers and editors wouldn't ever be able to.
That's the core of the problem with doing things yourself.
What we lack here is a huge amount of developer time. We could do with having a whole brigade of selfless expert developers who follow instructions and produce amazing work. We'd also like it for free. This really is not realistic. We have instead is a small but amazing team of fairly even handed developers who follow their own passion projects and do it for sometimes free and sometimes outside contracts in a complex real world sort of way.
Making the call to add a feature is actually the fairly easy part. I have a plan for multi-page support using groups and a couple of inkscape attributes, but I don't have the developers to put it together. It's the kind of thing where a whip round in a hat would bring in a pile of gold enough to hire someone to do the work, but even doing the collection is work and that's a catch-22.
What we need is more inkscape-users who can really get involved in the project. Not development tasks (unless you want to ;-)) but some of these other tasks. Community projects that involve communication, news, asking for money, doing bug management. There's a lot out there, but a small chunk each and we'd have a more robust structure to build the next inkscape from.
So come join inkscape, your svg editor needs you.
Best Regards, Martin Owens
P.S. For animation, everyone should be paying attention to AniGen.org that's a single developer doing a strong job of putting an animation editor together.
On Fri, 2017-04-21 at 16:06 +0200, Donn Ingle wrote:
Seems SVG is more and more invisible to the big companies. Here's sad tale of Amelia Bellamy-Royds's experiences with SVG and its seeming demise. (http://codepen.io/AmeliaBR/post/me-and-svg)
I wonder how the Inkscape devs (et al.) feel about this. Could Inkscape not take a new route, perhaps bake-in some new features*, now that the SVG standards seem to be moot?
Multiple pages in one file — and export to multi-page PDFs. A real symbol system — within and between documents. Custom colours that don't rely on that fake gradient trick (And make them work between documents too!) Animation time lines. Output to gif, video and so forth. Perhaps to HTML5 Canvas with some js framework too. Scripting, Blender-style, right there in the app. In Python and JS perhaps. Opening of Gimp native files (xcf) into layers, perhaps. Use of 3D objects and materials, from Blender (say) directly in the canvas — some kind of OLE layer thing.
I am sure there are many more.
I think Inkscape could have, by now, matched what Flash, Freehand and Corel et al. had 20 years ago! It did not go there because it, honourably, stuck to the SVG standards.
Inkscape is the best thing we have for graphic design on Linux (at least), but it's still way too primitive. Could we dare to think bigger? Start our own standard?
Just wondering. Is this a disaster or an opportunity?
/d
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Also remember a lot of people use inkscape to produce SVG files for their (vinyl) cutting machines so let's NOT loose that ability or change it too much so they stop working with them.
Added features are good but SVG is not just for web browsers
Gaz
Inkscape should always be able to export to svg (even if it is not the future of the inkscape construction format). So people who use svg for things should never worry that inkscape will stop being able to handle/produce svgs.
On Fri, Apr 21, 2017 at 5:24 PM, Gary Hawkins <dragonlord666@...155...> wrote:
Also remember a lot of people use inkscape to produce SVG files for their (vinyl) cutting machines so let's NOT loose that ability or change it too much so they stop working with them.
Added features are good but SVG is not just for web browsers
Gaz
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
good to know, thanks
On 21 April 2017 at 17:36, C R <cajhne@...155...> wrote:
Inkscape should always be able to export to svg (even if it is not the future of the inkscape construction format). So people who use svg for things should never worry that inkscape will stop being able to handle/produce svgs.
On Fri, 2017-04-21 at 17:24 +0100, Gary Hawkins wrote:
Also remember a lot of people use inkscape to produce SVG files for their (vinyl) cutting machines so let's NOT loose that ability or change it too much so they stop working with them.
Added features are good but SVG is not just for web browsers
Would you be one of those people Gaz?
I'm looking to build a sub-community of inkscape users-who-make things, so we have a central place to go for plugins, help and testing of new releases.
But the project would need someone to pull it together. If you know anyone, or are someone, do email me as I think it's something that would really help.
Best Regards, Martin Owens
On Fri, 21 Apr 2017 13:57:27 -0400 Martin Owens <doctormo@...155...> wrote:
On Fri, 2017-04-21 at 17:24 +0100, Gary Hawkins wrote:
Also remember a lot of people use inkscape to produce SVG files for their (vinyl) cutting machines so let's NOT loose that ability or change it too much so they stop working with them.
Added features are good but SVG is not just for web browsers
Would you be one of those people Gaz?
I'm looking to build a sub-community of inkscape users-who-make things, so we have a central place to go for plugins, help and testing of new releases.
But the project would need someone to pull it together. If you know anyone, or are someone, do email me as I think it's something that would really help.
Best Regards, Martin Owens
Just coming out of 'lurk' mode briefly :)
I use Inkscape for everything from electronic schematics to scaled layouts of machine control panels.
A couple of years ago I also designed my entire kitchen using Inkscape, and the cabinet maker was impressed with how well it actually fitted.
P.S. My house was built circa 1880 and there isn't a square corner or straight wall anywhere in it.
All of these are great idea for inkscape. It's a fantastic multiple for everything from package design, to industrial design (I use it for both professionally), and devs have been great about adding and improving features that make it more useful across the board.
It's only going to get better, and thanks to everyone for the support. :)
On 21 Apr 2017 7:13 p.m., "Abrolag" <abrolag@...16...> wrote:
On Fri, 21 Apr 2017 13:57:27 -0400 Martin Owens <doctormo@...155...> wrote:
On Fri, 2017-04-21 at 17:24 +0100, Gary Hawkins wrote:
Also remember a lot of people use inkscape to produce SVG files for their (vinyl) cutting machines so let's NOT loose that ability or change it too much so they stop working with them.
Added features are good but SVG is not just for web browsers
Would you be one of those people Gaz?
I'm looking to build a sub-community of inkscape users-who-make things, so we have a central place to go for plugins, help and testing of new releases.
But the project would need someone to pull it together. If you know anyone, or are someone, do email me as I think it's something that would really help.
Best Regards, Martin Owens
Just coming out of 'lurk' mode briefly :)
I use Inkscape for everything from electronic schematics to scaled layouts of machine control panels.
A couple of years ago I also designed my entire kitchen using Inkscape, and the cabinet maker was impressed with how well it actually fitted.
P.S. My house was built circa 1880 and there isn't a square corner or straight wall anywhere in it.
-- W J G
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
I agree. In 2008, I used it to plan the top-view of my house! I printed it all out on multiple A4 pages and taped them together for the builder. Poor bugger. :D
Awesome app. One of the jewels in the libre crown. No doubt.
/d
On 21 April 2017 at 20:20, C R <cajhne@...155...> wrote:
All of these are great idea for inkscape. It's a fantastic multiple for everything from package design, to industrial design (I use it for both professionally), and devs have been great about adding and improving features that make it more useful across the board.
It's only going to get better, and thanks to everyone for the support. :)
On 21 Apr 2017 7:13 p.m., "Abrolag" <abrolag@...16...> wrote:
On Fri, 21 Apr 2017 13:57:27 -0400 Martin Owens <doctormo@...155...> wrote:
On Fri, 2017-04-21 at 17:24 +0100, Gary Hawkins wrote:
Also remember a lot of people use inkscape to produce SVG files for their (vinyl) cutting machines so let's NOT loose that ability or change it too much so they stop working with them.
Added features are good but SVG is not just for web browsers
Would you be one of those people Gaz?
I'm looking to build a sub-community of inkscape users-who-make things, so we have a central place to go for plugins, help and testing of new releases.
But the project would need someone to pull it together. If you know anyone, or are someone, do email me as I think it's something that would really help.
Best Regards, Martin Owens
Just coming out of 'lurk' mode briefly :)
I use Inkscape for everything from electronic schematics to scaled layouts of machine control panels.
A couple of years ago I also designed my entire kitchen using Inkscape, and the cabinet maker was impressed with how well it actually fitted.
P.S. My house was built circa 1880 and there isn't a square corner or straight wall anywhere in it.
-- W J G
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On Fri, 2017-04-21 at 20:52 +0200, Donn Ingle wrote:
I agree. In 2008, I used it to plan the top-view of my house! I printed it all out on multiple A4 pages and taped them together for the builder. Poor bugger. :D
Awesome app. One of the jewels in the libre crown. No doubt.
Maybe we can all share our house plans in an inkscape.org gallery ;-) sounds like we've all done it.
Martin,
Does a dog bunk bed count? :D
On 21 Apr 2017 8:18 p.m., "Martin Owens" <doctormo@...155...> wrote:
On Fri, 2017-04-21 at 20:52 +0200, Donn Ingle wrote:
I agree. In 2008, I used it to plan the top-view of my house! I printed it all out on multiple A4 pages and taped them together for the builder. Poor bugger. :D
Awesome app. One of the jewels in the libre crown. No doubt.
Maybe we can all share our house plans in an inkscape.org gallery ;-) sounds like we've all done it.
Martin,
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Ha. Yes! It houses many fleas. :
/d
On 21 Apr 2017 21:46, "C R" <cajhne@...155...> wrote:
Does a dog bunk bed count? :D
On 21 Apr 2017 8:18 p.m., "Martin Owens" <doctormo@...155...> wrote:
On Fri, 2017-04-21 at 20:52 +0200, Donn Ingle wrote:
I agree. In 2008, I used it to plan the top-view of my house! I printed it all out on multiple A4 pages and taped them together for the builder. Poor bugger. :D
Awesome app. One of the jewels in the libre crown. No doubt.
Maybe we can all share our house plans in an inkscape.org gallery ;-) sounds like we've all done it.
Martin,
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On Fri, Apr 21, 2017 at 9:53 AM, C R <cajhne@...155...> wrote:
There is also plenty to fix before things like wishlist items get attention. [...]
All new features should probably take a backseat while what is already
there is fixed.
But if Martin is right and a lot of the features that come from volunteer dev work are "passion projects", then those work hours will come in whichever order anyway, regardless of priority. Anyway, there is plenty in the OP wishlist that is accomplishable now or later without abandoning (even a troubled) web standard.
As for the linked blog post,
I've promised them that I'll write up a summary of the issues as I see them. This post was supposed to be that, but that'll have to be something separate instead.
This will be more convincing to me about the future of open vector formats.
—Arlo
I understand all too well, Martin. The real-world restrictions on resources and people make any free software we have truly special.
I guess the standardizing of SVG is in a similar bind. I can't believe there are big companies, drowning in dollars, who can't be bothered. It's a failure of the commercial/libre hybrid, which really has its own worst enemy for a roommate.
The Inkscape we have now is better than nothing, but is that enough? Can the devs not shuck the limitations of an external standard — one that is drying up fast?
What if the devs could dream?
Perhaps the Inkscape community could draft a new Standard Graphics Language? Take all the amazing knowledge and detailed work that has gone into SVG as a foundation. It's not like browsers and commercial companies give a rat's for it, so why pander to their hypothetical futures?
(I'm not saying break basic SVG that has some web foothold. I doubt Inkscape as a web SVG tool — with all the extra stuff like css, animations, events and js that the web demands, but here's the thing: if SVG is gonna die, then so will Inkscape if it's correlated to it.)
In a way, this kibosh of SVG is like a brake pedal on libre innovation. We can't proceed because we want to play by the rules, but we allow those rules to be set by commercial software. They can streak-ahead, patenting and lawyering as they go, and they can tap the brakes on us any time they like.
tl;dr : The SVG standard is a boon, and an impediment. Let's own it and redirect into a future without a knife in the back!
Am I completely off track?
/d
On 21 April 2017 at 17:39, Martin Owens <doctormo@...155...> wrote:
This is more of an inkscape-devel discussion. But I'll add some thoughts here.
When SVG 1.1 was years and years old and no one except maybe Opera was doing anything with it at all, the Inkscape project added features, some from SVG 1.2 (flowing text etc), some from hacks (like the gradient stops) and some we just made whole cloth from our own xml namespace.
The problem comes when the SVG 2.0 specification really got going. We were left holding features which we'd probably have to keep being able to open, but other browsers and editors wouldn't ever be able to.
That's the core of the problem with doing things yourself.
What we lack here is a huge amount of developer time. We could do with having a whole brigade of selfless expert developers who follow instructions and produce amazing work. We'd also like it for free. This really is not realistic. We have instead is a small but amazing team of fairly even handed developers who follow their own passion projects and do it for sometimes free and sometimes outside contracts in a complex real world sort of way.
Making the call to add a feature is actually the fairly easy part. I have a plan for multi-page support using groups and a couple of inkscape attributes, but I don't have the developers to put it together. It's the kind of thing where a whip round in a hat would bring in a pile of gold enough to hire someone to do the work, but even doing the collection is work and that's a catch-22.
What we need is more inkscape-users who can really get involved in the project. Not development tasks (unless you want to ;-)) but some of these other tasks. Community projects that involve communication, news, asking for money, doing bug management. There's a lot out there, but a small chunk each and we'd have a more robust structure to build the next inkscape from.
So come join inkscape, your svg editor needs you.
Best Regards, Martin Owens
P.S. For animation, everyone should be paying attention to AniGen.org that's a single developer doing a strong job of putting an animation editor together.
On Fri, 2017-04-21 at 16:06 +0200, Donn Ingle wrote:
Seems SVG is more and more invisible to the big companies. Here's sad tale of Amelia Bellamy-Royds's experiences with SVG and its seeming demise. (http://codepen.io/AmeliaBR/post/me-and-svg)
I wonder how the Inkscape devs (et al.) feel about this. Could Inkscape not take a new route, perhaps bake-in some new features*, now that the SVG standards seem to be moot?
Multiple pages in one file — and export to multi-page PDFs. A real symbol system — within and between documents. Custom colours that don't rely on that fake gradient trick (And make them work between documents too!) Animation time lines. Output to gif, video and so forth. Perhaps to HTML5 Canvas with some js framework too. Scripting, Blender-style, right there in the app. In Python and JS perhaps. Opening of Gimp native files (xcf) into layers, perhaps. Use of 3D objects and materials, from Blender (say) directly in the canvas — some kind of OLE layer thing.
I am sure there are many more.
I think Inkscape could have, by now, matched what Flash, Freehand and Corel et al. had 20 years ago! It did not go there because it, honourably, stuck to the SVG standards.
Inkscape is the best thing we have for graphic design on Linux (at least), but it's still way too primitive. Could we dare to think bigger? Start our own standard?
Just wondering. Is this a disaster or an opportunity?
/d
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On Fri, 21 Apr 2017 16:06:24 +0200 Donn Ingle <donn.ingle@...155...> wrote:
Seems SVG is more and more invisible to the big companies. Here's sad tale of Amelia Bellamy-Royds's experiences with SVG and its seeming demise. (http://codepen.io/AmeliaBR/post/me-and-svg)
I wonder how the Inkscape devs (et al.) feel about this. Could Inkscape not take a new route, perhaps bake-in some new features*, now that the SVG standards seem to be moot?
I'm very satified with Inkscape. I use it for simple drawings on Troubleshooters.Com, and in the books I sell. Inkscape-authored graphics have tiny byte counts, and look great at any magnification. I use it to fill in PDFs. My course diploma maker uses an Inscape-drawn SVG file as a template with tokens replaced according to information in a YAML file. I use Inkscape to create all sorts of other templates for other automation. My form-letter generator is Inkscape based.
Multiple pages in one file
Put all the files in one directory for convenience, play them back in an HTML file that's created programmatically with a 50 line Python file.
— and export to multi-page PDFs.
LaTeX
A real symbol system — within and *between *documents. Custom colours that don't rely on that fake gradient trick (And make them work between documents too!)
Not sure what you mean here: I can implement any color that's describeable as #RRGGBB.
Animation time lines.
Sounds kind of niche to me, considering that SVG1 is for images
Output to gif,
convert test.svg test.gif
video and so forth. Perhaps to HTML5 Canvas with some
This seems to be beyond the mandate of Inkscape, and yet, check out this page:
http://www.creativebloq.com/inspiration/8-great-examples-of-graphic-design-p...
js framework too.
Why?
Scripting, Blender-style, right there in the app.
"Right there in the app" is the entire issue I have with all of this. You have a perfectly good SVG file that secondary programs can manipulate to their heart's content. The minute Inscape becomes an SVG superset or SVG-noncompliant, this very valuable feature goes away.
In Python and JS perhaps. Opening of Gimp native files (xcf) into layers, perhaps. Use of 3D objects and materials, from Blender (say) directly in the canvas — some kind of OLE layer thing.
Where do I start?
The preceding features, if added to Inkscape itself instead of as separate programs to work on the SVG file, would add tons of complexity to Inkscape. Complexity means bugs, instability, and all too often incompatibility.
Features have value only to the extent that they bestow benefits. I haven't seen benefits attached to the preceding features, but I'd expect that each such benefit accommodates only a small percentage of Inkscape users. And a lot of these features could be implemented as separate programs that operate on the SVG file. Doing it that way leaves Inkscape simple, and each feature's program is simple. Few bugs.
OLE? Are you kidding? Some who use Inkscape do it on Linux, where simplicity is a virtue.
I am sure there are many more.
I think Inkscape could have, by now, matched what Flash, Freehand and Corel et al. had 20 years ago!
That 20 years point is a bit of an ad-hominem, don't you think?
It did not go there because it, honourably, stuck to the SVG standards.
Yeah. That's why I can put an Inkscape-created SVG on Troubleshooters.Com, and anybody with a halfway modern browser can see it. These days I don't even use .png as a fallback: Everyone can read my Inkscape-authored graphics. SVG is THE standard for EPUB images.
And the fact that Inscape, for the most part, stuck to the SVG standards, means that anybody wanting an additional feature can throw together a Python program that parses the XML, reads the nodes, and copies off to a modified version that incorporates the desired feature.
Inkscape is the best thing we have for graphic design on Linux (at least), but it's still way too primitive. Could we dare to think bigger? Start our own standard?
Just wondering. Is this a disaster or an opportunity?
Opportunity. Roll up your sleeves and code a translator to convert *standard* SVG to a multipage display, or whatever you want.
But please: Inkscape works perfectly: Don't add a bunch of code, to Inkscape itself, to give bugs nooks and crannies in which to hide out, and don't diverge from SVG.
When it comes to Inkscape itself, as opposed to add-on programs, please leave well enough alone.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
On 21 April 2017 at 21:26, Steve Litt <slitt@...2357...> wrote:
I'm very satified with Inkscape.
It's a great app.
To your points on my suggestions for new stuff in Inkscape: It's an old road, well worn. I don't wanna.
Bottom line is I don't think there's a good reason that software should be a false dilemma. There're ways to make it suit *many* kinds of minds. Look at what Firefox does with Addons, for example.
"Right there in the app" is the entire issue I have with all of this. You have a perfectly good SVG file that secondary programs can manipulate to their heart's content. The minute Inscape becomes an SVG superset or SVG-noncompliant, this very valuable feature goes away.
I get it, and here's the thing: SVG, it's in serious trouble; fatal trouble if recent articles are to be heard. The Walking Doctype.
I think Inkscape could have, by now, matched what Flash, Freehand and Corel et al. had 20 years ago!
That 20 years point is a bit of an ad-hominem, don't you think?
Not intended as such.
My truth: I wish I could be as productive in design as I was in the late 90's. Linux has been my life for 17 years, but I could not continue in the design world because I'd left Windows, Adobe, yadda yadda... etc.
I have made-do. I have scripted and written Python apps. I have done All The Things to massage vectors into pixels and back. To squeeze HTML and ebooks and PDFs and images out of the stones in my $PATH. It's fun, but time spent there is time *not* spent designing artwork for clients.
Yeah. That's why I can put an Inkscape-created SVG on Troubleshooters.Com, and anybody with a halfway modern browser can see it. These days I don't even use .png as a fallback: Everyone can read my Inkscape-authored graphics. SVG is THE standard for EPUB images.
Sure. I agree. The core of SVG that is respected by browsers (into the future) should be sacrosanct and Inkscape is unlikey to throw all that code out. Software accrues thus.
/d
New to me too. There 's a link in my OP and this (another story) from Tav: http://tavmjong.free.fr/svg2_status.html
/d
On 21 April 2017 at 23:07, Abrolag <abrolag@...16...> wrote:
On Fri, 21 Apr 2017 22:49:23 +0200 Donn Ingle <donn.ingle@...155...> wrote:
I get it, and here's the thing: SVG, it's in serious trouble; fatal
trouble
if recent articles are to be heard. The Walking Doctype.
In trouble? News to me.
-- W J G
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On Fri, 21 Apr 2017 22:07:17 +0100 Abrolag <abrolag@...16...> wrote:
On Fri, 21 Apr 2017 22:49:23 +0200 Donn Ingle <donn.ingle@...155...> wrote:
I get it, and here's the thing: SVG, it's in serious trouble; fatal trouble if recent articles are to be heard. The Walking Doctype.
In trouble? News to me.
This appears to be based on:
* http://codepen.io/AmeliaBR/post/me-and-svg
* http://tavmjong.free.fr/svg2_status.html
Having read both the preceding, it looks to me like the project to define version 2 simply failed, probably because they bit off more than they could chew. Or perhaps more than browser makers were willing to implement at one time.
I'm not in a position to know about the SVG2 spec project, but sometimes when a specification fails, it's for the best. Sometimes a bunch of people get together and frenzy themselves into including or providing hooks for every conceivable situation, and that usually results in complexity, which results in bugs, instability and incompatibility.
The second of the articles mentioned the browser makers are ready, willing and able to implement an SVG2 with problem fixes and a few specific features. I'd hardly call that "life support." At this point I'm not sure who is left to tear out the stuff that's objected to: It would be horribly difficult to work all those months on a spec you love only to be told to rip it out, but if somebody can rip out the unwanted part of the spec, SVG progresses, though more slowly. I'd imagine the ripped out stuff gets put in a new document, some of which will someday become SVG3.
Like I say, my knowlege of the situation is based on the two links quoted in this thread, but it doesn't seem as dire as "life support" to me, nor does it seem like an excuse for radically changing Inkscape, which works quite well right now, producing and rendering standard SVG files.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
On 22 Apr 2017 07:59, "Steve Litt" <slitt@...2357...> wrote:
On Fri, 21 Apr 2017 22:07:17 +0100 Appears to be based on:
* http://codepen.io/AmeliaBR/post/me-and-svg
* http://tavmjong.free.fr/svg2_status.html
Having read both the preceding, it looks to me like the project to define version 2 simply failed, probably because they bit off more than they could chew. Or perhaps more than browser makers were willing to implement at one time.
I'm not in a position to know about the SVG2 spec project, but sometimes when a specification fails, it's for the best. Sometimes a bunch of people get together and frenzy themselves into including or providing hooks for every conceivable situation, and that usually results in complexity, which results in bugs, instability and incompatibility.
The second of the articles mentioned the browser makers are ready, willing and able to implement an SVG2 with problem fixes and a few specific features. I'd hardly call that "life support." At this point I'm not sure who is left to tear out the stuff that's objected to: It would be horribly difficult to work all those months on a spec you love only to be told to rip it out, but if somebody can rip out the unwanted part of the spec, SVG progresses, though more slowly. I'd imagine the ripped out stuff gets put in a new document, some of which will someday become SVG3.
Like I say, my knowlege of the situation is based on the two links quoted in this thread, but it doesn't seem as dire as "life support" to me, nor does it seem like an excuse for radically changing Inkscape, which works quite well right now, producing and rendering standard SVG files.
I'm not in a position to know either, but two articles by people both repected, committed and passionate speaks loudly.
Whatever the defences of the status quo, there may be no SVG 3. That's what the what-if thread is raising.
/d
On Fri, 21 Apr 2017 22:49:23 +0200 Donn Ingle <donn.ingle@...155...> wrote:
Bottom line is I don't think there's a good reason that software should be a false dilemma. There're ways to make it suit *many* kinds of minds. Look at what Firefox does with Addons, for example.
The preceding paragraph pretty much makes my point. About 1/3 of the people I interact with on Linux group lists have said that Firefox is now so bloated as to be unuseable. As years went by and they crammed more and more features, whether via Addons, plugins or hard coding, the less stable Firefox has become. On my box, by the time I open my 5th page and operate the program for a half hour, it responds slower than a DOS program on a 1200 baud modem.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
On 22 Apr 2017 07:44, "Steve Litt" <slitt@...2357...> wrote:
On Fri, 21 Apr 2017 22:49:23 +0200 Donn Ingle <donn.ingle@...155...> wrote:
Bottom line is I don't think there's a good reason that software should be a false dilemma. There're ways to make it suit *many* kinds of minds. Look at what Firefox does with Addons, for example.
The preceding paragraph pretty much makes my point. About 1/3 of the people I interact with on Linux group lists have said that Firefox is now so bloated as to be unuseable. As years went by and they crammed more and more features, whether via Addons, plugins or hard coding, the less stable Firefox has become. On my box, by the time I open my 5th page and operate the program for a half hour, it responds slower than a DOS program on a 1200 baud modem.
SteveT
I offered it in example of the idea.
Inkscape is great, but also very slow. A few thousand nodes and it suffers. Thus, I do not want cramming and bloating either.
I speak of a graphic design app that has holes where designers need tools. You speak of why holes are a benefit. This, to me does not compute.
I know its not impossible to have software as good as Freehand or Flash was, years ago, on much slower pcs - because they existed.
If the SVG std is dissolving, it could be time to rethink ink!
/d
On Sat, 22 Apr 2017, Donn Ingle wrote:
I know its not impossible to have software as good as Freehand or Flash was, years ago, on much slower pcs - because they existed.
wordstar worked on 8 bit processors, that doesn't mean that inkscape should try to do the job that wordstar was written for.
Freehand and Flash don't do the job that inkscape does, don't try to convert inkscape to do the job that they were written to do.
David Lang
There's another danger to Inkscape, and that's lack of progress as a professional design tool. There are holes in Inkscape functionality compared to other industry leading software, and some open source projects are starting to catch up to and in some areas exceed inkscape capabilities. If a tool used primarily for graphics, and designed for professional graphics work can not match features needed (and commonly requested by professional full time graphics people) other projects will become more popular, leading to a shift in the user base to other software.
So the attitude that inkscape works perfectly as it is, is also a slow suffocation death for the project. Confining it to specific simplistic use cases based on personal preferences, and calling what you don't personally use "bloat" is ignoring the bigger purpose of inkscape as a professional vector graphics design tool.
The "bloat" is not causing the slowness. There is a lot in Inkscape that needs refactoring, and a lot that needs refinement and optimization. We do not need to be tossing out good ideas which are asked for by our professional graphic design users that make Inkscape more useful because some users are content to use it only for laser cutting (as an example).
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs, and its disrespectful to the design community who need Inkscape to be a fully realised vector graphics production studio.
No one is suggesting that your use case should be affected. Users who are happy with how Inkscape is will probably notice only that Inkscape is faster, has more useful node tools and layer grouping modes, and is cleaner and easier to work with in general, affording more screen real estate for drawing.
Lots of improvements on the way, let's not denounce them beforehand. That next feature you think you don't need might be the best thing that ever happened to your work flow.
Just some thoughts. -C
On 22 Apr 2017 08:23, "David Lang" <david@...2429...> wrote:
On Sat, 22 Apr 2017, Donn Ingle wrote:
I know its not impossible to have software as good as Freehand or Flash was, years ago, on much slower pcs - because they existed.
wordstar worked on 8 bit processors, that doesn't mean that inkscape should try to do the job that wordstar was written for.
Freehand and Flash don't do the job that inkscape does, don't try to convert inkscape to do the job that they were written to do.
David Lang
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Exactly.
And if (*if*) SVG is staggering to a bit grave, perhaps it's time to reboot inkscape by making the standards of graphics ourselves.
I used Flash as an example because they have such a vastly superior drawing interface. All the little details (like, when you step into a group or movie-clip, all the parent layers dim a little and you can see clearly where you are) make a huge difference in sheer efficiency.
Things like symbols (clones, whatever) that can cross file boundaries are vital. Vital. There is no way to maintain a list of client logos and their use in multiple design files if, when there comes some change to the logo, one has to manually visit every file and manually change it again. Even given some clever SVG sed/grep/python voodoo, why would I spend a week writing code to do what design software did in the 90's? It's not rational.
Things like colours that have a customized palette - one uses a "swatch" all over the place and then one can change the actual colour of that swatch and it changes wherever you used it. Vital. Vital. Inkscape has a tedious workaround using one-stop gradients for this. It sucks and it doesn't work in exported PDFs.
I won't go on. When I start, I find I can't stop thinking of cool ideas; and I've not been in graphics since 2000.
/d
On 22 April 2017 at 10:21, C R <cajhne@...155...> wrote:
There's another danger to Inkscape, and that's lack of progress as a professional design tool. There are holes in Inkscape functionality compared to other industry leading software, and some open source projects are starting to catch up to and in some areas exceed inkscape capabilities. If a tool used primarily for graphics, and designed for professional graphics work can not match features needed (and commonly requested by professional full time graphics people) other projects will become more popular, leading to a shift in the user base to other software.
So the attitude that inkscape works perfectly as it is, is also a slow suffocation death for the project. Confining it to specific simplistic use cases based on personal preferences, and calling what you don't personally use "bloat" is ignoring the bigger purpose of inkscape as a professional vector graphics design tool.
The "bloat" is not causing the slowness. There is a lot in Inkscape that needs refactoring, and a lot that needs refinement and optimization. We do not need to be tossing out good ideas which are asked for by our professional graphic design users that make Inkscape more useful because some users are content to use it only for laser cutting (as an example).
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs, and its disrespectful to the design community who need Inkscape to be a fully realised vector graphics production studio.
No one is suggesting that your use case should be affected. Users who are happy with how Inkscape is will probably notice only that Inkscape is faster, has more useful node tools and layer grouping modes, and is cleaner and easier to work with in general, affording more screen real estate for drawing.
Lots of improvements on the way, let's not denounce them beforehand. That next feature you think you don't need might be the best thing that ever happened to your work flow.
Just some thoughts. -C
On 22 Apr 2017 08:23, "David Lang" <david@...2429...> wrote:
On Sat, 22 Apr 2017, Donn Ingle wrote:
I know its not impossible to have software as good as Freehand or Flash was, years ago, on much slower pcs - because they existed.
wordstar worked on 8 bit processors, that doesn't mean that inkscape should try to do the job that wordstar was written for.
Freehand and Flash don't do the job that inkscape does, don't try to convert inkscape to do the job that they were written to do.
David Lang
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On Sat, 22 Apr 2017 12:21:04 +0200 Donn Ingle <donn.ingle@...155...> wrote:
Exactly.
And if (*if*) SVG is staggering to a bit grave, perhaps it's time to reboot inkscape by making the standards of graphics ourselves.
I used Flash as an example because they have such a vastly superior drawing interface. All the little details (like, when you step into a group or movie-clip, all the parent layers dim a little and you can see clearly where you are) make a huge difference in sheer efficiency.
So, you're comparing something that works within fairly well defined limits and uses a known standard (and works pretty well), with a sprawling, buggy, proprietry monster.
Somehow you prefer the latter.
No thanks!
On 22 April 2017 at 14:43, Abrolag <abrolag@...16...> wrote:
So, you're comparing something that works within fairly well defined limits and uses a known standard (and works pretty well), with a sprawling, buggy, proprietry monster.
Somehow you prefer the latter.
No thanks!
I don't know what you mean.
/d
On Sat, 22 Apr 2017, Donn Ingle wrote:
On 22 April 2017 at 14:43, Abrolag <abrolag@...16...> wrote:
So, you're comparing something that works within fairly well defined limits and uses a known standard (and works pretty well), with a sprawling, buggy, proprietry monster.
Somehow you prefer the latter.
No thanks!
I don't know what you mean.
please show us the spec for Flash and the implementation that follows that spec reliably.
David Lang
On 22 April 2017 at 14:56, David Lang <david@...2429...> wrote:
On Sat, 22 Apr 2017, Donn Ingle wrote:
On 22 April 2017 at 14:43, Abrolag <abrolag@...16...>
wrote:
So, you're comparing something that works within fairly well defined limits and uses a known standard (and works pretty well), with a sprawling, buggy, proprietry monster.
Somehow you prefer the latter.
No thanks!
I don't know what you mean.
please show us the spec for Flash and the implementation that follows that spec reliably.
I am not talking about the Flash file format. I am using Flash (well, the one I recall from the late 90's) as an example of a superior user interface (the tools, the speed!, the means to animate, the many little subtle effects) and superior features (like the symbol system etc.)
Flash. Freehand. Corel. Those are my benchmarks, from 20 years ago. Inkscape is not as useful now as they were then: for creating graphics and getting them out into media, the web and print.
I am not slagging Inkscape either. I don't see why a higher standard should be seen as a threat. We can dream, and we should.
Does that make it clearer?
/d
On Sat, 22 Apr 2017, Donn Ingle wrote:
On 22 April 2017 at 14:56, David Lang <david@...2429...> wrote:
On Sat, 22 Apr 2017, Donn Ingle wrote:
On 22 April 2017 at 14:43, Abrolag <abrolag@...16...>
wrote:
So, you're comparing something that works within fairly well defined limits and uses a known standard (and works pretty well), with a sprawling, buggy, proprietry monster.
Somehow you prefer the latter.
No thanks!
I don't know what you mean.
please show us the spec for Flash and the implementation that follows that spec reliably.
I am not talking about the Flash file format. I am using Flash (well, the one I recall from the late 90's) as an example of a superior user interface (the tools, the speed!, the means to animate, the many little subtle effects) and superior features (like the symbol system etc.)
Flash. Freehand. Corel. Those are my benchmarks, from 20 years ago. Inkscape is not as useful now as they were then: for creating graphics and getting them out into media, the web and print.
I am not slagging Inkscape either. I don't see why a higher standard should be seen as a threat. We can dream, and we should.
Does that make it clearer?
If the underlying file format isn't the issue, then 'svg is dying' doesn't matter. If your argument is that the GUI could be better, then propose your improvements and don't argue about the file format.
David Lang
P.S. you can find passioned arguments that ANYTHING is a failure if you hunt the Internet enough.
I don't know what you are trying to say.
/d
On 22 Apr 2017 15:33, "David Lang" <david@...2429...> wrote:
On Sat, 22 Apr 2017, Donn Ingle wrote:
On 22 April 2017 at 14:56, David Lang <david@...2429...> wrote:
On Sat, 22 Apr 2017, Donn Ingle wrote:
On 22 April 2017 at 14:43, Abrolag <abrolag@...16...>
wrote:
So, you're comparing something that works within fairly well defined limits and uses a known standard (and works pretty well), with a sprawling, buggy, proprietry monster.
Somehow you prefer the latter.
No thanks!
I don't know what you mean.
please show us the spec for Flash and the implementation that follows
that
spec reliably.
I am not talking about the Flash file format. I am using Flash (well, the one I recall from the late 90's) as an example of a superior user
interface
(the tools, the speed!, the means to animate, the many little subtle effects) and superior features (like the symbol system etc.)
Flash. Freehand. Corel. Those are my benchmarks, from 20 years ago. Inkscape is not as useful now as they were then: for creating graphics and getting them out into media, the web and print.
I am not slagging Inkscape either. I don't see why a higher standard
should
be seen as a threat. We can dream, and we should.
Does that make it clearer?
If the underlying file format isn't the issue, then 'svg is dying' doesn't matter. If your argument is that the GUI could be better, then propose your improvements and don't argue about the file format.
David Lang
P.S. you can find passioned arguments that ANYTHING is a failure if you hunt the Internet enough.
------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On Sat, 22 Apr 2017, C R wrote:
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs, and its disrespectful to the design community who need Inkscape to be a fully realised vector graphics production studio.
No one is suggesting that your use case should be affected. Users who are happy with how Inkscape is will probably notice only that Inkscape is faster, has more useful node tools and layer grouping modes, and is cleaner and easier to work with in general, affording more screen real estate for drawing.
Actually, Donn Ingle is proposing that Inkscape no longer produce SVG, so he is proposing that many existing use cases will be thrown out.
Nobody here is opposing improvement, we are opposing throwing out the existing user base in pursuit of some theoretical new user base.
Some specific features being proposed are being opposed, but that's on the bases of the specific feature, not a general opposition to change/improvement.
David Lang
On 22 April 2017 at 14:24, David Lang <david@...2429...> wrote:
Actually, Donn Ingle is proposing that Inkscape no longer produce SVG, so he is proposing that many existing use cases will be thrown out.
I am not so proposing.
Here it is: SVG appears to be dying. Assuming this is so, I propose to continue SVG within the Inkscape community (at least) *and* take the chance to update Inkscape (at least) so that its many design holes are filled.
This new SVG would in no way break the older standard, however this is achieved.
/d
On Sat, 22 Apr 2017, Donn Ingle wrote:
On 22 April 2017 at 14:24, David Lang <david@...2429...> wrote:
Actually, Donn Ingle is proposing that Inkscape no longer produce SVG, so he is proposing that many existing use cases will be thrown out.
I am not so proposing.
Here it is: SVG appears to be dying. Assuming this is so, I propose to continue SVG within the Inkscape community (at least)
well, if you are not proposing abandoning SVG, then why keep arguing the point that it may be dying? What's the difference between "SVG is not dying" and "SVG is dying, but we should continue to use it"?
*and* take the chance to update Inkscape (at least) so that its many design holes are filled.
updating Inkscape can happen regardless.
This new SVG would in no way break the older standard, however this is achieved.
creating a SVG derivitive is a bad idea, in spite of what you think, there is a lot of stuff that works with the output of inkscape.
And what exactly needs to change in SVG to implement the new features you want in Inkscape? Especially when you consider the need to be portable across all the platforms that Inkscape is used on (even if you ignore all the platforms that the resulting svg is used on)
embedded python isn't an option unless you are going to embed a python interpreter as well. I'm not going to go back and dig up all the prior posts to find other suggestions, but you would be far better off just proposing new features and improvements rather than starting off by claiming that SVG is dying and therefor we should accept new features. Justify eacy feature by itself.
David Lang
On 22 April 2017 at 14:55, David Lang <david@...2429...> wrote:
SVG appears to be dying. Assuming this is so, I propose to continue SVG within the Inkscape community (at least)
well, if you are not proposing abandoning SVG, then why keep arguing the point that it may be dying? What's the difference between "SVG is not dying" and "SVG is dying, but we should continue to use it"?
Assuming the SVG standard is dying, then why not try to save it? Take it away from the big companies that are retarding it and bring it into the Inkscape community (at least).
I don't have the answer, but I am raising the idea. Save it by intervention. Take it and extend it.
*and* take the chance to update Inkscape (at least) so that its many design holes are filled.
updating Inkscape can happen regardless.
Well, I am not so sure. I have read many threads where the reason given for not adding features is because they are not in the SVG standard, or are under (interminable) discussion, or some other nice time-sink which leaves them in the cold. (I can't find examples right now.)
This new SVG would in no way break the older standard, however this is achieved.
creating a SVG derivitive is a bad idea, in spite of what you think, there is a lot of stuff that works with the output of inkscape.
Sure, and there's no reason why Inkscape could not continue to output what this other stuff requires. Clever use of the GUI and some form of "export as" system is not beyond imagination.
Also, if this other stuff freezes in time along with SVG itself, then it will fall out of use.
And what exactly needs to change in SVG to implement the new features you want in Inkscape? Especially when you consider the need to be portable across all the platforms that Inkscape is used on (even if you ignore all the platforms that the resulting svg is used on)
I don't know. Conversation hasn't reached these areas yet. Perhaps it will if we see SVG as our own, rather than some ideal.
let's call the new version SVFree. What the heck.
embedded python isn't an option unless you are going to embed a python interpreter as well. I'm not going to go back and dig up all the prior posts to find other suggestions, but you would be far better off just proposing new features and improvements rather than starting off by claiming that SVG is dying and therefor we should accept new features. Justify eacy feature by itself.
I hope, by now, that my position is clearer. The main point is this seems to be a crux. We can face facts and intervene in SVG's fate or we can lose all that Inkscape has achieved. (Assuming SVG does not regain a pulse somehow.)
/d
On Sat, 22 Apr 2017 09:21:52 +0100 C R <cajhne@...155...> wrote:
Confining it to specific simplistic use cases based on personal preferences, and calling what you don't personally use "bloat" is ignoring the bigger purpose of inkscape as a professional vector graphics design tool.
Nobody in this thread called anything about Inkscape "bloat", nor said that code related to what they don't use is "bloat". Go back and check the archives. I brought up "bloat" with respect to Firefox.
The "bloat" is not causing the slowness. There is a lot in Inkscape that needs refactoring, and a lot that needs refinement and optimization.
Nobody in this thread said Inkscape is currently bloated. What I said, although not in so many words, is that glomming on the feature list recommended by Donn Ingle would greatly increase its complexity.
We do not need to be tossing out good ideas which are asked for by our professional graphic design users that make Inkscape more useful because some users are content to use it only for laser cutting (as an example).
In that case, the professional graphic design users should prioritize which good ideas are most important, so we don't bury everything and a marching band inside currently good code. And those pro graphic designers should give us some ideas of how to implement those ideas in a way compatible to SVG1, or else brainstorm to come up with an idea of how to implement stuff incompatible with SVG1 within separate executables.
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs,
Oh HELL no. If devs hugely complexify software to the extent that it becomes buggy, slow and incompatible, they ruined the software, and deserve disrespect. It should be noted that nobody in this thread made that accusation about *Inkscape* developers.
I did, however, say that if Donn Ingle's long laundry list of changes were implemented en masse, and especially without regard to the SVG standard, it would result in complexity (a better word for bloat). I stand by that, and suspect that Inkscape developers agree.
and its disrespectful to the design community who need Inkscape to be a fully realised vector graphics production studio.
OK, fine. Why don't you submit a list of improvements to Inkscape, sorted by descending importance, so improvement can be done slowly and steadily, instead of as a free-for-all. Next to each improvement, be sure to fully specify how the improvement would look, what the user interface might feel like, what part of the SVG spec can support it, and perhaps a few suggestions of where it might fit into the existing code.
Hey, I never said Inkscape is perfect. Nobody who has ever done a gradient in Inkscape would make that statement. What I'm saying is it's pretty darn good, so don't break it in pursuit of the "perfect".
No one is suggesting that your use case should be affected. Users who are happy with how Inkscape is will probably notice only that Inkscape is faster,
"Faster" isn't the usual result when a bunch of features are added. There are limits to the wizardry of even the best programmers.
has more useful node tools and layer grouping modes, and is cleaner and easier to work with in general, affording more screen real estate for drawing.
Sounds like you've got some work cut out for you, suggesting a specification for node tools and layer grouping, and for Inkscape's graphical user interface.
Lots of improvements on the way, let's not denounce them beforehand.
I'll denounce them beforehand every time someone suggests a combination of an OLE type thing *and* video *and* multipage *and* Javascript framework *and* XCF *and* 3D *and* Python interface *and* immitation of Flash *and especially* dumping the SVG standard that allows me to use Inkscape as a tool to do some pretty cool stuff. How would you like to code all that crap? How would you like to do support on the finished result? Yeah, me neither. It was a horrible idea, as stated.
That next feature you think you don't need might be the best thing that ever happened to your work flow.
Happens all the time. But it happens only when the next feature is part of an incremental improvement policy, carefully designed for simplicity and encapsulation, carefully crafted, and released only when it's ready. However, when it's quickied into the code, especially as part of a laundry list of almost unrelated other features, the only way it improves my work flow is if I move to a superior program after the current one collapses under the weight of its complexity.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Your take on my words is bizarre. Be more charitable.
/d
On 22 April 2017 at 18:39, Steve Litt <slitt@...2357...> wrote:
On Sat, 22 Apr 2017 09:21:52 +0100 C R <cajhne@...155...> wrote:
Confining it to specific simplistic use cases based on personal preferences, and calling what you don't personally use "bloat" is ignoring the bigger purpose of inkscape as a professional vector graphics design tool.
Nobody in this thread called anything about Inkscape "bloat", nor said that code related to what they don't use is "bloat". Go back and check the archives. I brought up "bloat" with respect to Firefox.
The "bloat" is not causing the slowness. There is a lot in Inkscape that needs refactoring, and a lot that needs refinement and optimization.
Nobody in this thread said Inkscape is currently bloated. What I said, although not in so many words, is that glomming on the feature list recommended by Donn Ingle would greatly increase its complexity.
We do not need to be tossing out good ideas which are asked for by our professional graphic design users that make Inkscape more useful because some users are content to use it only for laser cutting (as an example).
In that case, the professional graphic design users should prioritize which good ideas are most important, so we don't bury everything and a marching band inside currently good code. And those pro graphic designers should give us some ideas of how to implement those ideas in a way compatible to SVG1, or else brainstorm to come up with an idea of how to implement stuff incompatible with SVG1 within separate executables.
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs,
Oh HELL no. If devs hugely complexify software to the extent that it becomes buggy, slow and incompatible, they ruined the software, and deserve disrespect. It should be noted that nobody in this thread made that accusation about *Inkscape* developers.
I did, however, say that if Donn Ingle's long laundry list of changes were implemented en masse, and especially without regard to the SVG standard, it would result in complexity (a better word for bloat). I stand by that, and suspect that Inkscape developers agree.
and its disrespectful to the design community who need Inkscape to be a fully realised vector graphics production studio.
OK, fine. Why don't you submit a list of improvements to Inkscape, sorted by descending importance, so improvement can be done slowly and steadily, instead of as a free-for-all. Next to each improvement, be sure to fully specify how the improvement would look, what the user interface might feel like, what part of the SVG spec can support it, and perhaps a few suggestions of where it might fit into the existing code.
Hey, I never said Inkscape is perfect. Nobody who has ever done a gradient in Inkscape would make that statement. What I'm saying is it's pretty darn good, so don't break it in pursuit of the "perfect".
No one is suggesting that your use case should be affected. Users who are happy with how Inkscape is will probably notice only that Inkscape is faster,
"Faster" isn't the usual result when a bunch of features are added. There are limits to the wizardry of even the best programmers.
has more useful node tools and layer grouping modes, and is cleaner and easier to work with in general, affording more screen real estate for drawing.
Sounds like you've got some work cut out for you, suggesting a specification for node tools and layer grouping, and for Inkscape's graphical user interface.
Lots of improvements on the way, let's not denounce them beforehand.
I'll denounce them beforehand every time someone suggests a combination of an OLE type thing *and* video *and* multipage *and* Javascript framework *and* XCF *and* 3D *and* Python interface *and* immitation of Flash *and especially* dumping the SVG standard that allows me to use Inkscape as a tool to do some pretty cool stuff. How would you like to code all that crap? How would you like to do support on the finished result? Yeah, me neither. It was a horrible idea, as stated.
That next feature you think you don't need might be the best thing that ever happened to your work flow.
Happens all the time. But it happens only when the next feature is part of an incremental improvement policy, carefully designed for simplicity and encapsulation, carefully crafted, and released only when it's ready. However, when it's quickied into the code, especially as part of a laundry list of almost unrelated other features, the only way it improves my work flow is if I move to a superior program after the current one collapses under the weight of its complexity.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Guys,
what if we start a petition on change.org so we can pressure W3C council to give us some status on the SVG 2 spec progress? Is this doable?
I'm just sad to realize that so much effort, organization and time may be discarded in the near future because the SVG 2 spec is not evolving at all.
Is this doable? What are your thoughts on this?
--Victor Westmann
2017-04-22 10:57 GMT-07:00 Donn Ingle <donn.ingle@...155...>:
Your take on my words is bizarre. Be more charitable.
/d
On 22 April 2017 at 18:39, Steve Litt <slitt@...2357...> wrote:
On Sat, 22 Apr 2017 09:21:52 +0100 C R <cajhne@...155...> wrote:
Confining it to specific simplistic use cases based on personal preferences, and calling what you don't personally use "bloat" is ignoring the bigger purpose of inkscape as a professional vector graphics design tool.
Nobody in this thread called anything about Inkscape "bloat", nor said that code related to what they don't use is "bloat". Go back and check the archives. I brought up "bloat" with respect to Firefox.
The "bloat" is not causing the slowness. There is a lot in Inkscape that needs refactoring, and a lot that needs refinement and optimization.
Nobody in this thread said Inkscape is currently bloated. What I said, although not in so many words, is that glomming on the feature list recommended by Donn Ingle would greatly increase its complexity.
We do not need to be tossing out good ideas which are asked for by our professional graphic design users that make Inkscape more useful because some users are content to use it only for laser cutting (as an example).
In that case, the professional graphic design users should prioritize which good ideas are most important, so we don't bury everything and a marching band inside currently good code. And those pro graphic designers should give us some ideas of how to implement those ideas in a way compatible to SVG1, or else brainstorm to come up with an idea of how to implement stuff incompatible with SVG1 within separate executables.
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs,
Oh HELL no. If devs hugely complexify software to the extent that it becomes buggy, slow and incompatible, they ruined the software, and deserve disrespect. It should be noted that nobody in this thread made that accusation about *Inkscape* developers.
I did, however, say that if Donn Ingle's long laundry list of changes were implemented en masse, and especially without regard to the SVG standard, it would result in complexity (a better word for bloat). I stand by that, and suspect that Inkscape developers agree.
and its disrespectful to the design community who need Inkscape to be a fully realised vector graphics production studio.
OK, fine. Why don't you submit a list of improvements to Inkscape, sorted by descending importance, so improvement can be done slowly and steadily, instead of as a free-for-all. Next to each improvement, be sure to fully specify how the improvement would look, what the user interface might feel like, what part of the SVG spec can support it, and perhaps a few suggestions of where it might fit into the existing code.
Hey, I never said Inkscape is perfect. Nobody who has ever done a gradient in Inkscape would make that statement. What I'm saying is it's pretty darn good, so don't break it in pursuit of the "perfect".
No one is suggesting that your use case should be affected. Users who are happy with how Inkscape is will probably notice only that Inkscape is faster,
"Faster" isn't the usual result when a bunch of features are added. There are limits to the wizardry of even the best programmers.
has more useful node tools and layer grouping modes, and is cleaner and easier to work with in general, affording more screen real estate for drawing.
Sounds like you've got some work cut out for you, suggesting a specification for node tools and layer grouping, and for Inkscape's graphical user interface.
Lots of improvements on the way, let's not denounce them beforehand.
I'll denounce them beforehand every time someone suggests a combination of an OLE type thing *and* video *and* multipage *and* Javascript framework *and* XCF *and* 3D *and* Python interface *and* immitation of Flash *and especially* dumping the SVG standard that allows me to use Inkscape as a tool to do some pretty cool stuff. How would you like to code all that crap? How would you like to do support on the finished result? Yeah, me neither. It was a horrible idea, as stated.
That next feature you think you don't need might be the best thing that ever happened to your work flow.
Happens all the time. But it happens only when the next feature is part of an incremental improvement policy, carefully designed for simplicity and encapsulation, carefully crafted, and released only when it's ready. However, when it's quickied into the code, especially as part of a laundry list of almost unrelated other features, the only way it improves my work flow is if I move to a superior program after the current one collapses under the weight of its complexity.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
what if we start a petition on change.org so we can pressure W3C council to give us some status on the SVG 2 spec progress? Is this doable?
I'd sign it, but the problem, according to Tav's articles is that it can never be a standard unless major browser developers (and companies like Adobe) support it. Not sure if a petition will solve that part of the problem.
I'm just sad to realize that so much effort, organization and time may be discarded in the near future because the SVG 2 spec is not evolving at all.
It will (probably) always be the basis for Inkscape's construction file format. There's nothing wrong with the file format itself, and like jpeg, etc. it will continue to be supported and used in current incarnations for the forseeable future. In that regard there's no need to worry. It was not for nothing. Tav and the SVG workgroup has given us a great basis for art done in Inkascape. It's extensible by nature as well, so the work will never be wasted effort.
-C
--Victor Westmann
2017-04-22 10:57 GMT-07:00 Donn Ingle <donn.ingle@...155...>:
Your take on my words is bizarre. Be more charitable.
/d
On 22 April 2017 at 18:39, Steve Litt <slitt@...2357...> wrote:
On Sat, 22 Apr 2017 09:21:52 +0100 C R <cajhne@...155...> wrote:
Confining it to specific simplistic use cases based on personal preferences, and calling what you don't personally use "bloat" is ignoring the bigger purpose of inkscape as a professional vector graphics design tool.
Nobody in this thread called anything about Inkscape "bloat", nor said that code related to what they don't use is "bloat". Go back and check the archives. I brought up "bloat" with respect to Firefox.
The "bloat" is not causing the slowness. There is a lot in Inkscape that needs refactoring, and a lot that needs refinement and optimization.
Nobody in this thread said Inkscape is currently bloated. What I said, although not in so many words, is that glomming on the feature list recommended by Donn Ingle would greatly increase its complexity.
We do not need to be tossing out good ideas which are asked for by our professional graphic design users that make Inkscape more useful because some users are content to use it only for laser cutting (as an example).
In that case, the professional graphic design users should prioritize which good ideas are most important, so we don't bury everything and a marching band inside currently good code. And those pro graphic designers should give us some ideas of how to implement those ideas in a way compatible to SVG1, or else brainstorm to come up with an idea of how to implement stuff incompatible with SVG1 within separate executables.
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs,
Oh HELL no. If devs hugely complexify software to the extent that it becomes buggy, slow and incompatible, they ruined the software, and deserve disrespect. It should be noted that nobody in this thread made that accusation about *Inkscape* developers.
I did, however, say that if Donn Ingle's long laundry list of changes were implemented en masse, and especially without regard to the SVG standard, it would result in complexity (a better word for bloat). I stand by that, and suspect that Inkscape developers agree.
and its disrespectful to the design community who need Inkscape to be a fully realised vector graphics production studio.
OK, fine. Why don't you submit a list of improvements to Inkscape, sorted by descending importance, so improvement can be done slowly and steadily, instead of as a free-for-all. Next to each improvement, be sure to fully specify how the improvement would look, what the user interface might feel like, what part of the SVG spec can support it, and perhaps a few suggestions of where it might fit into the existing code.
Hey, I never said Inkscape is perfect. Nobody who has ever done a gradient in Inkscape would make that statement. What I'm saying is it's pretty darn good, so don't break it in pursuit of the "perfect".
No one is suggesting that your use case should be affected. Users who are happy with how Inkscape is will probably notice only that Inkscape is faster,
"Faster" isn't the usual result when a bunch of features are added. There are limits to the wizardry of even the best programmers.
has more useful node tools and layer grouping modes, and is cleaner and easier to work with in general, affording more screen real estate for drawing.
Sounds like you've got some work cut out for you, suggesting a specification for node tools and layer grouping, and for Inkscape's graphical user interface.
Lots of improvements on the way, let's not denounce them beforehand.
I'll denounce them beforehand every time someone suggests a combination of an OLE type thing *and* video *and* multipage *and* Javascript framework *and* XCF *and* 3D *and* Python interface *and* immitation of Flash *and especially* dumping the SVG standard that allows me to use Inkscape as a tool to do some pretty cool stuff. How would you like to code all that crap? How would you like to do support on the finished result? Yeah, me neither. It was a horrible idea, as stated.
That next feature you think you don't need might be the best thing that ever happened to your work flow.
Happens all the time. But it happens only when the next feature is part of an incremental improvement policy, carefully designed for simplicity and encapsulation, carefully crafted, and released only when it's ready. However, when it's quickied into the code, especially as part of a laundry list of almost unrelated other features, the only way it improves my work flow is if I move to a superior program after the current one collapses under the weight of its complexity.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On 22 April 2017 at 21:13, Victor Westmann <victor.westmann@...155...> wrote:
Guys,
what if we start a petition on change.org so we can pressure W3C council to give us some status on the SVG 2 spec progress? Is this doable?
I'm just sad to realize that so much effort, organization and time may be discarded in the near future because the SVG 2 spec is not evolving at all.
Is this doable? What are your thoughts on this?
I don't know anything about activism, but I'll help any way I can. If a petition is an effective measure, let's go. Perhaps the more knowledgeable members and devs should be involved from the start since they are the ones who form the backbone of Inkscape.
/d
Your take on my words is bizarre. Be more charitable.
fwiw, you have lots of good ideas. I'm not sure why Steve has this burning desire to dismiss the lot of them as if it were one single request. Don't let it discourage you. Most of what you're proposing is already in the works in various stages, or in plans for the future. It is certainly not "crap", and a rather large community of artists and more than a few devs agree with most of your list items. Steve seems to be saying "hey, let's not do that all at once, and make the software too complex!". I think we can let him have that point. What do you think? ;)
-C
On 22 April 2017 at 18:39, Steve Litt <slitt@...2357...> wrote:
On Sat, 22 Apr 2017 09:21:52 +0100 C R <cajhne@...155...> wrote:
Confining it to specific simplistic use cases based on personal preferences, and calling what you don't personally use "bloat" is ignoring the bigger purpose of inkscape as a professional vector graphics design tool.
Nobody in this thread called anything about Inkscape "bloat", nor said that code related to what they don't use is "bloat". Go back and check the archives. I brought up "bloat" with respect to Firefox.
The "bloat" is not causing the slowness. There is a lot in Inkscape that needs refactoring, and a lot that needs refinement and optimization.
Nobody in this thread said Inkscape is currently bloated. What I said, although not in so many words, is that glomming on the feature list recommended by Donn Ingle would greatly increase its complexity.
We do not need to be tossing out good ideas which are asked for by our professional graphic design users that make Inkscape more useful because some users are content to use it only for laser cutting (as an example).
In that case, the professional graphic design users should prioritize which good ideas are most important, so we don't bury everything and a marching band inside currently good code. And those pro graphic designers should give us some ideas of how to implement those ideas in a way compatible to SVG1, or else brainstorm to come up with an idea of how to implement stuff incompatible with SVG1 within separate executables.
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs,
Oh HELL no. If devs hugely complexify software to the extent that it becomes buggy, slow and incompatible, they ruined the software, and deserve disrespect. It should be noted that nobody in this thread made that accusation about *Inkscape* developers.
I did, however, say that if Donn Ingle's long laundry list of changes were implemented en masse, and especially without regard to the SVG standard, it would result in complexity (a better word for bloat). I stand by that, and suspect that Inkscape developers agree.
and its disrespectful to the design community who need Inkscape to be a fully realised vector graphics production studio.
OK, fine. Why don't you submit a list of improvements to Inkscape, sorted by descending importance, so improvement can be done slowly and steadily, instead of as a free-for-all. Next to each improvement, be sure to fully specify how the improvement would look, what the user interface might feel like, what part of the SVG spec can support it, and perhaps a few suggestions of where it might fit into the existing code.
Hey, I never said Inkscape is perfect. Nobody who has ever done a gradient in Inkscape would make that statement. What I'm saying is it's pretty darn good, so don't break it in pursuit of the "perfect".
No one is suggesting that your use case should be affected. Users who are happy with how Inkscape is will probably notice only that Inkscape is faster,
"Faster" isn't the usual result when a bunch of features are added. There are limits to the wizardry of even the best programmers.
has more useful node tools and layer grouping modes, and is cleaner and easier to work with in general, affording more screen real estate for drawing.
Sounds like you've got some work cut out for you, suggesting a specification for node tools and layer grouping, and for Inkscape's graphical user interface.
Lots of improvements on the way, let's not denounce them beforehand.
I'll denounce them beforehand every time someone suggests a combination of an OLE type thing *and* video *and* multipage *and* Javascript framework *and* XCF *and* 3D *and* Python interface *and* immitation of Flash *and especially* dumping the SVG standard that allows me to use Inkscape as a tool to do some pretty cool stuff. How would you like to code all that crap? How would you like to do support on the finished result? Yeah, me neither. It was a horrible idea, as stated.
That next feature you think you don't need might be the best thing that ever happened to your work flow.
Happens all the time. But it happens only when the next feature is part of an incremental improvement policy, carefully designed for simplicity and encapsulation, carefully crafted, and released only when it's ready. However, when it's quickied into the code, especially as part of a laundry list of almost unrelated other features, the only way it improves my work flow is if I move to a superior program after the current one collapses under the weight of its complexity.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On 23 April 2017 at 00:47, C R <cajhne@...155...> wrote:
fwiw, you have lots of good ideas. I'm not sure why Steve has this burning desire to dismiss the lot of them as if it were one single request. Don't let it discourage you. Most of what you're proposing is already in the works in various stages, or in plans for the future. It is certainly not "crap", and a rather large community of artists and more than a few devs agree with most of your list items. Steve seems to be saying "hey, let's not do that all at once, and make the software too complex!". I think we can let him have that point. What do you think? ;)
Yeah, I agree. I'm not about Internet fights! I don't think Steve need worry that I have any weight at all and can add complexity somehow! I was expelled from Hogwarts because my ZX80-wand was too slow! No magic here. :)
I liked your description in this para from a mail up-thread: [my additions/edits]
"
*The whole point of the [OPs] list was that Inkscape needs to grow beyond using SVG as a CONSTRUCTION format. Specifically because there's a lot more we want to do, and unfortunately the world has lost interest in making SVGs better. Nothing done to SVG2 spec affects the SVG1 spec, and nothing done to inkscape's construction file after svg2 is set as the last svg "standard" will affect svg2 after that. The OP was simply saying that the functionality of inkscape should not be limited to things only covered by SVG2, which is already the case (it already contains awesome new features that will not make it into SVG2 [* i.e. mesh gradients]).*"
Which is excellent — and something I didn't really know. I didn't know the mesh gradients were non-standard. That's actually quite exciting because it shows a will to pull away from the bog that the standard has (seems to have) become.
I am aware of the save as standard SVG vs Inkscape SVG option. Yes, it's already quite "fuzzy".
Thanks, /d
Nobody in this thread called anything about Inkscape "bloat", nor said that code related to what they don't use is "bloat". Go back and check the archives. I brought up "bloat" with respect to Firefox.
*sigh* Which was your reply to Donn's comparison of firefox to Inkscape as another example of a program that was good at a lot of different things. Maybe it was not your intention to say Inkscape's new features will lead to Inkscape being bloatware, but it certainly came off that way.
The "bloat" is not causing the slowness. There is a lot in Inkscape that needs refactoring, and a lot that needs refinement and optimization.
Nobody in this thread said Inkscape is currently bloated. What I said, although not in so many words, is that glomming on the feature list recommended by Donn Ingle would greatly increase its complexity.
Some of Donn's stuff is right on the money, and have already been discussed in previous emails and on IRC. If you've got some issues with particular items, that can be discussed. Dismissing someone's personal wishlist wholesale isn't very helpful.
We do not need to be tossing out good ideas which are asked for by our professional graphic design users that make Inkscape more useful because some users are content to use it only for laser cutting (as an example).
In that case, the professional graphic design users should prioritize which good ideas are most important
They do, all the time, in fact. And most of them are written into the roadmap somewhere.
And those pro graphic designers should give us some ideas of how to implement those ideas in a way compatible to SVG1, or else brainstorm to come up with an idea of how to implement stuff incompatible with SVG1 within separate executables.
Uh, no. :) SVG1 is a delivery format for simple vector graphics. SVG2 will eventually become a delivery format as well because it's no longer developed. That's exactly what this thread is about: some users have it in their minds that everything must be somehow crammed into an SVG, and viewable in browser. Well, it's not going to happen. Inkscape will always be able to save/export to SVG1 and SVG2 as a delivery format, and read those formats back in for use in other projects. However, those formats simply don't cover the complete needs of a pro-graphics construction file. We even have mesh gradients now, which is not officially in either spec. Guess we should abandon that too, just because some people like Inkscape the way it is? No... no I think not. :)
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs,
Oh HELL no. If devs hugely complexify software to the extent that it becomes buggy, slow and incompatible, they ruined the software, and deserve disrespect. It should be noted that nobody in this thread made that accusation about *Inkscape* developers.
Except Inkscape IS a complex program. You're saying everything that can not be done in SVG1 should be excluded. Everything else is "bloat", right? Frankly, I don't know what you're trying to say at this point. :)
I did, however, say that if Donn Ingle's long laundry list of changes were implemented en masse, and especially without regard to the SVG standard, it would result in complexity (a better word for bloat).
The whole point of the Donn's list was that Inkscape needs to grow beyond using SVG as a CONSTRUCTION format. Specifically because there's a lot more we want to do, and unfortunately the world has lost interest in making SVGs better. Nothing done to SVG2 spec affects the SVG1 spec, and nothing done to inkscape's construction file after svg2 is set as the last svg "standard" will affect svg2 after that. The OP was simply saying that the functionality of inkscape should not be limited to things only covered by SVG2, which is already the case (it already contains awesome new features that will not make it into SVG2). So I have no idea what you're arguing about. :)
The only real question is: Do we keep calling Inkscape's native construction format called "SVG".
It's already confusing, because you can save a "plain SVG file" and an "inkscape SVG" (non-standard) SVG file, and both have the extension .svg. Changing inkscape's construction file format to something like IVG (Inksape Vector Graphic) would actually help protect the standard svg(1) and svg(2) file formats from the need to include all the new stuff that has already been added and is in the works.
For example, take mesh gradients: If we already saved in IVG format, we wouldn't have issues with users complaining about it not showing up in browser. That's reserved for the SVG standard (which is only a standard if it's accepted by most web browsers). It's specifically because SVG should remain pure that we need another format, which will no doubt continue to be based on SVG with extended options.
So don't worry! SVG is safe. It's not going anywhere, and while we may disagree what should be in Inkscape feature-wise, at least we can agree that standard SVG files should remain usable in their *standardised and agreed upon format*.
Hey, I never said Inkscape is perfect. Nobody who has ever done a gradient in Inkscape would make that statement. What I'm saying is it's pretty darn good, so don't break it in pursuit of the "perfect".
I don't think you need to worry about that. And yes, definitely agree about the gradient banding issues. :)
-C
No one is suggesting that your use case should be affected. Users who are happy with how Inkscape is will probably notice only that Inkscape is faster,
"Faster" isn't the usual result when a bunch of features are added. There are limits to the wizardry of even the best programmers.
has more useful node tools and layer grouping modes, and is cleaner and easier to work with in general, affording more screen real estate for drawing.
Sounds like you've got some work cut out for you, suggesting a specification for node tools and layer grouping, and for Inkscape's graphical user interface.
Lots of improvements on the way, let's not denounce them beforehand.
I'll denounce them beforehand every time someone suggests a combination of an OLE type thing *and* video *and* multipage *and* Javascript framework *and* XCF *and* 3D *and* Python interface *and* immitation of Flash *and especially* dumping the SVG standard that allows me to use Inkscape as a tool to do some pretty cool stuff. How would you like to code all that crap? How would you like to do support on the finished result? Yeah, me neither. It was a horrible idea, as stated.
That next feature you think you don't need might be the best thing that ever happened to your work flow.
Happens all the time. But it happens only when the next feature is part of an incremental improvement policy, carefully designed for simplicity and encapsulation, carefully crafted, and released only when it's ready. However, when it's quickied into the code, especially as part of a laundry list of almost unrelated other features, the only way it improves my work flow is if I move to a superior program after the current one collapses under the weight of its complexity.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On Sat, 22 Apr 2017 23:21:14 +0100 C R <cajhne@...155...> wrote:
Nobody in this thread called anything about Inkscape "bloat", nor said that code related to what they don't use is "bloat". Go back and check the archives. I brought up "bloat" with respect to Firefox.
*sigh* Which was your reply to Donn's comparison of firefox to Inkscape as another example of a program that was good at a lot of different things. Maybe it was not your intention to say Inkscape's new features will lead to Inkscape being bloatware, but it certainly came off that way.
Look back through the archive, and see the context in which I used the word "bloat". But now that you mention it, I'd be surprised if adding everything suggested, quickly and at once, would not add complexity, leading to behavior most folks associate with "bloat".
The "bloat" is not causing the slowness. There is a lot in Inkscape that needs refactoring, and a lot that needs refinement and optimization.
Nobody in this thread said Inkscape is currently bloated. What I said, although not in so many words, is that glomming on the feature list recommended by Donn Ingle would greatly increase its complexity.
Some of Donn's stuff is right on the money, and have already been discussed in previous emails and on IRC.
"Some." Which ones? Heck, I might agree if it weren't presented as a laundry list.
If you've got some issues with particular items, that can be discussed. Dismissing someone's personal wishlist wholesale isn't very helpful.
It *is* helpful, given the manner and lack of prioritization the wishlist was presented. If an attempt was made to implement the whole thing, the Inkscape program would likely suffer badly.
We do not need to be tossing out good ideas which are asked for by our professional graphic design users that make Inkscape more useful because some users are content to use it only for laser cutting (as an example).
In that case, the professional graphic design users should prioritize which good ideas are most important
They do, all the time, in fact. And most of them are written into the roadmap somewhere.
Where? Seeing such a roadmap would be most informative.
And those pro graphic designers should give us some ideas of how to implement those ideas in a way compatible to SVG1, or else brainstorm to come up with an idea of how to implement stuff incompatible with SVG1 within separate executables.
Uh, no. :) SVG1 is a delivery format for simple vector graphics. SVG2 will eventually become a delivery format as well because it's no longer developed.
Then there may be good news. I'm not a C++ guy, but I just downloaded and very quickly scanned some of the Inkscape source. It's about 100K lines of .cpp and about 28K lines of .h, and appears to me to be laid out in a clear, well abstracted way. It's a big program with a lot of stuff because it's a big program that does a lot of stuff, but it seems to me to be laid out logically.
I spent 5 minutes checking out the SVG2 specification. Probably because I know little of the mechanics of image manipulation, I didn't understand what I read, but you and Donn would likely understand more. Once you understand the spec, if the Inkscape developers go along with it, you and Donn could start moving it over to source files, one at a time, that would be read only if #ifdef SVG2CANDREC20160915 or whatever. There would probably have to be some other #ifdef SVG2CANDREC20160915 conditional compiles in existing code, but the idea would be to have your code enabled by #define SVG2CANDREC20160915, and if that's not defined, it should compile to the exact same program it does not. You should also make a program called "graceful_degrade" that removes all version-2-only XML from the finished Inkscape file. I'm more of a C guy than C++, but if you do this, I might help you to a limited degree.
That's exactly what this thread is about: some users have it in their minds that everything must be somehow crammed into an SVG, and viewable in browser.
That's sure my definition of Inkscape, and Inkscape would be much less valuable to me otherwise.
Well, it's not going to happen. Inkscape will always be able to save/export to SVG1 and SVG2 as a delivery format, and read those formats back in for use in other projects.
If those conversions are round trip and pass a diff test on SVG files that have gone several round trips through them, I'll worry less about SVG not being the native format. Otherwise, it's a big worry.
However, those formats simply don't cover the complete needs of a pro-graphics construction file. We even have mesh gradients now, which is not officially in either spec. Guess we should abandon that too, just because some people like Inkscape the way it is? No... no I think not. :)
Not at all. It was defined sanely in a few .h files, I assume implemented sanely in files that could use mesh gradients, and a mesh gradient could be made to gracefully degrade by changing any fill properties using the mesh to something more appropriate.
Please (everyone) stop referring to the hard work and superior features that are being proposed as "bloat". It's disrespectful to the devs,
Oh HELL no. If devs hugely complexify software to the extent that it becomes buggy, slow and incompatible, they ruined the software, and deserve disrespect. It should be noted that nobody in this thread made that accusation about *Inkscape* developers.
Except Inkscape IS a complex program.
It's big and does a lot, but I wouldn't call it complex. From the half hour I've spent looking at the source, it's a very sane and simple way of implementing something so powerful.
You're saying everything that can not be done in SVG1 should be excluded. Everything else is "bloat", right? Frankly, I don't know what you're trying to say at this point. :)
After looking at the program, I think there are ways you guys could start implementing SVG2 features, **one at a time, with heavy testing**. I could help to some degree, and could write documentation.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
On Sat, 2017-04-22 at 20:36 -0400, Steve Litt wrote:
Where? Seeing such a roadmap would be most informative.
Inkscape's roadmap is available on the wiki:
http://wiki.inkscape.org/wiki/index.php/Roadmap
Martin,
On Sat, 22 Apr 2017 20:45:03 -0400 Martin Owens <doctormo@...155...> wrote:
On Sat, 2017-04-22 at 20:36 -0400, Steve Litt wrote:
Where? Seeing such a roadmap would be most informative.
Inkscape's roadmap is available on the wiki:
That looks like a great plan, and (I assume) it's made by the developers knowledgeable in what's already in the software and how difficult each step will be.
About the only thing that raised my eyebrow was the mention of d-bus in 1.4: I hope d-bus is never a hard requirement, and Inkscape always remains init-system agnostic (which means checking libraries for such init-agnosticism).
And it looks like the roadmap will integrate SVG2 features, but keep them in the "inkscape" namespace until SVG2 is in the final stages of adoption. And until SVG2 is widely adopted, the plan is a graceful fallback to 1.1 if requested. Nice!
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
On Sun, 2017-04-23 at 02:53 -0400, Steve Litt wrote:
About the only thing that raised my eyebrow was the mention of d-bus in 1.4: I hope d-bus is never a hard requirement, and Inkscape always remains init-system agnostic (which means checking libraries for such init-agnosticism).
dbus isn't an init system. are you thinking of systemd?
Honestly, dbus is great and should have had more support when we had it. But that's for another day.
Martin,
On Sun, 23 Apr 2017, Martin Owens wrote:
On Sun, 2017-04-23 at 02:53 -0400, Steve Litt wrote:
About the only thing that raised my eyebrow was the mention of d-bus in 1.4: I hope d-bus is never a hard requirement, and Inkscape always remains init-system agnostic (which means checking libraries for such init-agnosticism).
dbus isn't an init system. are you thinking of systemd?
Honestly, dbus is great and should have had more support when we had it. But that's for another day.
what functionality would dbus add to inkscape? If it's so wonderful, does that mean that Inkscape on non-linux systems woudl be crippled? or is it that there would be two ways to do everything that can be done via dbus, one for systems where dbus exist and one for where it doesn't?
David Lang
Dear David Lang,
On Sun, 2017-04-23 at 05:07 -0700, David Lang wrote:
what functionality would dbus add to inkscape? If it's so wonderful, does that mean that Inkscape on non-linux systems woudl be crippled? or is it that there would be two ways to do everything that can be done via dbus, one for systems where dbus exist and one for where it doesn't?
dbus has been working on windows for a while now. (needs more testing, but what doesn't), so Inkscape wouldn't have been crippled.
https://www.freedesktop.org/wiki/Software/dbus/#index6h1
Mostly it added the capacity in inkscape to interact with outside programs. We have our python API (stuff an svg through a pipe), our command line API (stuff an svg through file handles) and our human API (stuff an svg through eyeballs). But dbus is different in how one can interact with Inkscape scalpel like.
So it was a promise to the future of better things. Mostly better extensions, but I understand there are plans to improve the extensions API regardless.
That's in the past.
Martin,
On Sun, 23 Apr 2017 05:07:28 -0700 (PDT) David Lang <david@...2429...> wrote:
On Sun, 23 Apr 2017, Martin Owens wrote:
On Sun, 2017-04-23 at 02:53 -0400, Steve Litt wrote:
About the only thing that raised my eyebrow was the mention of d-bus in 1.4: I hope d-bus is never a hard requirement, and Inkscape always remains init-system agnostic (which means checking libraries for such init-agnosticism).
dbus isn't an init system. are you thinking of systemd?
Honestly, dbus is great and should have had more support when we had it. But that's for another day.
what functionality would dbus add to inkscape? If it's so wonderful, does that mean that Inkscape on non-linux systems woudl be crippled? or is it that there would be two ways to do everything that can be done via dbus, one for systems where dbus exist and one for where it doesn't?
David Lang
Hi David,
That's why I expressed the hope that dbus would never be a *hard* requirement. If Inkscape sees there's no dbus or a malfunctioning dbus on the computer, or if the user declines to use dbus, it should gracefully decline to do anything with dbus.
By the way, it's not just people on Windows, Mac and BSD. I use Linux but try very hard to limit my exposure to dbus. I've had bad experiences with it in the past, and view its architecture as a big traffic circle in which anyone can talk with anyone else, which degrades encapsulation.
But others like dbus, so as long as it's a *soft* requirement, what the heck?
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
On Sun, 23 Apr 2017 07:11:42 -0400 Martin Owens <doctormo@...155...> wrote:
On Sun, 2017-04-23 at 02:53 -0400, Steve Litt wrote:
About the only thing that raised my eyebrow was the mention of d-bus in 1.4: I hope d-bus is never a hard requirement, and Inkscape always remains init-system agnostic (which means checking libraries for such init-agnosticism).
dbus isn't an init system. are you thinking of systemd?
Honestly, dbus is great and should have had more support when we had it. But that's for another day.
Martin,
I should have made two sentences.
Quite apart from dbus, I don't use user applications that care what init system the computer is using. And yes, I personally have a problem with systemd, would never init my computer with it, and if given no other choice would migrate to Mac rather than use systemd. But listen, others like systemd: I'm just saying I hope Inkscape doesn't build in any code such that Inkscape can't run or loses significant capability unless a specific init system, *any* specific init system, is used.
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
On Sun, Apr 23, 2017 at 1:36 AM, Steve Litt <slitt@...2357...> wrote:
On Sat, 22 Apr 2017 23:21:14 +0100 C R <cajhne@...155...> wrote:
Nobody in this thread called anything about Inkscape "bloat", nor said that code related to what they don't use is "bloat". Go back and check the archives. I brought up "bloat" with respect to Firefox.
*sigh* Which was your reply to Donn's comparison of firefox to Inkscape as another example of a program that was good at a lot of different things. Maybe it was not your intention to say Inkscape's new features will lead to Inkscape being bloatware, but it certainly came off that way.
Look back through the archive, and see the context in which I used the word "bloat".
I did.. and I just told you what the context was too... I give up! :)
But now that you mention it, I'd be surprised if adding everything suggested, quickly and at once, would not add complexity, leading to behavior most folks associate with "bloat".
This is where you are assuming that the wishlist was asked to be added "all at once". It's like saying the ocean can't be sailed "all at once". You're right of course, but no one was saying that. :)
"Some." Which ones? Heck, I might agree if it weren't presented as a laundry list.
Again, this is one user's wish-list. It was given just as examples. I don't know why you're still trying to argue over it. It IS a laundry list, given just for the sake of examples of stuff that (might) not be able to be implemented with the current SVG standard. You seem to be the only one taking it as a "doo all this at once" sort of deal.
It *is* helpful, given the manner and lack of prioritization the wishlist was presented. If an attempt was made to implement the whole thing, the Inkscape program would likely suffer badly.
Devs do the prioritisation. Why should users have to prioritise what the devs understand far better on a code level? You are wanting/expecting too much from a user wishlist.
Where? Seeing such a roadmap would be most informative.
Google-foo failing you today? ;) Here's some help: http://lmgtfy.com/?q=inkscape+roadmap
Then there may be good news. I'm not a C++ guy, but I just downloaded *snip*
Great, I recommend to talk with the devs on IRC if you'd like to help. Then you can understand the big picture better. Ranting at a user when they are asking questions because you assume the user wishlist is somehow going to be taken as gospel, and implemented all at once... is silly, but also unhelpful. Calling it "crap" and "a horrible idea" isn't very pleasant, and doesn't make anyone more inclined to agree with your points. :)
You may also want to take a look at our COC : https://inkscape.org/en/community/coc/ It contains useful advice about responding to user requests, and ideas.
User 1: "Cool ideas, but we probably shouldn't try to implement this all at once." User 2: "It's just a list of modifications as an example, that may be outside the SVG scope." User 1: "Ah, nevermind then. Some of those things sound pretty cool." User 2: "Thanks! I'll leave it to the devs to figure out what should be priority."
That's how that part of the conversation should have gone. See the complete difference in tone? Quite a bit more efficient too. :)
That's exactly what this thread is about: some users have it in their minds that everything must be somehow crammed into an SVG, and viewable in browser.
That's sure my definition of Inkscape, and Inkscape would be much less valuable to me otherwise.
This is already not the case. Sorry to disappoint. :)
Well, it's not going to happen. Inkscape will always be able to save/export to SVG1 and SVG2 as a delivery format, and read those formats back in for use in other projects.
If those conversions are round trip and pass a diff test on SVG files that have gone several round trips through them, I'll worry less about SVG not being the native format. Otherwise, it's a big worry.
Of course it would. :) So again, no need to worry. You would only have to worry if you used a non-svg1 feature in your svg1. Inkscape would happily convert it to svg1 for you, but when you read it back in (of course) inkscape is only going to be able to show you the svg1 converted stuff. It can't do otherwise because user construction data is lost. This is why it's useful to have a construction format separate from the delivery format (and why almost all pro graphics programs do).
Not at all. It was defined sanely in a few .h files, I assume implemented sanely in files that could use mesh gradients, and a mesh gradient could be made to gracefully degrade by changing any fill properties using the mesh to something more appropriate.
Possible. The issue is that the standard is not agreed upon yet, and likely will not be because of the lost interest in making svg better by all browsers. Now, if you could save a mesh gradient to svg1 for example, you would use things like control points during the conversion, so when you read it back in, it's a mess.
Except Inkscape IS a complex program.
It's big and does a lot, but I wouldn't call it complex. From the half hour I've spent looking at the source, it's a very sane and simple way of implementing something so powerful.
Yep. I think you can also expect that the awesome minds who made the current incarnation will continue to make it clean and logical in the same way as before.
You're saying everything that can not be done in SVG1 should be excluded. Everything else is "bloat", right? Frankly, I don't know what you're trying to say at this point. :)
After looking at the program, I think there are ways you guys could start implementing SVG2 features, **one at a time, with heavy testing**. I could help to some degree, and could write documentation.
Help is always welcome! Thanks for the offer, and I hope our discussions lead to your involvement with the project. :)
-C
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On Sun, 23 Apr 2017 12:29:52 +0100 C R <cajhne@...155...> wrote:
Then there may be good news. I'm not a C++ guy, but I just downloaded *snip*
Great, I recommend to talk with the devs on IRC if you'd like to help.
Wait a minute. I'm not the guy who wants these changes. You and Donn are. *You two* are the ones who should be volunteering to help. Later in my email I said that if you and Donn implement these changes in a sane way, I'll help you and Donn in some limited ways.
Until you and Donn start writing code, I'm perfectly happy with http://wiki.inkscape.org/wiki/index.php/Roadmap
SteveT
Steve Litt April 2017 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
Wait a minute. I'm not the guy who wants these changes. You and Donn are. *You two* are the ones who should be volunteering to help. Later in my email I said that if you and Donn implement these changes in a sane way, I'll help you and Donn in some limited ways.
Thanks, but I already volunteer a lot of my time to help Inkscape and other FLOSS projects, and you were the one suggesting (several paragraphs worth) of implementation ideas. I thought it was a good opportunity to invite you to contribute. I was not asking for your help, personally, but thanks anyway. :)
It's the policy of the Inkscape project to be encouraging and friendly to all new (and potential) contributors, whether it's code contributions, community building efforts, or any of the other areas the project requests help.
Glad you found the roadmap!
-C
Just using the last message in this thread to add some general comments. Not replying to anything specifically.
From a simple Inkscape user, who can hardly follow technical things, like SVG
standards:
Inkscape is a beautiful thing! And as far as I understand it, SVG is too!
As a simple Inkscape user, I have a hard time understanding why browsers don't want to support SVG (as much as before). There must be some reason why SVG was created. Is that reason moot now, for some reason?
Or there must be some other kind of technology, already in existance, which can take the place of SVG. Because otherwise, if SVG hits the skids (or just SVG2, as the case may be) what's to take its place?
Rhetorical questions, answers not needed.
Granted I've only been involved (in the development side of the community) for the last few years. So when I say "we", it's probably a stretch. But it looks to me like we've come too far as a community, to turn back now.
We should try to find some way to support Amelia and Tav and the others who have been pulling far more than their fair share (at least that's how it sounds to me). Maybe we just need a little bit of a paradigm shift? Not that I know what that might be.
But I know this community is packed with brilliant people!! And I have no doubt that a solution is well within the collective ability of the community :-D
All best, brynn
-----Original Message----- From: C R Sent: Monday, April 24, 2017 2:19 PM To: Inkscape User Community Subject: Re: [Inkscape-user] The SVG blues
Wait a minute. I'm not the guy who wants these changes. You and Donn are. *You two* are the ones who should be volunteering to help. Later in my email I said that if you and Donn implement these changes in a sane way, I'll help you and Donn in some limited ways.
Thanks, but I already volunteer a lot of my time to help Inkscape and other FLOSS projects, and you were the one suggesting (several paragraphs worth) of implementation ideas. I thought it was a good opportunity to invite you to contribute. I was not asking for your help, personally, but thanks anyway. :)
It's the policy of the Inkscape project to be encouraging and friendly to all new (and potential) contributors, whether it's code contributions, community building efforts, or any of the other areas the project requests help.
Glad you found the roadmap!
-C
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
I will note that browser support of SVGs (and by extension of Inkscape's native format) is awesome, and allows some very cool things to be done such as:
http://shapeoko.github.io/Docs/content/tPictures/PS20028-100.svg
(click on the parts list to highlight parts in the diagram)
William
On Wed, Apr 26, 2017 at 7:12 AM, brynn <brynn@...3089...> wrote:
Just using the last message in this thread to add some general comments. Not replying to anything specifically.
From a simple Inkscape user, who can hardly follow technical things, like
SVG standards:
Inkscape is a beautiful thing! And as far as I understand it, SVG is too!
As a simple Inkscape user, I have a hard time understanding why browsers don't want to support SVG (as much as before). There must be some reason why SVG was created. Is that reason moot now, for some reason?
Or there must be some other kind of technology, already in existance, which can take the place of SVG. Because otherwise, if SVG hits the skids (or just SVG2, as the case may be) what's to take its place?
Rhetorical questions, answers not needed.
Granted I've only been involved (in the development side of the community) for the last few years. So when I say "we", it's probably a stretch. But it looks to me like we've come too far as a community, to turn back now.
We should try to find some way to support Amelia and Tav and the others who have been pulling far more than their fair share (at least that's how it sounds to me). Maybe we just need a little bit of a paradigm shift? Not that I know what that might be.
But I know this community is packed with brilliant people!! And I have no doubt that a solution is well within the collective ability of the community :-D
All best, brynn
-----Original Message----- From: C R Sent: Monday, April 24, 2017 2:19 PM To: Inkscape User Community Subject: Re: [Inkscape-user] The SVG blues
Wait a minute. I'm not the guy who wants these changes. You and Donn are. *You two* are the ones who should be volunteering to help. Later in my email I said that if you and Donn implement these changes in a sane way, I'll help you and Donn in some limited ways.
Thanks, but I already volunteer a lot of my time to help Inkscape and other FLOSS projects, and you were the one suggesting (several paragraphs worth) of implementation ideas. I thought it was a good opportunity to invite you to contribute. I was not asking for your help, personally, but thanks anyway. :)
It's the policy of the Inkscape project to be encouraging and friendly to all new (and potential) contributors, whether it's code contributions, community building efforts, or any of the other areas the project requests help.
Glad you found the roadmap!
-C
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Dear all,
I'm not at all an SVG specialist, and I'm a rather passive user of Inkscape (though I like it a lot). But I work in data-visualization, and I draw SVG stuff in browsers all day long (like this : https://www.elephanttrust.org/visualization/). I'm using a javascript library called D3.js (https://d3js.org/), and though it also works for other types of browser graphics, like HTML5 canvas, it was build to make heavy use of SVG. I don't have data to support this but it's practically the number one library for interactive data-visualization on the web right now. It's still being actively developed. So SVG is definitely not dead on the web.
By the way, I read somewhere in this thread that we needed good examples of professional work make with Inkscape. I know that there's a growing dissatisfaction with Adobe's (pricing) policy, and some influential people in data-vis (Alberto Cairo for instance) would be happy (I think) to make the move to Inkscape. But Inkscape lacks Illustrator's very handy data-visualization tool, which allows users to very easily import spreadsheets and draw simple data-vis primitives (like bar and line charts, scatter plots, etc.). I don't know who could help me with this, but I'd be happy to pay for (part of) the development and to help with the grammar of graphics. If Inkscape had this tool I'm pretty sure that there could be lots of quality data-vis examples for the "made with Inkscape" gallery.
Cheers,
Pierre.
2017-04-26 14:21 GMT+02:00 William Adams <will.adams@...3026...>:
I will note that browser support of SVGs (and by extension of Inkscape's native format) is awesome, and allows some very cool things to be done such as:
http://shapeoko.github.io/Docs/content/tPictures/PS20028-100.svg
(click on the parts list to highlight parts in the diagram)
William
On Wed, Apr 26, 2017 at 7:12 AM, brynn <brynn@...3089...> wrote:
Just using the last message in this thread to add some general comments. Not replying to anything specifically.
From a simple Inkscape user, who can hardly follow technical things,
like SVG standards:
Inkscape is a beautiful thing! And as far as I understand it, SVG is too!
As a simple Inkscape user, I have a hard time understanding why browsers don't want to support SVG (as much as before). There must be some reason why SVG was created. Is that reason moot now, for some reason?
Or there must be some other kind of technology, already in existance, which can take the place of SVG. Because otherwise, if SVG hits the skids (or just SVG2, as the case may be) what's to take its place?
Rhetorical questions, answers not needed.
Granted I've only been involved (in the development side of the community) for the last few years. So when I say "we", it's probably a stretch. But it looks to me like we've come too far as a community, to turn back now.
We should try to find some way to support Amelia and Tav and the others who have been pulling far more than their fair share (at least that's how it sounds to me). Maybe we just need a little bit of a paradigm shift? Not that I know what that might be.
But I know this community is packed with brilliant people!! And I have no doubt that a solution is well within the collective ability of the community :-D
All best, brynn
-----Original Message----- From: C R Sent: Monday, April 24, 2017 2:19 PM To: Inkscape User Community Subject: Re: [Inkscape-user] The SVG blues
Wait a minute. I'm not the guy who wants these changes. You and Donn are. *You two* are the ones who should be volunteering to help. Later in my email I said that if you and Donn implement these changes in a sane way, I'll help you and Donn in some limited ways.
Thanks, but I already volunteer a lot of my time to help Inkscape and other FLOSS projects, and you were the one suggesting (several paragraphs worth) of implementation ideas. I thought it was a good opportunity to invite you to contribute. I was not asking for your help, personally, but thanks anyway. :)
It's the policy of the Inkscape project to be encouraging and friendly to all new (and potential) contributors, whether it's code contributions, community building efforts, or any of the other areas the project requests help.
Glad you found the roadmap!
-C
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Dear Pierre,
I'd consider myself to be experienced with d3 (both nv and vanilla) as well as alternatives such as chartist.
I'd actually say that d3 is a fairly messy svg generator, the developers don't seem to have been well versed with svg capabilities, or at least they do things in expensive js ways with tons of elements instead of letting svg do the heavy lifting.
Chartist on the other hand has fewer animations and transitions, doesn't do any of the data processing that d3 does for you, but the base for line and bar charts is super solid and the plugins are incredibly easy to write and pile up together.
I'm also a freelance contractor and I work on Inkscape. Maybe we can set something up? I have a few ideas for how we might get more charts into inkscape, but I should get more details from your directly if you want to do something with me for hire.
(sending this to list, because contracting developers to work on inkscape is a thing people can do)
Best Regards, Martin Owens
On Wed, 2017-04-26 at 16:13 +0200, Pierre Massat wrote:
Dear all,
I'm not at all an SVG specialist, and I'm a rather passive user of Inkscape (though I like it a lot). But I work in data-visualization, and I draw SVG stuff in browsers all day long (like this : https://ww w.elephanttrust.org/visualization/). I'm using a javascript library called D3.js (https://d3js.org/), and though it also works for other types of browser graphics, like HTML5 canvas, it was build to make heavy use of SVG. I don't have data to support this but it's practically the number one library for interactive data-visualization on the web right now. It's still being actively developed. So SVG is definitely not dead on the web.
By the way, I read somewhere in this thread that we needed good examples of professional work make with Inkscape. I know that there's a growing dissatisfaction with Adobe's (pricing) policy, and some influential people in data-vis (Alberto Cairo for instance) would be happy (I think) to make the move to Inkscape. But Inkscape lacks Illustrator's very handy data-visualization tool, which allows users to very easily import spreadsheets and draw simple data-vis primitives (like bar and line charts, scatter plots, etc.). I don't know who could help me with this, but I'd be happy to pay for (part of) the development and to help with the grammar of graphics. If Inkscape had this tool I'm pretty sure that there could be lots of quality data-vis examples for the "made with Inkscape" gallery.
Cheers,
Pierre.
2017-04-26 14:21 GMT+02:00 William Adams <will.adams@...3026...>:
I will note that browser support of SVGs (and by extension of Inkscape's native format) is awesome, and allows some very cool things to be done such as:
http://shapeoko.github.io/Docs/content/tPictures/PS20028-100.svg
(click on the parts list to highlight parts in the diagram)
William
On Wed, Apr 26, 2017 at 7:12 AM, brynn <brynn@...3089...> wrote:
Just using the last message in this thread to add some general comments. Not replying to anything specifically.
From a simple Inkscape user, who can hardly follow technical
things, like SVG standards:
Inkscape is a beautiful thing! And as far as I understand it, SVG is too!
As a simple Inkscape user, I have a hard time understanding why browsers don't want to support SVG (as much as before). There must be some reason why SVG was created. Is that reason moot now, for some reason?
Or there must be some other kind of technology, already in existance, which can take the place of SVG. Because otherwise, if SVG hits the skids (or just SVG2, as the case may be) what's to take its place?
Rhetorical questions, answers not needed.
Granted I've only been involved (in the development side of the community) for the last few years. So when I say "we", it's probably a stretch. But it looks to me like we've come too far as a community, to turn back now.
We should try to find some way to support Amelia and Tav and the others who have been pulling far more than their fair share (at least that's how it sounds to me). Maybe we just need a little bit of a paradigm shift? Not that I know what that might be.
But I know this community is packed with brilliant people!! And I have no doubt that a solution is well within the collective ability of the community :-D
All best, brynn
-----Original Message----- From: C R Sent: Monday, April 24, 2017 2:19 PM To: Inkscape User Community Subject: Re: [Inkscape-user] The SVG blues
Wait a minute. I'm not the guy who wants these changes. You and
Donn
are. *You two* are the ones who should be volunteering to help.
Later in
my email I said that if you and Donn implement these changes in
a sane
way, I'll help you and Donn in some limited ways.
Thanks, but I already volunteer a lot of my time to help Inkscape and other FLOSS projects, and you were the one suggesting (several paragraphs worth) of implementation ideas. I thought it was a good opportunity to invite you to contribute. I was not asking for your help, personally, but thanks anyway. :)
It's the policy of the Inkscape project to be encouraging and friendly to all new (and potential) contributors, whether it's code contributions, community building efforts, or any of the other areas the project requests help.
Glad you found the roadmap!
-C
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On 26 April 2017 at 13:12, brynn <brynn@...3089...> wrote:
We should try to find some way to support Amelia and Tav and the others who have been pulling far more than their fair share (at least that's how it sounds to me). Maybe we just need a little bit of a paradigm shift? Not that I know what that might be.
But I know this community is packed with brilliant people!! And I have no doubt that a solution is well within the collective ability of the community :-D
I know Patreon seems to work quite well for Youtubers (American ones, at least). Perhaps something crowd-sourcey can keep a gang of four or five SVG minds pulsing in a corner of the world, keeping the libre graphics hopes alive. :)
/d
On Sat, 2017-04-22 at 23:21 +0100, C R wrote:
Uh, no. :) SVG1 is a delivery format for simple vector graphics. SVG2 will eventually become a delivery format as well because it's no longer developed. That's exactly what this thread is about: some users have it in their minds that everything must be somehow crammed into an SVG, and viewable in browser. Well, it's not going to happen. Inkscape will always be able to save/export to SVG1 and SVG2 as a delivery format, and read those formats back in for use in other projects. However, those formats simply don't cover the complete needs of a pro-graphics construction file. We even have mesh gradients now, which is not officially in either spec. Guess we should abandon that too, just because some people like Inkscape the way it is? No... no I think not. :)
SVG is a comprehensive document format, a standard.
If we extend the format, then it will only be with the intention of extending svg as a format. The reason why there is no InkscapeVectorFormat file, is because we're not going to create the impression that improvements and additions we make are just for us.
The ideal situation to be in, is one where we make an addition and then browsers, command line tools, other art tools, make the decision that what we offer has some merit and they implement it too.
Then when it comes time to set the standard, these well worn extensions are incorporated into the standard.
This is what happened with HTML5, and I suspect SVG2 is very much our XHTML2, with very good intentions, but very little to show for it. Many of the items that would be great for our users were vetoed as we went along. What we have had is vendors who couldn't decide what svg should be and where they could subset their support appropriately.
So are we going to give up on SVG? No. Are we going to stop standardisation and stop trying to convince other teams that svg+ is a good way forwards? I really hope not.
I'll give you a very small micro example. The animation tool AniGen.org uses Inkscape's layer attribute to designate layers. It's not something that svg has, but it's something that tools choose to support because Inkscape is important and moves things forward well.
Also AniGen is why inkscape shouldn't do animation ;-) but we'll save that one for the other heated debate.
Best Regards, Martin Owens
Thanks for the level-headed email Martin.
What do you think about the two articles (Tav's and Amelia's)? http://codepen.io/AmeliaBR/post/me-and-svg http://tavmjong.free.fr/svg2_status.html
Is there something to the notion that SVG2+ may never happen, or be so tenuous that it takes years?
I guess I am stuck on this conspiracy theory, which is probably wrong (my bias):
1. SVG is the standard. 2. Artists seek various features in Inkscape. 3. Dev say, "It's not in the standard. Influence that." 4. The standard says, "Not now. Not yet." 5. Adobe and MS and Apple have a coffee break and say, "Hell, suckers. Never is when they can have it!" Muhaha. 6. Artists and devs wait. 7. Cobwebs grow as the standard decays further by sheer reluctance of important members to participate, or by voodoo market forces.
I don't have evidence, but the shape of graphic tools in Linux-land (my O/S pov) is primitive. I have to ask why we can't do the few essential things (like abstract-out symbols/clones and palettes - the basic efficiency stuff) after so many years?
/d
On 23 April 2017 at 04:07, Martin Owens <doctormo@...155...> wrote:
On Sat, 2017-04-22 at 23:21 +0100, C R wrote:
Uh, no. :) SVG1 is a delivery format for simple vector graphics. SVG2 will eventually become a delivery format as well because it's no longer developed. That's exactly what this thread is about: some users have it in their minds that everything must be somehow crammed into an SVG, and viewable in browser. Well, it's not going to happen. Inkscape will always be able to save/export to SVG1 and SVG2 as a delivery format, and read those formats back in for use in other projects. However, those formats simply don't cover the complete needs of a pro-graphics construction file. We even have mesh gradients now, which is not officially in either spec. Guess we should abandon that too, just because some people like Inkscape the way it is? No... no I think not. :)
SVG is a comprehensive document format, a standard.
If we extend the format, then it will only be with the intention of extending svg as a format. The reason why there is no InkscapeVectorFormat file, is because we're not going to create the impression that improvements and additions we make are just for us.
The ideal situation to be in, is one where we make an addition and then browsers, command line tools, other art tools, make the decision that what we offer has some merit and they implement it too.
Then when it comes time to set the standard, these well worn extensions are incorporated into the standard.
This is what happened with HTML5, and I suspect SVG2 is very much our XHTML2, with very good intentions, but very little to show for it. Many of the items that would be great for our users were vetoed as we went along. What we have had is vendors who couldn't decide what svg should be and where they could subset their support appropriately.
So are we going to give up on SVG? No. Are we going to stop standardisation and stop trying to convince other teams that svg+ is a good way forwards? I really hope not.
I'll give you a very small micro example. The animation tool AniGen.org uses Inkscape's layer attribute to designate layers. It's not something that svg has, but it's something that tools choose to support because Inkscape is important and moves things forward well.
Also AniGen is why inkscape shouldn't do animation ;-) but we'll save that one for the other heated debate.
Best Regards, Martin Owens
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On Sun, 2017-04-23 at 11:54 +0200, Donn Ingle wrote:
Thanks for the level-headed email Martin.
What do you think about the two articles (Tav's and Amelia's)? http://codepen.io/AmeliaBR/post/me-and-svg http://tavmjong.free.fr/svg2_status.html
Is there something to the notion that SVG2+ may never happen, or be so tenuous that it takes years?
This is really something that Tav can delve into far more than I can.
From other standards issues like xhtml, the perspective is that
software code beats yak yak, so pushing features forwards is a possible strategy to improve svg for svg2.1 or whatever comes next.
I don't have evidence, but the shape of graphic tools in Linux-land (my O/S pov) is primitive. I have to ask why we can't do the few essential things (like abstract-out symbols/clones and palettes - the basic efficiency stuff) after so many years?
That's an investment problem, not a standards problem. Most of the issues we have (the big ones anyway) are not sitting here waiting for svg, they're waiting for developers with time/money to work on them.
Take CMYK, svg has supported cmyk for a long time (in that you can specify colours as cmyk data) but Inkscape's capacity to load, save and then export those colours to pdf has been slow to realise.
I hope this adds something, but I'm not an expert really.
Best Regards, Martin Owens
On 23 April 2017 at 17:35, Martin Owens <doctormo@...155...> wrote:
Is there something to the notion that SVG2+ may never happen, or be so tenuous that it takes years?
This is really something that Tav can delve into far more than I can.
Agreed.
I don't have evidence, but the shape of graphic tools in Linux-land
(my O/S pov) is primitive. I have to ask why we can't do the few essential things (like abstract-out symbols/clones and palettes - the basic efficiency stuff) after so many years?
That's an investment problem, not a standards problem. Most of the issues we have (the big ones anyway) are not sitting here waiting for svg, they're waiting for developers with time/money to work on them.
Take CMYK, svg has supported cmyk for a long time (in that you can specify colours as cmyk data) but Inkscape's capacity to load, save and then export those colours to pdf has been slow to realise.
I hope this adds something, but I'm not an expert really.
Fair enough. Thank you.
/d
I mean that Freehand, for e.g., *existed*. What it did was thus not fiction. It was doing it so well in the 90's on Windows 98 on computers that sucked.
In other words, we are not limited by what O/Ss can do. Nor by what C++ (etc.) can do. Nor by what the various GUIs can do. We are limited by 1) legal and patent threats and 2) A small work force of unpaid volunteers, but mostly by 3) Overly conservative slavish devotion to SVG standards.
On point 3 I feel SVG has gotten to a great place, but it took so long. Along with this note of alarm sounded by respected members of the SVG and Inkscape community, perhaps it's time to reboot goals?
We can take all the holes in the libre graphics software and match them to the code required and rank them. Then we can grow SVG or start some new idea. And from that perhaps Inkscape will benefit vastly, and all of us too.
/d
On 22 April 2017 at 09:06, David Lang <david@...2429...> wrote:
On Sat, 22 Apr 2017, Donn Ingle wrote:
I know its not impossible to have software as good as Freehand or Flash was, years ago, on much slower pcs - because they existed.
wordstar worked on 8 bit processors, that doesn't mean that inkscape should try to do the job that wordstar was written for.
Freehand and Flash don't do the job that inkscape does, don't try to convert inkscape to do the job that they were written to do.
David Lang
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
participants (12)
-
Abrolag -
Arlo Barnes -
brynn -
C R -
David Lang -
Donn Ingle -
Gary Hawkins -
Martin Owens -
Pierre Massat -
Steve Litt -
Victor Westmann -
William Adams