Hi folks don't you think in the free (as in freedom) and opensource space that we should move forward and surpass the SVG format with something more generic?
SVG and Inkscape are great but from my point of view they suffer tremendously their web oriented roots. I think we should have an evolution, another XML format more generic able to overcome SVG limits while keeps compatibility besides handlig the text not only as CSS but also as Postscript, multiple spaces colors and spot colors, multi artboards and pages, etc.
SVG is designed to be handled by a web browser while we would need another format to fill designer needs from print to web...
Inkscape's SVG roots are pretty deep. The project even spends some of it's money sending a developer to the W3C working group to continue developing the SVG specification. And you are right that the project has been rebuffed by web browsers that did not want to support things in SVG 2.0 that editors like Inkscape would have liked. But it's also true that SVG being an xml format is extendable already and technically Inkscape already operates it's own SVG+Inkscape format.
A good example is guides. Guides aren't in the SVG specification, and they won't be rendered by any web browser. But we still have them.
What kinds of functionality do you need to get to that might require SVg itself to be removed?
Hi folks don't you think in the free (as in freedom) and opensource space that we should move forward and surpass the SVG format with something more generic?
SVG and Inkscape are great but from my point of view they suffer tremendously their web oriented roots. I think we should have an evolution, another XML format more generic able to overcome SVG limits while keeps compatibility besides handlig the text not only as CSS but also as Postscript, multiple spaces colors and spot colors, multi artboards and pages, etc.
SVG is designed to be handled by a web browser while we would need another format to fill designer needs from print to web...
What do you think about it?
Hi Gnuserland,
Inkscape's SVG roots are pretty deep. The project even spends some of it's money sending a developer to the W3C working group to continue developing the SVG specification. And you are right that the project has been rebuffed by web browsers that did not want to support things in SVG 2.0 that editors like Inkscape would have liked. But it's also true that SVG being an xml format is extendable already and technically Inkscape already operates it's own SVG+Inkscape format.
A good example is guides. Guides aren't in the SVG specification, and they won't be rendered by any web browser. But we still have them.
What kinds of functionality do you need to get to that might require SVg itself to be removed?