Discussion:
[Inkscape-user] The SVG blues
Donn Ingle
2017-04-21 14:06:24 UTC
Permalink
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
William Adams
2017-04-21 14:29:34 UTC
Permalink
I'd be fine with Inkscape for graphic design use if it would just write out
a CMYK PDF w/o jumping through hoops.
Post by Donn Ingle
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Martin Owens
2017-04-21 15:39:54 UTC
Permalink
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.
Post by Donn Ingle
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
C R
2017-04-21 15:53:58 UTC
Permalink
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
Post by Martin Owens
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.
Post by Donn Ingle
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Gary Hawkins
2017-04-21 16:24:10 UTC
Permalink
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
C R
2017-04-21 16:36:02 UTC
Permalink
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.
Post by Gary Hawkins
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Gary Hawkins
2017-04-21 17:31:14 UTC
Permalink
good to know, thanks
Post by C R
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.
Martin Owens
2017-04-21 17:57:27 UTC
Permalink
Post by Gary Hawkins
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 
Abrolag
2017-04-21 18:11:23 UTC
Permalink
On Fri, 21 Apr 2017 13:57:27 -0400
Post by Martin Owens
Post by Gary Hawkins
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
C R
2017-04-21 18:20:33 UTC
Permalink
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. :)
Post by Abrolag
On Fri, 21 Apr 2017 13:57:27 -0400
Post by Martin Owens
Post by Gary Hawkins
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Donn Ingle
2017-04-21 18:52:04 UTC
Permalink
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
Post by C R
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. :)
Post by Abrolag
On Fri, 21 Apr 2017 13:57:27 -0400
Post by Martin Owens
Post by Gary Hawkins
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Martin Owens
2017-04-21 19:16:44 UTC
Permalink
Post by Donn Ingle
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,
C R
2017-04-21 19:44:21 UTC
Permalink
Does a dog bunk bed count? :D
Post by Martin Owens
Post by Donn Ingle
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Donn Ingle
2017-04-21 20:00:58 UTC
Permalink
Ha. Yes! It houses many fleas. :

/d
Post by C R
Does a dog bunk bed count? :D
Post by Martin Owens
Post by Donn Ingle
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Arlo Barnes
2017-04-21 17:39:43 UTC
Permalink
Post by C R
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
Post by C R
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,
Post by C R
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
Donn Ingle
2017-04-21 18:50:19 UTC
Permalink
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
Post by Martin Owens
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.
Post by Donn Ingle
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Steve Litt
2017-04-21 19:26:58 UTC
Permalink
On Fri, 21 Apr 2017 16:06:24 +0200
Post by Donn Ingle
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.
Post by Donn Ingle
*
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.
Post by Donn Ingle
­— and export to multi-page PDFs.
LaTeX
Post by Donn Ingle
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.
Post by Donn Ingle
Animation time lines.
Sounds kind of niche to me, considering that SVG1 is for images
Post by Donn Ingle
Output to gif,
convert test.svg test.gif
Post by Donn Ingle
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-portfolios
Post by Donn Ingle
js framework too.
Why?
Post by Donn Ingle
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.
Post by Donn Ingle
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.
Post by Donn Ingle
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?
Post by Donn Ingle
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.
Post by Donn Ingle
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
Donn Ingle
2017-04-21 20:49:23 UTC
Permalink
Post by Steve Litt
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.
Post by Steve Litt
"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.
Post by Steve Litt
Post by Donn Ingle
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.
Post by Steve Litt
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
Abrolag
2017-04-21 21:07:17 UTC
Permalink
On Fri, 21 Apr 2017 22:49:23 +0200
Post by Donn Ingle
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
Donn Ingle
2017-04-21 21:23:00 UTC
Permalink
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
Post by Abrolag
On Fri, 21 Apr 2017 22:49:23 +0200
Post by Donn Ingle
I get it, and here's the thing: SVG, it's in serious trouble; fatal
trouble
Post by Donn Ingle
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Steve Litt
2017-04-22 05:57:50 UTC
Permalink
On Fri, 21 Apr 2017 22:07:17 +0100
Post by Abrolag
On Fri, 21 Apr 2017 22:49:23 +0200
Post by Donn Ingle
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
Donn Ingle
2017-04-22 06:33:09 UTC
Permalink
On 22 Apr 2017 07:59, "Steve Litt" <***@troubleshooters.com> 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
Steve Litt
2017-04-22 05:42:22 UTC
Permalink
On Fri, 21 Apr 2017 22:49:23 +0200
Post by Donn Ingle
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
Donn Ingle
2017-04-22 06:49:33 UTC
Permalink
On 22 Apr 2017 07:44, "Steve Litt" <***@troubleshooters.com> wrote:

On Fri, 21 Apr 2017 22:49:23 +0200
Post by Donn Ingle
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
David Lang
2017-04-22 07:06:13 UTC
Permalink
Post by Donn Ingle
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
C R
2017-04-22 08:21:52 UTC
Permalink
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
Post by David Lang
Post by Donn Ingle
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Donn Ingle
2017-04-22 10:21:04 UTC
Permalink
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
Post by C R
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
Post by David Lang
Post by Donn Ingle
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Abrolag
2017-04-22 12:43:52 UTC
Permalink
On Sat, 22 Apr 2017 12:21:04 +0200
Post by Donn Ingle
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!
--
W J G
Donn Ingle
2017-04-22 12:50:58 UTC
Permalink
Post by Abrolag
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
David Lang
2017-04-22 12:56:53 UTC
Permalink
Post by Donn Ingle
Post by Abrolag
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
Donn Ingle
2017-04-22 13:18:53 UTC
Permalink
Post by David Lang
Post by Donn Ingle
Post by Abrolag
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
David Lang
2017-04-22 13:31:42 UTC
Permalink
Post by Donn Ingle
Post by David Lang
Post by Donn Ingle
Post by Abrolag
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.
Donn Ingle
2017-04-22 14:16:07 UTC
Permalink
I don't know what you are trying to say.

/d
Post by Donn Ingle
Post by David Lang
Post by Donn Ingle
Post by Abrolag
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
Post by Donn Ingle
Post by David Lang
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
David Lang
2017-04-22 12:24:21 UTC
Permalink
Post by C R
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
Donn Ingle
2017-04-22 12:42:59 UTC
Permalink
Post by David Lang
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
David Lang
2017-04-22 12:55:17 UTC
Permalink
Post by Donn Ingle
Post by David Lang
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.
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"?
Post by Donn Ingle
*and* take the chance to update
Inkscape (at least) so that its many design holes are filled.
updating Inkscape can happen regardless.
Post by Donn Ingle
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
Donn Ingle
2017-04-22 13:13:06 UTC
Permalink
Post by David Lang
Post by Donn Ingle
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.
Post by David Lang
Post by Donn Ingle
*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.)
Post by David Lang
Post by Donn Ingle
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.
Post by David Lang
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.
Post by David Lang
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
Steve Litt
2017-04-22 16:39:49 UTC
Permalink
On Sat, 22 Apr 2017 09:21:52 +0100
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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".
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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
Donn Ingle
2017-04-22 17:57:24 UTC
Permalink
Your take on my words is bizarre. Be more charitable.

/d
Post by Steve Litt
On Sat, 22 Apr 2017 09:21:52 +0100
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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".
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Victor Westmann
2017-04-22 19:13:49 UTC
Permalink
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
Post by Donn Ingle
Your take on my words is bizarre. Be more charitable.
/d
Post by Steve Litt
On Sat, 22 Apr 2017 09:21:52 +0100
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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".
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
C R
2017-04-22 22:54:10 UTC
Permalink
Post by Victor Westmann
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.
Post by Victor Westmann
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
Post by Victor Westmann
--Victor Westmann
Post by Donn Ingle
Your take on my words is bizarre. Be more charitable.
/d
Post by Steve Litt
On Sat, 22 Apr 2017 09:21:52 +0100
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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".
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Donn Ingle
2017-04-23 09:03:16 UTC
Permalink
Post by Victor Westmann
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
C R
2017-04-22 22:47:59 UTC
Permalink
Post by Donn Ingle
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
Post by Donn Ingle
Post by Steve Litt
On Sat, 22 Apr 2017 09:21:52 +0100
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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".
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Donn Ingle
2017-04-23 09:17:15 UTC
Permalink
Post by C R
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
C R
2017-04-22 22:21:14 UTC
Permalink
Post by Steve Litt
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.
Post by Steve Litt
Post by C R
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.
Post by Steve Litt
Post by C R
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.
Post by Steve Litt
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. :)
Post by Steve Litt
Post by C R
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. :)
Post by Steve Litt
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*.
Post by Steve Litt
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
Post by Steve Litt
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Steve Litt
2017-04-23 00:36:40 UTC
Permalink
On Sat, 22 Apr 2017 23:21:14 +0100
Post by C R
Post by Steve Litt
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".
Post by C R
Post by Steve Litt
Post by C R
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.
Post by C R
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.
Post by C R
Post by Steve Litt
Post by C R
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.
Post by C R
Post by Steve Litt
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.
Post by C R
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.
Post by C R
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.
Post by C R
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.
Post by C R
Post by Steve Litt
Post by C R
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.
Post by C R
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
Martin Owens
2017-04-23 00:45:03 UTC
Permalink
Post by Steve Litt
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,
Steve Litt
2017-04-23 06:53:38 UTC
Permalink
On Sat, 22 Apr 2017 20:45:03 -0400
Post by Martin Owens
Post by Steve Litt
Where? Seeing such a roadmap would be most informative.
http://wiki.inkscape.org/wiki/index.php/Roadmap
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
Martin Owens
2017-04-23 11:11:42 UTC
Permalink
Post by Steve Litt
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,
David Lang
2017-04-23 12:07:28 UTC
Permalink
Post by Martin Owens
Post by Steve Litt
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
Martin Owens
2017-04-23 15:22:27 UTC
Permalink
Dear David Lang,
Post by David Lang
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,
Steve Litt
2017-04-23 22:17:10 UTC
Permalink
On Sun, 23 Apr 2017 05:07:28 -0700 (PDT)
Post by David Lang
Post by Martin Owens
Post by Steve Litt
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
Steve Litt
2017-04-23 22:24:09 UTC
Permalink
On Sun, 23 Apr 2017 07:11:42 -0400
Post by Martin Owens
Post by Steve Litt
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
C R
2017-04-23 11:29:52 UTC
Permalink
Post by Steve Litt
On Sat, 22 Apr 2017 23:21:14 +0100
Post by C R
Post by Steve Litt
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! :)
Post by Steve Litt
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. :)
Post by Steve Litt
"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.
Post by Steve Litt
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.
Post by Steve Litt
Where? Seeing such a roadmap would be most informative.
Google-foo failing you today? ;)
Here's some help:
http://lmgtfy.com/?q=inkscape+roadmap
Post by Steve Litt
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. :)
Post by Steve Litt
Post by C R
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. :)
Post by Steve Litt
Post by C R
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).
Post by Steve Litt
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.
Post by Steve Litt
Post by C R
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.
Post by Steve Litt
Post by C R
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
Post by Steve Litt
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Steve Litt
2017-04-23 22:13:08 UTC
Permalink
On Sun, 23 Apr 2017 12:29:52 +0100
Post by C R
Post by Steve Litt
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
C R
2017-04-24 20:19:02 UTC
Permalink
Post by Steve Litt
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
brynn
2017-04-26 11:12:37 UTC
Permalink
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-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-user
William Adams
2017-04-26 12:21:29 UTC
Permalink
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
Post by brynn
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
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Pierre Massat
2017-04-26 14:13:45 UTC
Permalink
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.
Post by William Adams
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
http://shapeoko.github.io/Docs/content/tPictures/PS20028-100.svg
(click on the parts list to highlight parts in the diagram)
William
Post by brynn
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Martin Owens
2017-04-26 14:53:22 UTC
Permalink
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
Post by Pierre Massat
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.
Post by William Adams
I will note that browser support of SVGs (and by extension of
Inkscape's native format) is awesome, and allows some very cool
http://shapeoko.github.io/Docs/content/tPictures/PS20028-100.svg
(click on the parts list to highlight parts in the diagram)
William
Post by brynn
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
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Donn Ingle
2017-04-26 12:54:42 UTC
Permalink
Post by brynn
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
Martin Owens
2017-04-23 02:07:30 UTC
Permalink
Post by C R
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
Donn Ingle
2017-04-23 09:54:52 UTC
Permalink
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
Post by Martin Owens
Post by C R
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Martin Owens
2017-04-23 15:35:03 UTC
Permalink
Post by Donn Ingle
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.
Post by Donn Ingle
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
Donn Ingle
2017-04-23 18:08:40 UTC
Permalink
Post by Martin Owens
Post by Donn Ingle
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.
Post by Martin Owens
I don't have evidence, but the shape of graphic tools in Linux-land
Post by Donn Ingle
(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
Donn Ingle
2017-04-22 10:36:52 UTC
Permalink
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
Post by David Lang
Post by Donn Ingle
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
https://lists.sourceforge.net/lists/listinfo/inkscape-user
Loading...