The little bit I've used Inkscape (usually just when I didn't have access to my work computer), I've been frustrated (especially) with the way things save. Especially if I try to export to PDF, I lose text information and apparently everything on a given layer just becomes a big group. I didn't look into the documentation, but I imagine this has to do with limitation in how Inkscape deals with these sorts of elements compared to PDFs. Or maybe whomever made the exporter didn't bother make a big affair of the feature, which is understandable.
Anyhows, I got to thinking about the SVG format, which being XML should be infinitely expandable, but coming down to practice, if the file has to be renderable according to the set standards, I have to wonder what sorts of features cannot be added without killing native Plain SVG compatibility. In another thread I proposed adding variable width stroke, but I'm not sure how that would be handled. Would the outline instead be a separate path with additional XML information defining the path as being exclusively controlled by the width tool? Seems awkward. I'm just curious if SVG could cause problems in the future, or if the XML bit should be expandable enough to allow any unforeseen features.
SVG limitations
Re: SVG limitations
Luftmensch wrote:The little bit I've used Inkscape (usually just when I didn't have access to my work computer), I've been frustrated (especially) with the way things save. Especially if I try to export to PDF, I lose text information and apparently everything on a given layer just becomes a big group. I didn't look into the documentation, but I imagine this has to do with limitation in how Inkscape deals with these sorts of elements compared to PDFs.
that's exactly how it works. Inkscape adds a special property (inkscape:groupmode) on a group to tag it as a layer.
Luftmensch wrote:Or maybe whomever made the exporter didn't bother make a big affair of the feature, which is understandable.
that's exactly how it worked
Luftmensch wrote:Anyhows, I got to thinking about the SVG format, which being XML should be infinitely expandable, but coming down to practice, if the file has to be renderable according to the set standards, I have to wonder what sorts of features cannot be added without killing native Plain SVG compatibility.
all features that are added in svg1.2
Luftmensch wrote:In another thread I proposed adding variable width stroke, but I'm not sure how that would be handled. Would the outline instead be a separate path with additional XML information defining the path as being exclusively controlled by the width tool?
It already exists (to some extend ) and it worked somewhat when you described it.
use with ellipse shape (for exemple). inkscape will store (privately) the original path but it will add an additional path that is original path stretched to fit an ellipse.
What if you want the path to look more like a losange ?
select the path.
open the live path editor (shift ctrl 7)
in fx list click pattern along a path
in current fx/pattern source click edit in place
you'll see a (probably) small path (a circle) that defines the enveloppe.
A) add/remove/edit nodes to make it like a losange
or B) create a new shape, copy it (ctrl +c) / reselect your path / in pattern source click paste
I didn't see the video @adobe so it could be easier (you don't have to "guess" where the template path maps to the original path)
but in inkcape you can edit template pattern and see the effect in realtime.
click edit in place you'll see your template pattern (or a copy if you use method B)
and like the "template" pattern is repeated once and stretched, its size (and poisition) doesn't matter
so you can resize it and move it to match the size and position of your path.
Luftmensch wrote:Seems awkward. I'm just curious if SVG could cause problems in the future,
why wait so long ? the problems are already here.
Re: SVG limitations
Well, yeah... The problem with following a W3C standard is that you have to wait for them to come up with the new stuff. W3C, in my opinion, is why too slow. I don't know why, but maybe because it's a multi continental organization and they have this process to approve proposals... Way too bureaucratic to my taste.
The layer becoming a group is indeed a limitation inherited from the SVG format. Inkscape fakes layers using groups to allow you to work with layers within Inksape itself. Which brings us to that particular point. SVG was designed with that in mind, you can add your own stuff to the xml structure, as long as that stuff doesn't break the rendering of the image, or the proper handling of SVG elements that are already defined in the standard. In this case other programs will see just a group and everything will be fine.
With regards to the variable width in strokes, I'm not so sure the "don't break the thing" criteria could be met. Maybe you could have a different path there to show the different width and Inkscape could handle them as a special group too, and the rest of the soft would just render them as a path, but saying it sure is a lot simpler than programing it!
I'm not sure what you mean by "SVG could cause problems in the future", but in any case, the SVG standard, like any other, is both the problem AND the solution. Inkscape, btw, is already adding a lot of it's own stuff there and that doesn't seem to be a problem so far, so maybe there isn't a real limit to what you can add to extend the SVG functionality (except the "don't break" rule).
In any case, right now, to see real variable width in Inkscape, my bet is that we'll have to wait for the W3C to finish the SVG 2 proposal (or was it 3?) and then wait for the Cairo guys to implement it (the rendering engine Inkscape will use) and then the guys at the Inkscape project write the necessary code to handle that... phew, looks like yeeeeears in the future to me.
Anyway... I'm goint to bed.
But man, that video in your other thread made me drool. To have that in Inkscape would be so freaking cool... I'll dream about that tonight, I'm sure, I'll be there floating free in a white immaculate canvas with a brush and a WinXP color palette drawing light-blued leaves... yeah...
The layer becoming a group is indeed a limitation inherited from the SVG format. Inkscape fakes layers using groups to allow you to work with layers within Inksape itself. Which brings us to that particular point. SVG was designed with that in mind, you can add your own stuff to the xml structure, as long as that stuff doesn't break the rendering of the image, or the proper handling of SVG elements that are already defined in the standard. In this case other programs will see just a group and everything will be fine.
With regards to the variable width in strokes, I'm not so sure the "don't break the thing" criteria could be met. Maybe you could have a different path there to show the different width and Inkscape could handle them as a special group too, and the rest of the soft would just render them as a path, but saying it sure is a lot simpler than programing it!
I'm not sure what you mean by "SVG could cause problems in the future", but in any case, the SVG standard, like any other, is both the problem AND the solution. Inkscape, btw, is already adding a lot of it's own stuff there and that doesn't seem to be a problem so far, so maybe there isn't a real limit to what you can add to extend the SVG functionality (except the "don't break" rule).
In any case, right now, to see real variable width in Inkscape, my bet is that we'll have to wait for the W3C to finish the SVG 2 proposal (or was it 3?) and then wait for the Cairo guys to implement it (the rendering engine Inkscape will use) and then the guys at the Inkscape project write the necessary code to handle that... phew, looks like yeeeeears in the future to me.
Anyway... I'm goint to bed.
But man, that video in your other thread made me drool. To have that in Inkscape would be so freaking cool... I'll dream about that tonight, I'm sure, I'll be there floating free in a white immaculate canvas with a brush and a WinXP color palette drawing light-blued leaves... yeah...
Re: SVG limitations
It surprises me that you're still using Inkscape. You seemed so dissatisfied in the earlier topic viewtopic.php?f=22&t=11586
I think the point was made in the earlier topic, or possibly even in this one (I didn't read closely). But just to be sure it's made -- This is an Inkscape users' forum. Sometimes users are also developers. And sometimes users will have opinions about SVG limitations. But for the most part, we use Inkscape because we like it.
I'm thinking there might be better audiences for your comments, which might be better prepared for such "upper level" or technical discussions. ("Upper level" meaning organizational or decision-making, not that Inkscape users are "lowly".)
I think the point was made in the earlier topic, or possibly even in this one (I didn't read closely). But just to be sure it's made -- This is an Inkscape users' forum. Sometimes users are also developers. And sometimes users will have opinions about SVG limitations. But for the most part, we use Inkscape because we like it.
I'm thinking there might be better audiences for your comments, which might be better prepared for such "upper level" or technical discussions. ("Upper level" meaning organizational or decision-making, not that Inkscape users are "lowly".)
Basics - Help menu > Tutorials
Manual - Inkscape: Guide to a Vector Drawing Program
Inkscape Community - Inkscape FAQ - Gallery
Inkscape for Cutting Design
Manual - Inkscape: Guide to a Vector Drawing Program
Inkscape Community - Inkscape FAQ - Gallery
Inkscape for Cutting Design
- shawnhcorey
- Posts: 149
- Joined: Mon Jan 07, 2008 12:17 pm
Re: SVG limitations
Uktrunie wrote:Well, yeah... The problem with following a W3C standard is that you have to wait for them to come up with the new stuff. W3C, in my opinion, is why too slow. I don't know why, but maybe because it's a multi continental organization and they have this process to approve proposals... Way too bureaucratic to my taste.
The approval process is designed so that any member company can:
- Make sure they are well on the way to implementing it before it becomes standard.
- Limit it so that their propriety software actually does more.
-
- Posts: 16
- Joined: Sat Feb 25, 2012 11:40 am
Re: SVG limitations
brynn wrote:It surprises me that you're still using Inkscape. You seemed so dissatisfied in the earlier topic viewtopic.php?f=22&t=11586
[. . .]
I'm thinking there might be better audiences for your comments, which might be better prepared for such "upper level" or technical discussions. ("Upper level" meaning organizational or decision-making, not that Inkscape users are "lowly".)
I'm an Inkscape user in the same sense I'm a Mac user. I'm loosely familiar enough with how the systems work to get by in the unfortunate but inevitable circumstance I'm forced to use either. I still consider Inkscape a terribly designed piece of software with the same practical functionality as Macromedia Freehand 5. But I'm open to accepting its eventual improvement and I gladly follow the occasional update.
As for the audience, I have no idea what you were trying to say right there, but I got good answers from the other users.
Re: SVG limitations
Uumm....Yeah, "audience" was a bad choice of words. I meant a better community in which to discuss your issues.
Basics - Help menu > Tutorials
Manual - Inkscape: Guide to a Vector Drawing Program
Inkscape Community - Inkscape FAQ - Gallery
Inkscape for Cutting Design
Manual - Inkscape: Guide to a Vector Drawing Program
Inkscape Community - Inkscape FAQ - Gallery
Inkscape for Cutting Design