I'm working on Diffusion Curves (for master thesis) and will try to get them in Inkscape in the foreseeable future (this calender year hopefully). As I'm slowly getting more grip on the technical side of things (which is what my thesis will be about) I'd love some input (and help) on UI issues.
For those who haven't heard about them yet, they're basically a new and very(!) flexible way of specifying color transitions. You just assign colors to curves and let the program fill in the intermediate space using diffusion. This tends to create visually pleasing, smooth, transitions while allowing for a very complex geometry with minimal effort. More information (especially see the references at the bottom for examples): http://wiki.inkscape.org/wiki/index.php/Diffusion_Curves
My current thinking is that it would probably be best to treat diffusion curves as a paint server, allowing people to assign color to nodes (that either coincide with existing nodes or are positioned somewhere on the path). The colors would be linearly interpolated along the path. A scheme like this would fit in well with the idea of expanding the functionality of the gradient tool and having a general color picker.
Unfortunately this would sort of limit the ability to blur boundaries to the point that it might not make any sense. But then again, maybe it's a mistake to try and integrate two separate concepts (blur and color transitions), even in the original paper these are treated quite separately (the blur values are diffused separately and then a spatially varying blur is applied).
Any thoughts or suggestions would be helpful.
Also, would it make sense to apply diffusion curves to strokes? If so, how would that work?
On 10-09-07 19:05 , Jasper van de Gronde wrote:
I'm working on Diffusion Curves
Hey, this gave me the goosebumps! :) Just saw the video presentation on the YouTube. Incredible power! I admire...
Not linked directly to Inkscape, but as a general rule of innovation, I think that when your brain is in the 'tool-building' mode, you should not worry about the existing tool taxonomies and terminologies. No matter how cool and smart they are! It might limit the imagination. :)
You know... Blur or/and color? Who knows? You might code something so cool that it can replace several existing tools, with elegance! Or, you might code something that can be 'split' to 'blur' and 'color' in the UI layer to make it easier for the user. Or maybe, it would make the most sense to add it to the existing tools... Who knows...
But in any case, I would like to know more of your thoughts on this!
When you are asking about applying diff.curves to strokes, do you mean, apply them as Inkscape's stroke paint? Maybe I misunderstood how diff.curves work, but to me it seems that they are always applied 'on path'. The YouTube video from siggraph shows open and closed curves, but the diff.curves are over the paths, look like strokes. But, maybe the terminology is escaping me...
If you don't mind working with a graphic designer turned UX/UI/interaction designer on Phd. with humble brain-power and a tendency to trust the real observation data, more than his own (f)artistic impulses, I'd like to volunteer on all things UI! ;) When/If needed, of course...
On 2010-09-07 12:53, Aleksandar Kovač wrote:
... When you are asking about applying diff.curves to strokes, do you mean, apply them as Inkscape's stroke paint? Maybe I misunderstood how diff.curves work, but to me it seems that they are always applied 'on path'. The YouTube video from siggraph shows open and closed curves, but the diff.curves are over the paths, look like strokes. But, maybe the terminology is escaping me...
Good point, I forgot to mention that one of the main "problems" with diffusion curves as defined in the original paper(s) is that they completely do not fit in the normal "stack of objects with fill/stroke" idea. Basically they solve this by explicitly specifying the color on either side of each boundary, but this is not ideal (compared to simply superposing an object over a background for example) and some adhoc solutions are presented (in subsequent papers).
In contrast I (and others) would like to integrate diffusion curves into the normal "stack of objects" concept used in SVG, as this has some definite advantages when it comes to designing an image. Unfortunately this makes it a lot less obvious (to say the least) how "soft boundaries" can be supported. I have some ideas on this, but one of the outcomes could be that it is simply not that big a deal to combine the two, it might actually be more useful to simply have the ability to do a spatially varying blur *as well*.
If you don't mind working with a graphic designer turned UX/UI/interaction designer on Phd. with humble brain-power and a tendency to trust the real observation data, more than his own (f)artistic impulses, I'd like to volunteer on all things UI! ;) When/If needed, of course...
Any help is of course appreciated.
On Tue, 2010-09-07 at 13:53 +0200, Jasper van de Gronde wrote:
Good point, I forgot to mention that one of the main "problems" with diffusion curves as defined in the original paper(s) is that they completely do not fit in the normal "stack of objects with fill/stroke" idea. Basically they solve this by explicitly specifying the color on either side of each boundary, but this is not ideal (compared to simply superposing an object over a background for example) and some adhoc solutions are presented (in subsequent papers).
In contrast I (and others) would like to integrate diffusion curves into the normal "stack of objects" concept used in SVG, as this has some definite advantages when it comes to designing an image. Unfortunately this makes it a lot less obvious (to say the least) how "soft boundaries" can be supported. I have some ideas on this, but one of the outcomes could be that it is simply not that big a deal to combine the two, it might actually be more useful to simply have the ability to do a spatially varying blur *as well*.
I may be missing the point, but should it come down full control in one specific instance vs the ability to reuse a paint, I would choose full control to be able to get the most out of this technique. Seeing how a complex shading/paint/fill will be very dependent on the object, anyway.
On 2010-09-07 14:21, Thorsten Wilms wrote:
On Tue, 2010-09-07 at 13:53 +0200, Jasper van de Gronde wrote:
Good point, I forgot to mention that one of the main "problems" with diffusion curves as defined in the original paper(s) is that they completely do not fit in the normal "stack of objects with fill/stroke" idea. Basically they solve this by explicitly specifying the color on either side of each boundary, but this is not ideal (compared to simply superposing an object over a background for example) and some adhoc solutions are presented (in subsequent papers).
In contrast I (and others) would like to integrate diffusion curves into the normal "stack of objects" concept used in SVG, as this has some definite advantages when it comes to designing an image. Unfortunately this makes it a lot less obvious (to say the least) how "soft boundaries" can be supported. I have some ideas on this, but one of the outcomes could be that it is simply not that big a deal to combine the two, it might actually be more useful to simply have the ability to do a spatially varying blur *as well*.
I may be missing the point, but should it come down full control in one specific instance vs the ability to reuse a paint, I would choose full control to be able to get the most out of this technique. Seeing how a complex shading/paint/fill will be very dependent on the object, anyway.
The issue is not so much full control vs. ability to reuse. There are actually a few issues, but the main one is that the original definition assumed one (fixed-size) flat canvas, so no stacking of objects or translucent overlays or anything. Apart from clashing with SVG's painting model it's also not very useful for a general drawing tool, you want to be able to draw a background and then draw something on top of that without affecting the background (and be able to move it later on) for example. This means we need to figure out a way to make diffusion curves work well within SVG(/Inkscape).
One obvious way to make diffusion curves work within SVG would be to just see it as another kind of paint. So if you give an object a solid color the area affected by the color would be the area affected by the diffusion. This would give a very flexible alternative to the current linear and radial gradients while fitting perfectly within the framework of SVG, in theory you could even reuse the whole gradient stop idea (only the stops would apply to the boundary).
The main restriction this would put on diffusion curves (as far as I can see) is that you can't (easily) have "soft" boundaries. However, in the original paper these are implemented by simply reblurring the result, so you could imagine also separating the two steps in Inkscape.
So, are there other problems people can see with this approach? Any important use cases you can think of that would not be able to benefit fully?
Good day everyone,
The issue is not so much full control vs. ability to reuse. There are actually a few issues, but the main one is that the original definition assumed one (fixed-size) flat canvas
Does this mean that the size of the canvas influences the appearance? (excuse my ignorance)
One obvious way to make diffusion curves work within SVG would be to just see it as another kind of paint. So if you give an object a solid color the area affected by the color would be the area affected by the diffusion.
This seems to be consistent with the current user's mental model of painting. Will users be able to add color-controlling nodes arbitrarily? e.g. have more than 3 controlling nodes on a triangle?
The main restriction this would put on diffusion curves (as far as I can see) is that you can't (easily) have "soft" boundaries. However, in the original paper these are implemented by simply reblurring the result, so you could imagine also separating the two steps in Inkscape.
If the size of the canvas influences the appearance of the diff.curves, personally I'd rather re-blur in an additional step than risk messing up the artwork with every modification of the curve. But...
So, are there other problems people can see with this approach? Any important use cases you can think of that would not be able to benefit fully?
Imagine a filled rectangle. for example, I'd like to have the top and bottom edges of this rectangle sharp, but left and right to have smooth diffusion. If I understand correctly, This would be possible using diff.curves suggested by Orzan et al. Would it be possible using 'diff.curve as paint' approach?
thanks,
Alex
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2010-09-08 05:45, Alex Kovac wrote:
Good day everyone,
The issue is not so much full control vs. ability to reuse. There are actually a few issues, but the main one is that the original definition assumed one (fixed-size) flat canvas
Does this mean that the size of the canvas influences the appearance? (excuse my ignorance)
In the original definition it does. Usually it shouldn't make a huge difference, but yes, it does matter. There are methods that would allow for a theoretically infinite canvas, but requiring support for that would restrict the possible implementations to one kind of method, or at least complicate other implementations.
One obvious way to make diffusion curves work within SVG would be to just see it as another kind of paint. So if you give an object a solid color the area affected by the color would be the area affected by the diffusion.
This seems to be consistent with the current user's mental model of painting. Will users be able to add color-controlling nodes arbitrarily? e.g. have more than 3 controlling nodes on a triangle?
Yes. As many as they would like. And they need not even coincide with nodes of the path, as long as they lie on the path.
The main restriction this would put on diffusion curves (as far as I can see) is that you can't (easily) have "soft" boundaries. However, in the original paper these are implemented by simply reblurring the result, so you could imagine also separating the two steps in Inkscape.
If the size of the canvas influences the appearance of the diff.curves, personally I'd rather re-blur in an additional step than risk messing up the artwork with every modification of the curve. But...
In principle the question of reblurring is separate from having the size of the canvas influence the result.
So, are there other problems people can see with this approach? Any important use cases you can think of that would not be able to benefit fully?
Imagine a filled rectangle. for example, I'd like to have the top and bottom edges of this rectangle sharp, but left and right to have smooth diffusion. If I understand correctly, This would be possible using diff.curves suggested by Orzan et al. Would it be possible using 'diff.curve as paint' approach?
If you mean that the left and right sides would be blurred while the top and bottom are sharp, yes, that is possible in Orzan et al's method. Whether it would be possible in the scheme I proposed would depend on whether we would indeed also have a spatially varying blur. Basically you'd first make a rectangle with the appropriate colors and then apply a spatially varying blur (this comes with a little handwaving, as it's not immediately clear how this would work outside the fill area).
Hey Jasper,
Yes, top posting is evil. :) It seems there are a number of new things, such as diffusion curves, gradient meshes, new curve types, hatching, and more which are being looked into for SVG 2.0. Previously, we've already run into an issue with someone creating a patch to do spiral (conical?) gradients in Inkscape that basically got the thumbs down for not being SVG compliant.
I think that we need to have a configure flag for diffusion curves and other proposed SVG 2.0 features (I seem to recall seeing someone bringing up the spiral gradients too as a thought, so maybe that patch could get integrated after the proposed config modification).
With a configure flag for these "proposed" SVG 2.0 features we can achieve the following. A) We can then figure out the best UI for an authoring tool of these features and not worry about that changing in the meantime. B) We won't run into the flowtext issue again since these features must manually be flagged at build time to be used at all. C) We don't risk breaking SVG compliance in Inkscape proper (aka normal builds) and can also show that these tools/features have use cases and have merit to be in SVG 2.0. D) We can help to figure out what the syntax should look like w/o being overly concerned with this changing over time (these features wouldn't really be for production, so backwards compatibility is far less of an issue). Thoughts?
Cheers, Josh
On Tue, 2010-09-07 at 12:05 +0200, Jasper van de Gronde wrote:
I'm working on Diffusion Curves (for master thesis) and will try to get them in Inkscape in the foreseeable future (this calender year hopefully). As I'm slowly getting more grip on the technical side of things (which is what my thesis will be about) I'd love some input (and help) on UI issues.
For those who haven't heard about them yet, they're basically a new and very(!) flexible way of specifying color transitions. You just assign colors to curves and let the program fill in the intermediate space using diffusion. This tends to create visually pleasing, smooth, transitions while allowing for a very complex geometry with minimal effort. More information (especially see the references at the bottom for examples): http://wiki.inkscape.org/wiki/index.php/Diffusion_Curves
My current thinking is that it would probably be best to treat diffusion curves as a paint server, allowing people to assign color to nodes (that either coincide with existing nodes or are positioned somewhere on the path). The colors would be linearly interpolated along the path. A scheme like this would fit in well with the idea of expanding the functionality of the gradient tool and having a general color picker.
Unfortunately this would sort of limit the ability to blur boundaries to the point that it might not make any sense. But then again, maybe it's a mistake to try and integrate two separate concepts (blur and color transitions), even in the original paper these are treated quite separately (the blur values are diffused separately and then a spatially varying blur is applied).
Any thoughts or suggestions would be helpful.
Also, would it make sense to apply diffusion curves to strokes? If so, how would that work?
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2010-09-07 17:13, Joshua A. Andler wrote:
Yes, top posting is evil. :) It seems there are a number of new things, such as diffusion curves, gradient meshes, new curve types, hatching, and more which are being looked into for SVG 2.0. Previously, we've already run into an issue with someone creating a patch to do spiral (conical?) gradients in Inkscape that basically got the thumbs down for not being SVG compliant.
That's indeed an important issue. I am looking at fallbacks and trying to communicate with the W3C about this.
I think that we need to have a configure flag for diffusion curves and other proposed SVG 2.0 features (I seem to recall seeing someone bringing up the spiral gradients too as a thought, so maybe that patch could get integrated after the proposed config modification).
With a configure flag for these "proposed" SVG 2.0 features we can achieve the following. A) We can then figure out the best UI for an authoring tool of these features and not worry about that changing in the meantime. B) We won't run into the flowtext issue again since these features must manually be flagged at build time to be used at all. C) We don't risk breaking SVG compliance in Inkscape proper (aka normal builds) and can also show that these tools/features have use cases and have merit to be in SVG 2.0. D) We can help to figure out what the syntax should look like w/o being overly concerned with this changing over time (these features wouldn't really be for production, so backwards compatibility is far less of an issue). Thoughts?
I understand where you're coming from, but to me it doesn't feel quite right yet. What if standardization of SVG 2.0 takes another N years? We would then perhaps have several (advanced!) features in the code base that hardly ever get used (because you have to turn them on explicitly). Naturally this would come with all the usual maintenance nightmares of "dead" code. If you don't use it, you don't notice it's broken. And if people do use it a lot the whole point is gone.
Basically we WANT people to use this (and other) new feature(s), and perhaps even especially before they are standardized. But you're right we also do NOT want to run into trouble down the road when the standard is finalized. For now I hope some common sense, fallbacks and a lot of communication will help mitigate these problems, but I'd welcome any suggestions to further improve the situation.
On Tue, 2010-09-07 at 18:12 +0200, Jasper van de Gronde wrote:
I understand where you're coming from, but to me it doesn't feel quite right yet. What if standardization of SVG 2.0 takes another N years? We would then perhaps have several (advanced!) features in the code base that hardly ever get used (because you have to turn them on explicitly). Naturally this would come with all the usual maintenance nightmares of "dead" code. If you don't use it, you don't notice it's broken. And if people do use it a lot the whole point is gone.
We don't properly support SVG versions yet as is. If we get that part straightened out, there would be nothing wrong with having "SVG 2.0 proposed" available (in conjunction w/ svg:switch) so we could then enable these advanced features without any flag. No problems with visibility and use then. :) We also need to remember that even if stuff is enabled by default it can still suffer the fate of lack of maintenance. The gradient editing dialog and the custom win32 dialogs come to mind.
Basically we WANT people to use this (and other) new feature(s), and perhaps even especially before they are standardized. But you're right we also do NOT want to run into trouble down the road when the standard is finalized. For now I hope some common sense, fallbacks and a lot of communication will help mitigate these problems, but I'd welcome any suggestions to further improve the situation.
Yes, we do want people to use new features. I myself want to use them. :) I think that if we have things implemented in a sane way to get non-finalized features in (especially taking into account that there is no proposed syntax for a lot of these things yet even), that we can possibly help to ensure that the features DO get added to the spec.
Please don't mistake where I'm coming from... I want the best vector graphics editor out there. However, given that Inkscape is our choice of editors and is explicitly an SVG editor, it means we have to actively work with the SVG WG to make the best vector graphics format out there.
Cheers, Josh
On 10-09-08 1:49 , Joshua A. Andler wrote:
Yes, we do want people to use new features. I myself want to use them. :) I think that if we have things implemented in a sane way to get non-finalized features in (especially taking into account that there is no proposed syntax for a lot of these things yet even), that we can possibly help to ensure that the features DO get added to the spec.
My opinion is based on the User experience side. Please excuse my ignorance of the possible issues it might/might not introduce in the programming field. I might be completely off here. :) I think that the implementation is not too hard from the User Experience point of view. Additionally, it could allow us to gather some insights from the users that we can use to improve UI, too. A simple example, presuming that there's no 'experimental' branch, but one Inkscape, that allows the widest user-base, would be:
1. Not to let down the trust and loyalty of the people, a stable Inkscape release should be all nice and by-the-book, out of the box, I think.
2. The new features are introduced with a honest and clear, but serious approach. E.g. User enables the feature(s) explicitly using Inkscape preferences' 'Experimental' panel. The panel states: -what is the feature the user is turning on -info on the implications, and the fallback -a link to more info online (it would be great to allow user to turn off the feature, too :)) The panel might have a prominent black/yellow stripe pattern to indicate the 'experimentallity' of this. (or some color...)
This explicit acceptance gives the user a clear signal and choice of crossing from the 'safe and stable' into the 'experimental area'. It's like opening the hood of the car, removing the back cover of the TV set, or lifting a lid on the pot to add some more pepper to mother-in-law's soup. ;)
3. Any new UI element that might appear following this user's decision is visually labeled to clearly indicate the 'experimental' status. For example, using the same pattern or color the user sees on the 'experimental' panel would provide a clear correlation.
4. The user should never lose the data, so the fallback Krzysztof suggested, plus a fair notice when saving or opening such a file, would be nice. A link to a shoutbox, of even an ability to send feedback directly from Inkscape, would be awesome.
From my experience, an approach like this indicates the user a clear 'crossing line' and removes (I'd say) all the confusion and helplessness. Additionally, with an ability to send feedback, it turns user's frustration into collaboration. SVG people could and try and see the thing too and maybe speed up some things! ;)
... The ability to test features live, real users using the real stuff (and by 'testing' I mean their code, implementations and acceptance) is a huge advantage the open source has over any other development paradigm. Excepting evolution ;). We should embrace this more, I think.
The issue of standards is and always will be a love/hate thing. But, as Joshua said, Inkscape is a factor in shaping of these standards.
Am 07.09.2010 18:12, schrieb Jasper van de Gronde:
On 2010-09-07 17:13, Joshua A. Andler wrote:
Yes, top posting is evil. :) It seems there are a number of new things, such as diffusion curves, gradient meshes, new curve types, hatching, and more which are being looked into for SVG 2.0. Previously, we've already run into an issue with someone creating a patch to do spiral (conical?) gradients in Inkscape that basically got the thumbs down for not being SVG compliant.
That's indeed an important issue. I am looking at fallbacks and trying to communicate with the W3C about this.
I think that we need to have a configure flag for diffusion curves and other proposed SVG 2.0 features (I seem to recall seeing someone bringing up the spiral gradients too as a thought, so maybe that patch could get integrated after the proposed config modification).
With a configure flag for these "proposed" SVG 2.0 features we can achieve the following. A) We can then figure out the best UI for an authoring tool of these features and not worry about that changing in the meantime. B) We won't run into the flowtext issue again since these features must manually be flagged at build time to be used at all. C) We don't risk breaking SVG compliance in Inkscape proper (aka normal builds) and can also show that these tools/features have use cases and have merit to be in SVG 2.0. D) We can help to figure out what the syntax should look like w/o being overly concerned with this changing over time (these features wouldn't really be for production, so backwards compatibility is far less of an issue). Thoughts?
I understand where you're coming from, but to me it doesn't feel quite right yet. What if standardization of SVG 2.0 takes another N years? We would then perhaps have several (advanced!) features in the code base that hardly ever get used (because you have to turn them on explicitly). Naturally this would come with all the usual maintenance nightmares of "dead" code. If you don't use it, you don't notice it's broken. And if people do use it a lot the whole point is gone.
Basically we WANT people to use this (and other) new feature(s), and perhaps even especially before they are standardized. But you're right we also do NOT want to run into trouble down the road when the standard is finalized. For now I hope some common sense, fallbacks and a lot of communication will help mitigate these problems, but I'd welcome any suggestions to further improve the situation.
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hey Jasper and other Devs,
thanks for more infos about it. i hope the Diffusion Curves coming son. ;) I´m wainting for it.
2010/9/7 Joshua A. Andler <scislac@...400...>:
I think that we need to have a configure flag for diffusion curves and other proposed SVG 2.0 features (I seem to recall seeing someone bringing up the spiral gradients too as a thought, so maybe that patch could get integrated after the proposed config modification).
Not a good idea. I think this will lead to another Inkboard situation.
We should finally implement correct svg:switch handling and provide fallbacks in the document. Additionally, there should be an option to choose the SVG version in which you want to save. When saving as SVG 1.1, diffusion curves would be saved with bitmap fallbacks.
Regards, Krzysztof
On Tue, 2010-09-07 at 18:14 +0200, Krzysztof Kosiński wrote:
2010/9/7 Joshua A. Andler <scislac@...400...>:
I think that we need to have a configure flag for diffusion curves and other proposed SVG 2.0 features (I seem to recall seeing someone bringing up the spiral gradients too as a thought, so maybe that patch could get integrated after the proposed config modification).
Not a good idea. I think this will lead to another Inkboard situation.
Inkboard had a number of issues, but the flag for compiling it was not one of them. The lack of support for the data throughput on the jabber server side led more to it dying (as well as a lack of continued developer commitment to maintenance) than it being an optional feature. I seem to recall that it was even distributed a few years back in Ubuntu (and possibly other distros) with the feature enabled.
We should finally implement correct svg:switch handling and provide fallbacks in the document. Additionally, there should be an option to choose the SVG version in which you want to save. When saving as SVG 1.1, diffusion curves would be saved with bitmap fallbacks.
I agree with the svg:switch part (long overdue), but I have a feeling that the bitmap fallbacks will not be liked in the same way it wasn't liked when brought up for the spiral gradient feature.
Cheers, Josh
On Tue, 2010-09-07 at 09:24 -0700, Joshua A. Andler wrote:
On Tue, 2010-09-07 at 18:14 +0200, Krzysztof Kosiński wrote:
2010/9/7 Joshua A. Andler <scislac@...400...>:
I think that we need to have a configure flag for diffusion curves and other proposed SVG 2.0 features (I seem to recall seeing someone bringing up the spiral gradients too as a thought, so maybe that patch could get integrated after the proposed config modification).
Not a good idea. I think this will lead to another Inkboard situation.
Inkboard had a number of issues, but the flag for compiling it was not one of them. The lack of support for the data throughput on the jabber server side led more to it dying (as well as a lack of continued developer commitment to maintenance) than it being an optional feature. I seem to recall that it was even distributed a few years back in Ubuntu (and possibly other distros) with the feature enabled.
We should finally implement correct svg:switch handling and provide fallbacks in the document. Additionally, there should be an option to choose the SVG version in which you want to save. When saving as SVG 1.1, diffusion curves would be saved with bitmap fallbacks.
I agree with the svg:switch part (long overdue), but I have a feeling that the bitmap fallbacks will not be liked in the same way it wasn't liked when brought up for the spiral gradient feature.
I believe the correct way of implementing diffusion curves is within the Inkscape name space or with a prefix such as used by mozilla and webkit for rounded corners. If it becomes a part of the SVG standard then the prefix can be removed.
I am not sure that you can handle fallbacks with switches as I don't think there is a way to define custom tests. One thing that was talked about at yesterdays SVG working group meeting was how to handle fallbacks for tags that are not understood. Are children of unknown tags rendered? This isn't clearly defined in SVG and the browsers have implemented it differently. There was a strong argument that children should be rendered from the perspective of people extending SVG for mapping purposes. They want a tag that has all the map projection information that would wrap the map content. The tag would be used by special mapping renderers to transform the SVG coordinates but would fall back gracefully to displaying the untransformed SVG. If all the browser implementers agree (which is a possibility) then you could have something like this:
<inkscape-diffusion-curve ...> <!-- fallback --> <image ....> </inkscape-diffusion-curve>
But the problem here is that images are not treated like paint servers (this will probably change) so some kind of clipping would be involved.
A first step to implementing diffusion curves is to implement gradients along a path. And a gradient along a path could be used to simulate a spiral gradient.
Oh, I don't want to discourage getting switches to work... they would be very useful for things like providing fallback for filters which IE9 won't support.
Tav
On Tue, 2010-09-07 at 12:05 +0200, Jasper van de Gronde wrote:
My current thinking is that it would probably be best to treat diffusion curves as a paint server, allowing people to assign color to nodes (that either coincide with existing nodes or are positioned somewhere on the path). The colors would be linearly interpolated along the path. A scheme like this would fit in well with the idea of expanding the functionality of the gradient tool and having a general color picker.
Unfortunately this would sort of limit the ability to blur boundaries to the point that it might not make any sense. But then again, maybe it's a mistake to try and integrate two separate concepts (blur and color transitions), even in the original paper these are treated quite separately (the blur values are diffused separately and then a spatially varying blur is applied).
Any thoughts or suggestions would be helpful.
Diffusion curves were discussed yesterday at the SVG working group meeting (along with mesh gradients and gradients along a path). There was in general a favorable response to there inclusion in the SVG2 spec provided a good method can be found for their implementation and their specification (and if there are no patent problems). At least one person on the SVG working group has done work on a trial implementation.
Some careful thought should be done on how diffusion curves can be specified in SVG so that what you do could be adapted easily if they make it into the spec. Your suggestion that diffusion curves be treated as a paint server matches what was discussed yesterday. As part of vector effects, partial paths will be supported so you could share paths between an object and diffusion curves via references.
BTW, some form of mesh gradients will almost certainly make it into the next spec.
Tav
participants (8)
-
Aleksandar Kovač -
Alex Kovac -
Axel Richter -
Jasper van de Gronde -
Joshua A. Andler -
Krzysztof Kosiński -
Tavmjong Bah -
Thorsten Wilms