SVG Working Group: Possible New Path Type
Hi,
At the SVG Working Group meeting yesterday there was a discussion on adding a new path type to SVG that would allow a path to be drawn that passes automatically through a list of points. You can read a blog post from Doug Schepers about the idea at:
We discussed the possibility of using Spiro paths rather than the initially proposed Catmull-Rom curves as Inksscape and FontForge already support Spiro curves. (Spiro curves may, however, be overkill and there are patent issues.)
Your feedback would be appreciated.
Tav
My humble opinion is that, with the current official standard still not 100% supported in a lot of software (I'm not speaking only of Inkscape), adding more fancy features would be premature.
I also think that SVG, as the graphic core, should only support things that are very difficult or impossible to do in upper layers, like filters or color management. Things like spiros or polygons (another thing they wanted to add that I was against) are best done via extensions, the way Inkscape does them. This way SVG renderers (as opposed to editors) are freed from the burden of implementing these algorithms.
On 7/15/10, bulia byak wrote:
I also think that SVG, as the graphic core, should only support things that are very difficult or impossible to do in upper layers, like filters or color management. Things like spiros or polygons (another thing they wanted to add that I was against) are best done via extensions, the way Inkscape does them.
The way Inkscape supports Spiro and does LPE in principle should be seriously improved before we can advertise it as a s good solution :)
Alexandre Prokoudine http://libregraphicsworld.org
On Thu, Jul 15, 2010 at 5:34 AM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
The way Inkscape supports Spiro and does LPE in principle should be seriously improved before we can advertise it as a s good solution :)
Everything can be improved in some way. Can you please be more specific?
On 7/15/10, bulia byak wrote:
The way Inkscape supports Spiro and does LPE in principle should be seriously improved before we can advertise it as a s good solution :)
Everything can be improved in some way. Can you please be more specific?
http://lists.w3.org/Archives/Public/www-svg/2010Jul/0037.html
Alexandre Prokoudine http://libregraphicsworld.org
On Thu, Jul 15, 2010 at 11:58 AM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 7/15/10, bulia byak wrote:
The way Inkscape supports Spiro and does LPE in principle should be seriously improved before we can advertise it as a s good solution :)
Everything can be improved in some way. Can you please be more specific?
http://lists.w3.org/Archives/Public/www-svg/2010Jul/0037.html
The fact that LPEs don't update while you drag (only when you release) has absolutely nothing to do with them being en LPE. It's just an implementation detail. It is possible to do it completely live if someone badly needs it. At the very least, this is irrelevant for the W3C list where the source SVG is discussed.
Boolean LPE crashing has even less to do with this. And yes, it is possible to stack LPEs arbitrarily, including applying booleans to spiros.
Please stop spreading FUD about LPEs :)
On 7/15/10, bulia byak wrote:
Everything can be improved in some way. Can you please be more specific?
http://lists.w3.org/Archives/Public/www-svg/2010Jul/0037.html
The fact that LPEs don't update while you drag (only when you release) has absolutely nothing to do with them being en LPE. It's just an implementation detail.
OK, implementation detail then.
It is possible to do it completely live if someone badly needs it.
"Someone"? "Everyone" is more likely.
Boolean LPE crashing has even less to do with this. And yes, it is possible to stack LPEs arbitrarily, including applying booleans to spiros.
Did I say that the whole email should be analyzed with regards to this thread? No, I'm sure as hell I didn't say that.
Please stop spreading FUD about LPEs :)
*shrug* Claiming my points to be invalid won't magically solve real existing issues. But you know better, of course.
Alexandre Prokoudine http://libregraphicsworld.org
On Thu, Jul 15, 2010 at 1:31 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 7/15/10, bulia byak wrote:
It is possible to do it completely live if someone badly needs it.
"Someone"? "Everyone" is more likely.
By the way, this is already fixed with the new Node tool. I completely forgot. Care to try? Dragging a Spiro node updates the Spiro path absolutely live.
I have an excuse for forgetting about that: I rarely drag nodes by mouse, especially when fine-tuning a shape. Alt+arrow keys are more convenient and precise for me. (So much for your "everyone needs it" :)
Of course there are a few other places where fixes are needed, such as Pen and Pencil tool when they draw Spiros. But it's also doable.
Please stop spreading FUD about LPEs :)
*shrug* Claiming my points to be invalid won't magically solve real existing issues. But you know better, of course.
I'm not against discussing existing issues. I'm against discussing them in a wrong place (entirely off topic on the W3C list) and with wrong implications, somehow blaming the LPE idea itself for the implementation details.
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: 15 July 2010 20:37
On Thu, Jul 15, 2010 at 1:31 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 7/15/10, bulia byak wrote:
It is possible to do it completely live if someone badly needs it.
"Someone"? "Everyone" is more likely.
By the way, this is already fixed with the new Node tool. I completely forgot. Care to try? Dragging a Spiro node updates the Spiro path absolutely live.
Huh?! What are you guys talking about? LPEs have always been completely live, hence the name "LIVE path effects". This is not something of the new node tool. 0.46 has live updated LPEs when you drag a node, not only when you release the node.
Confused, Johan
On 7/15/10, bulia byak wrote:
It is possible to do it completely live if someone badly needs it.
"Someone"? "Everyone" is more likely.
By the way, this is already fixed with the new Node tool. I completely forgot. Care to try? Dragging a Spiro node updates the Spiro path absolutely live.
*sigh*
I use Spiro all the time and no -- this is not fixed, because I didn't even *mention* Node tool.
Switch to Pen tool. Choose Spiro mode. Start drawing. What do you see? Bezier curve. Finish the path. Suddenly it becomes a Spiro spline. Is this expected by users? No. Is it supposed to be so? No.
Now choose a pattern-along-path preset for Pen tool. Start drawing. Do you see the pattern applied to the path as you draw? No. Is this expected by users? No. Is it supposed to be so? No.
I'm not against discussing existing issues. I'm against discussing them in a wrong place (entirely off topic on the W3C list) and with wrong implications, somehow blaming the LPE idea itself for the implementation details.
I agree that I did a mistake here. But think a bit further. The whole thing about supporting both LPE and 2.5 effects in the future doesn't worry you? A mix of two different approaches to more or less same problem in one standard and at least one authoring application is fine?
LPE is great, but not perfect. It has problems on both conceptual and implementation (as we all know now) level. Before we suggest anything we do to use in the standard, it'd be jolly good to make sure it won't cause cancer and unpredictable hair loss :)
Alexandre Prokoudine http://libregraphicsworld.org
On 15 July 2010 19:33, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
Switch to Pen tool. Choose Spiro mode. Start drawing. What do you see? Bezier curve. Finish the path. Suddenly it becomes a Spiro spline. Is this expected by users? No. Is it supposed to be so? No.
Now choose a pattern-along-path preset for Pen tool. Start drawing. Do you see the pattern applied to the path as you draw? No. Is this expected by users? No. Is it supposed to be so? No.
It would also be great if we could draw with auto smooth nodes using the Pen tool :)
On Thu, Jul 15, 2010 at 8:33 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
I use Spiro all the time and no -- this is not fixed, because I didn't even *mention* Node tool.
Switch to Pen tool. Choose Spiro mode. Start drawing. What do you see? Bezier curve. Finish the path. Suddenly it becomes a Spiro spline. Is this expected by users? No. Is it supposed to be so? No.
OK, I misunderstood you. I thought you were referring to Node. Pen is broken in this, yes, I mentioned it myself. But fixing it should be even easier than fixing Node.
I agree that I did a mistake here. But think a bit further. The whole thing about supporting both LPE and 2.5 effects in the future doesn't worry you? A mix of two different approaches to more or less same problem in one standard and at least one authoring application is fine?
As Johan very eloquently explained on this list some time ago, SVG vector effects and LPEs are very different and solve different problems.
But we're not speaking about effects here. What is being discussed (if I understand it correctly) is including Spiro or something similar to the SVG core, on equal terms with Beziers, which is a quite different thing. And I object _not_ because Inkscape has a different implementation but because I consider core expansion without sufficient reasons fundamentally detrimental for SVG.
bulia byak wrote:
My humble opinion is that, with the current official standard still not 100% supported in a lot of software (I'm not speaking only of Inkscape), adding more fancy features would be premature.
I also think that SVG, as the graphic core, should only support things that are very difficult or impossible to do in upper layers, like filters or color management. Things like spiros or polygons (another thing they wanted to add that I was against) are best done via extensions, the way Inkscape does them. This way SVG renderers (as opposed to editors) are freed from the burden of implementing these algorithms.
We discussed this general issue a bit at LGM and basically the SVG WG does not see SVG as "the graphic core", but rather as something that can be used for (hand-)authoring and animation. For example, they would also be interested in adding the notion of a layer. It's a bit like we're using SVG as assembly language while they're trying to develop C++.
I can see why they would want that, as it would be pretty cool to have a format that can be edited interoperably by different editors, and it can be very hard to animate a spiro for example if the renderer has no notion of it (you'd have to animate the bezier, which would not have the same effect).
But I think you're absolutely right that this is putting a pretty big burden on renderers and that it might be better to have a more focussed format. Personally I'm thinking that it might be best to select a subset of SVG and/or create a different format specifically for this purpose, but feel free to tell the SVG WG how you feel about this kind of thing on the SVG mailing list.
Hi, Jasper-
Jasper van de Gronde wrote (on 7/15/10 4:47 AM):
We discussed this general issue a bit at LGM and basically the SVG WG does not see SVG as "the graphic core", but rather as something that can be used for (hand-)authoring and animation.
Correct.
For example, they would also be interested in adding the notion of a layer. It's a bit like we're using SVG as assembly language while they're trying to develop C++.
Well... maybe C. :) I realize you're joking a bit, but I don't think that's a great metaphor. SVG was *never* intended as a graphics core, which should be clear from the feature set of SVG 1.0: client-side scripting with a full event model and special graphical APIs, declarative and scripted animation, interactivity, linking, CSS support, and so forth... it was intended as a Web format, with all that entails. Maybe a better metaphor is the difference between HTML used as a text format like RTF versus the way it's used today to make interactive applications; both are valid uses, and they are both HTML.
I can see why they would want that, as it would be pretty cool to have a format that can be edited interoperably by different editors, and it can be very hard to animate a spiro for example if the renderer has no notion of it (you'd have to animate the bezier, which would not have the same effect).
Exactly. Also, these paths are rather smaller in file size than the equivalent Béziers.
But I think you're absolutely right that this is putting a pretty big burden on renderers and that it might be better to have a more focussed format.
A new path command is not a large burden to place on renderers. I realize that Javascript is easier to code than C, but I put together my script lib in an afternoon. How much time would that spare people trying to hand-author Béziers? I think it's a very good investment of implementers time.
The real danger is that it will be disruptive to the ecosystem since it wouldn't be backwards-compatible, so older authoring tools and browsers couldn't make sense of it, and would only render the path up to the point where the new command was made. But that's a minimal risk right now, and is the risk of any new features of SVG, including new gradients.
Personally I'm thinking that it might be best to select a subset of SVG and/or create a different format specifically for this purpose, but feel free to tell the SVG WG how you feel about this kind of thing on the SVG mailing list.
Effectively, Inkscape has already done that... as a static authoring tool, you do not implement the linking, declarative animation, or scripting effects, and that is not required of you. In fact, the SVG WG is clarifying different categories of SVG user agents, including static ones, so Inkscape can occupy the niche it feels best suited for. But that is not a good rational not to add new features to SVG, in my opinion.
Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Doug Schepers wrote:
Jasper van de Gronde wrote (on 7/15/10 4:47 AM):
... But I think you're absolutely right that this is putting a pretty big burden on renderers and that it might be better to have a more focussed format.
A new path command is not a large burden to place on renderers. I realize that Javascript is easier to code than C, but I put together my script lib in an afternoon. How much time would that spare people trying to hand-author Béziers? I think it's a very good investment of implementers time.
Don't get me wrong, I wasn't talking about this specific proposal, but rather the more general idea. SVG is great in many respects, but it is a very complex and subtle standard. Believe me when I say this does put a burden on any implementation.
However, don't let that stop you. In my mind the right solution here wouldn't be to make SVG simpler, but rather to make it easier to make a renderer. One of the things I've been thinking about is making a different (much more basic) format and defining how SVG maps to that format. At the very least it would make the standard much less ambiguous, but I expect it would also help in finding problem areas, and it could help implementations by suggesting a way to break down rendering.
On Fri, Jul 16, 2010 at 4:40 AM, Jasper van de Gronde
However, don't let that stop you. In my mind the right solution here wouldn't be to make SVG simpler, but rather to make it easier to make a renderer. One of the things I've been thinking about is making a different (much more basic) format and defining how SVG maps to that format. At the very least it would make the standard much less ambiguous, but I expect it would also help in finding problem areas, and it could help implementations by suggesting a way to break down rendering.
That is a good idea I think. Right now, we often use Batik as the "standard" because in the spec, there are many unclear and confusing areas. If we had a "basic SVG", for example with featureset of Postscript, and a strictly-defined mapping from the rest of SVG to basic, it would help implementers a lot.
Hi, bulia-
bulia byak wrote (on 7/16/10 4:34 PM):
On Fri, Jul 16, 2010 at 4:40 AM, Jasper van de Gronde
However, don't let that stop you. In my mind the right solution here wouldn't be to make SVG simpler, but rather to make it easier to make a renderer. One of the things I've been thinking about is making a different (much more basic) format and defining how SVG maps to that format. At the very least it would make the standard much less ambiguous, but I expect it would also help in finding problem areas, and it could help implementations by suggesting a way to break down rendering.
That is a good idea I think. Right now, we often use Batik as the "standard" because in the spec, there are many unclear and confusing areas.
If there are areas which are unclear or confusing, you should ask for clarification on the SVG mailing list, www-svg@...2382... We continually issue errata, and right now are in the process of publishing an update, SVG 1.1 Second Edition, to roll some of these errata back into the spec. Browser vendors, other implementers, and even content creators have filed numerous "bugs" with the spec, and we try to correct them as quickly as possible; in addition to clarifying the text in the spec, we try also to make a new test for that feature, so it is clear to implementers what is expected.
Now is an especially good time to report problems with the spec, because it gives us an opportunity to improve it for SVG 2, which we have begun work on. If you have a list of specific issues, we would be very happy to see them.
If we had a "basic SVG", for example with featureset of Postscript, and a strictly-defined mapping from the rest of SVG to basic, it would help implementers a lot.
I'd be concerned about profiling SVG, since that risks fracturing consistency of support. You expressed concern about this lack of consistency in different implementations, and profiling tends to promote such fracturing. However, it's true that only certain features of SVG make sense to implement in a static authoring tool (for example, scripting doesn't necessarily make sense for a drawing tool.
Perhaps if you explained a bit more what you're looking for, and gave some examples, we could help address your needs in SVG 2. Maybe we could mark specific sections as applicable to different classes of user agent, such as static authoring tools.
Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
2010/7/17 Doug Schepers <schepers@...157...>:
Perhaps if you explained a bit more what you're looking for, and gave some examples, we could help address your needs in SVG 2. Maybe we could mark specific sections as applicable to different classes of user agent, such as static authoring tools.
I think Bulia is talking about a minimal, simplified form of SVG that is easy to parse and render and can be automatically generated from full SVG. It would still be valid SVG but with some constraints. For example: - all transforms are specified using the transform() notation - scale(), translate() etc. are not allowed - the only type of shape is svg:path - paths cannot have stroke attributes or markers - both are converted to filled paths - path data is in absolute coordinates; S, T, H and V commands are not allowed - path command letters cannot be omitted for repeated commands - pattern fills that would need a very large intermediate buffer are converted to clipped groups of objects - objectBoundingBox is not allowed - everything is converted to userSpaceOnUse - viewBox are converted to groups and/or appropriate transform attributes - svg:image cannot refer to external SVG documents - etc.
Regards, Krzysztof
Doug Schepers wrote:
Hi, bulia-
bulia byak wrote (on 7/16/10 4:34 PM):
On Fri, Jul 16, 2010 at 4:40 AM, Jasper van de Gronde
However, don't let that stop you. In my mind the right solution here wouldn't be to make SVG simpler, but rather to make it easier to make a renderer. One of the things I've been thinking about is making a different (much more basic) format and defining how SVG maps to that format. At the very least it would make the standard much less ambiguous, but I expect it would also help in finding problem areas, and it could help implementations by suggesting a way to break down rendering.
That is a good idea I think. Right now, we often use Batik as the "standard" because in the spec, there are many unclear and confusing areas.
If there are areas which are unclear or confusing, you should ask for clarification on the SVG mailing list, www-svg@...2382... We continually issue errata, and right now are in the process of publishing an update, SVG 1.1 Second Edition, to roll some of these errata back into the spec. Browser vendors, other implementers, and even content creators have filed numerous "bugs" with the spec, and we try to correct them as quickly as possible; in addition to clarifying the text in the spec, we try also to make a new test for that feature, so it is clear to implementers what is expected.
The point here is not that current specification isn't clear enough, but rather that it could help to more formally define the semantics of SVG. First of all this helps in writing the specification, as it forces you to think about it in a more concrete way, but it also helps in implementing the standard, as the semantics are virtually unambiguous and could even provide a starting point for implementers to break down the specification into simpler tasks.
If we had a "basic SVG", for example with featureset of Postscript, and a strictly-defined mapping from the rest of SVG to basic, it would help implementers a lot.
I'd be concerned about profiling SVG, since that risks fracturing consistency of support. You expressed concern about this lack of consistency in different implementations, and profiling tends to promote such fracturing. However, it's true that only certain features of SVG make sense to implement in a static authoring tool (for example, scripting doesn't necessarily make sense for a drawing tool.
It wouldn't necessarily be a profile that you would actually write a document in, but rather a mental model (that could hopefully be mirrored in an implementation). For example, SVG currently has at least four methods to composite images (three filter elements and the "normal" compositing mode), although this might be a candidate for simplification in a future standard anyway it serves as an example of how a standard like SVG will ALWAYS have multiple ways to do more or less the same thing. Currently this kind of overlap in functionality isn't exposed in the spec at all, which makes it hard to avoid duplicating code and hinders implementing new features (as it is less easy to build on what you already have).
A positive example of something like this in the spec is the definition of rect in terms of path (although I wouldn't mind a less verbose and more formal mapping).
Hi, Bulia-
bulia byak wrote (on 7/15/10 2:16 AM):
My humble opinion is that, with the current official standard still not 100% supported in a lot of software (I'm not speaking only of Inkscape), adding more fancy features would be premature.
Actually, as I mention on the W3C SVG mailing list, we have a rare opportunity to bring the various implementers (authoring tools, browsers, and toolkits) up a notch, while such disruption is relatively minor in bad effects. Right now, implementers are engaged. How long will that persist?
I also think that SVG, as the graphic core, should only support things that are very difficult or impossible to do in upper layers, like filters or color management. Things like spiros or polygons (another thing they wanted to add that I was against) are best done via extensions, the way Inkscape does them. This way SVG renderers (as opposed to editors) are freed from the burden of implementing these algorithms.
No offense, but this is a very static-authoring-tool-centric view. For dynamic effects and animations, which are increasingly part of the SVG "renderer" experience, and for multiple-tool workflows, this model breaks down. For example, as a web developer, Inkscape is only of limited utility to me because the output is not very developer-friendly.
Obviously, Inkscape should feel free to experiment and extend SVG however you want, as you have been doing; this is a great way to find new features that benefit everyone. But when those changes are not reflected in the underlying format, the authoring and user experience drifts further and further apart, and intention is lost. Interoperability is far more important than the features of any given tool.
The SVG community and infrastructure is a large and complex ecosystem, of which Inkscape is a very valuable part... but only one part. For many use cases, this new path command would be really useful, and I don't think it harms Inkscape at all.
So, I'm interested to hear your specific technical objections to adding Catmull-Rom curves (or something similar) to SVG 2. They were very easy for me to implement, and would be fairly trivial for any renderer... much less of a burden than even the simplest filter.
Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
On Thu, Jul 15, 2010 at 6:50 PM, Doug Schepers <schepers@...157...> wrote:
Actually, as I mention on the W3C SVG mailing list, we have a rare opportunity to bring the various implementers (authoring tools, browsers, and toolkits) up a notch, while such disruption is relatively minor in bad effects. Right now, implementers are engaged. How long will that persist?
I think you are biased towards those implementers who are engaged, simply because you see them :) How many more others are out there, who are not engaged at all, and for whom the sudden necessity to implement the Spiro algorithm will become an unpleasant surprise?
Obviously, Inkscape should feel free to experiment and extend SVG however you want, as you have been doing; this is a great way to find new features that benefit everyone. But when those changes are not reflected in the underlying format, the authoring and user experience drifts further and further apart, and intention is lost.
I'm not against standardizing at all. I just think that putting everything into the same standard will make it even heavier (and it's already heavy enough) and slow down its acceptance even more (and it's not like it's suffering from overacceptance right now). Mean and lean things tend to win over huge committee-designed monstrosities. SGML lingered for decades, barely alive, but a much simplified XML took the world by storm.
Once again: the core must contain things which are absolutely essential to graphics and which would be hard to do outside of the core. Spiros are none of that at the moment.
That doesn't mean you can't standardize Spiros. Assuming for a moment that they are a solid and 100% stable feature (which is not quite true, the equations easily diverge into nasty infinities; but I admit I know nothing about the Catmull-Rom curves which might be better in this respect), and you want to place a W3C stamp of approval on them, I would welcome that - but the correct way to do that would be to place them into an optional "effects" module, a separate W3C standard, which would ensure interoperability among those agents that choose to implement the spiro math, _and_ at the same time provide a Bezier-only fallback for those agents who do not. Basically, that would amount to moving the Inkscape's Spiro LPE from Inkscape namespace into a W3C namespace specific to that optional module. The Bezier-only fallback, at least for Spiros, would add only a modest amount of noise to the file and will not significantly affect file size or editability. This way you get the best of both worlds: easy implementation for render-only agents and standardization for those who want to do more with SVG.
participants (8)
-
unknown＠example.com -
Alexandre Prokoudine -
bulia byak -
Dave Crossland -
Doug Schepers -
Jasper van de Gronde -
Krzysztof Kosiński -
Tavmjong Bah