Hi,
Here is an interesting patch in the tracker:
https://bugs.launchpad.net/bugs/346681
"This is a .diff file containing code that allows Inkscape to generate spiral gradients, as well as conical or angular gradients as a degenerate case. It allows the user to create and edit these gradients with the gradient context (tool) and the Fill and Stroke dialog in the same manner as a Radial gradient. It also includes an (ugly) icon for use in the Fill and Stroke dialog and Gradient toolbar."
How come no has one commented for 5 days now? :)
Alexandre
On Fri, Mar 27, 2009 at 8:31 PM, Alexandre Prokoudine
"This is a .diff file containing code that allows Inkscape to generate spiral gradients, as well as conical or angular gradients as a degenerate case. It allows the user to create and edit these gradients with the gradient context (tool) and the Fill and Stroke dialog in the same manner as a Radial gradient. It also includes an (ugly) icon for use in the Fill and Stroke dialog and Gradient toolbar."
It's really a pity that so much work has gone into a feature which is not SVG-compliant...
On Sat, Mar 28, 2009 at 2:53 AM, bulia byak wrote:
It's really a pity that so much work has gone into a feature which is not SVG-compliant...
I have always wondered if we can do compatibility-wise safe extensions to plain SVG for serious things like aforementioned advanced gradient fill types. It really is a pity that it takes so much time to do standards revisions.
Alexandre
On Fri, Mar 27, 2009 at 9:00 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Sat, Mar 28, 2009 at 2:53 AM, bulia byak wrote:
It's really a pity that so much work has gone into a feature which is not SVG-compliant...
I have always wondered if we can do compatibility-wise safe extensions to plain SVG for serious things like aforementioned advanced gradient fill types. It really is a pity that it takes so much time to do standards revisions.
If this used extension attributes and SVG-compliant approximate rendering, just like our shapes, it would be perfectly acceptable. But the author is simply using a new element type which is not SVG and provides no backup rendering. I don't think this will fly.
On Sat, Mar 28, 2009 at 3:07 AM, bulia byak wrote:
If this used extension attributes and SVG-compliant approximate rendering, just like our shapes, it would be perfectly acceptable. But the author is simply using a new element type which is not SVG and provides no backup rendering. I don't think this will fly.
But is this patch absolutely not acceptable or could it possibly be reworked by its author to meets requirements that you listed?
Alexandre
On Fri, Mar 27, 2009 at 9:12 PM, Alexandre Prokoudine
But is this patch absolutely not acceptable or could it possibly be reworked by its author to meets requirements that you listed?
I think it's quite difficult to render a good spiral gradient with pure SVG. This may require a group with multiple layered objects. So perhaps the only way to do this is via svg:switch. I'm just not sure it is worth doing for such a relatively obscure feature.
I know it's kinda evil but there's always the option to render a bitmap version to stay svg compliant...
We need to accept that there are a lot of users (most probably) for whom the svg is not the reason that their using inkscape, they just want a vector art program. For them the svg doesn't support it limitation is irrelevant.
Cheers
John
Sent from my iPhone
On 28 Mar 2009, at 03:14, bulia byak <buliabyak@...400...> wrote:
On Fri, Mar 27, 2009 at 9:12 PM, Alexandre Prokoudine
But is this patch absolutely not acceptable or could it possibly be reworked by its author to meets requirements that you listed?
I think it's quite difficult to render a good spiral gradient with pure SVG. This may require a group with multiple layered objects. So perhaps the only way to do this is via svg:switch. I'm just not sure it is worth doing for such a relatively obscure feature.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 28 Mar 2009 08:49:20 -0000, John Cliff <john.cliff@...400...> wrote:
I know it's kinda evil but there's always the option to render a bitmap version to stay svg compliant...
We need to accept that there are a lot of users (most probably) for whom the svg is not the reason that their using inkscape, they just want a vector art program. For them the svg doesn't support it limitation is irrelevant.
Well, perhaps. If you ask users "do you need this application to be strictly SVG compliant" they'll probably say "SV what?". Ask them instead, "Do you want to be able to send your work to people who don't use Inkscape?" then I'd bet on a 90% "Yes, please" response.
Adding non-svg elements is a slippery and tempting slope but in the long run it will bite back.
I'd be no less SVG compliant than Illustrator, which does exactly what I'm suggesting to get round this sort of issue. Its also what we do to blurs etc when we write them to PDF, so theres precedent in the codebase already...
Personally SVG is the means to the end, not the end in itself.
As for sending stuff to people not using inkscape, I'd generally recommend using pdf not svg for those cases anyway.
2009/3/28 Thomas Worthington <thomas@...2129...>:
On Sat, 28 Mar 2009 08:49:20 -0000, John Cliff <john.cliff@...400...> wrote:
I know it's kinda evil but there's always the option to render a bitmap version to stay svg compliant...
We need to accept that there are a lot of users (most probably) for whom the svg is not the reason that their using inkscape, they just want a vector art program. For them the svg doesn't support it limitation is irrelevant.
Well, perhaps. If you ask users "do you need this application to be strictly SVG compliant" they'll probably say "SV what?". Ask them instead, "Do you want to be able to send your work to people who don't use Inkscape?" then I'd bet on a 90% "Yes, please" response.
Adding non-svg elements is a slippery and tempting slope but in the long run it will bite back.
-- Thomas Worthington Tech Nouveau 32 Bangor Road Groomsport BT19 6JF
07748 792333
Perhaps a little bit naïve and not very well technically informed, but why not encourage browsers editors to support Inkscape SVG instead of plain SVG ?
Sad for plain SVG but if its evolution is too slow to follow users and developpers needs...
________________________________ De : john cliff <john.cliff@...400...> À : Thomas Worthington <thomas@...2129...> Cc : Inkscape Devel List inkscape-devel@lists.sourceforge.net; bulia byak <buliabyak@...400...>; Alexandre Prokoudine <alexandre.prokoudine@...1063....> Envoyé le : Samedi, 28 Mars 2009, 14h17mn 54s Objet : Re: [Inkscape-devel] more gradients
I'd be no less SVG compliant than Illustrator, which does exactly what I'm suggesting to get round this sort of issue. Its also what we do to blurs etc when we write them to PDF, so theres precedent in the codebase already...
Personally SVG is the means to the end, not the end in itself.
As for sending stuff to people not using inkscape, I'd generally recommend using pdf not svg for those cases anyway.
2009/3/28 Thomas Worthington <thomas@...2129...>:
On Sat, 28 Mar 2009 08:49:20 -0000, John Cliff <john.cliff@...400...> wrote:
I know it's kinda evil but there's always the option to render a bitmap version to stay svg compliant...
We need to accept that there are a lot of users (most probably) for whom the svg is not the reason that their using inkscape, they just want a vector art program. For them the svg doesn't support it limitation is irrelevant.
Well, perhaps. If you ask users "do you need this application to be strictly SVG compliant" they'll probably say "SV what?". Ask them instead, "Do you want to be able to send your work to people who don't use Inkscape?" then I'd bet on a 90% "Yes, please" response.
Adding non-svg elements is a slippery and tempting slope but in the long run it will bite back.
-- Thomas Worthington Tech Nouveau 32 Bangor Road Groomsport BT19 6JF
07748 792333
------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 2009-03-28 at 13:38 +0000, Ivan Louette wrote:
Perhaps a little bit naïve and not very well technically informed, but why not encourage browsers editors to support Inkscape SVG instead of plain SVG ?
Sad for plain SVG but if its evolution is too slow to follow users and developpers needs...
Ahh... because Inkscape SVG *is* standard SVG.
The difference between Inkscape SVG and "Plain SVG" is that for plain, the little bits of marker attributes and such that help in *editing* of the SVG are dropped out.
For *viewing*, Inkscape relies on standard SVG features to achieve everything.
Thanks for your reply and the info !
ivan
________________________________ De : Jon A. Cruz <jon@...18...> À : Ivan Louette <ivan_louette@...48...> Cc : john cliff <john.cliff@...400...>; Thomas Worthington <thomas@...2165.....>; Inkscape Devel List inkscape-devel@lists.sourceforge.net; bulia byak <buliabyak@...400...>; Alexandre Prokoudine <alexandre.prokoudine@...1063....> Envoyé le : Dimanche, 29 Mars 2009, 1h52mn 53s Objet : Re: [Inkscape-devel] Re : more gradients
On Sat, 2009-03-28 at 13:38 +0000, Ivan Louette wrote:
Perhaps a little bit naïve and not very well technically informed, but why not encourage browsers editors to support Inkscape SVG instead of plain SVG ?
Sad for plain SVG but if its evolution is too slow to follow users and developpers needs...
Ahh... because Inkscape SVG *is* standard SVG.
The difference between Inkscape SVG and "Plain SVG" is that for plain, the little bits of marker attributes and such that help in *editing* of the SVG are dropped out.
For *viewing*, Inkscape relies on standard SVG features to achieve everything.
On Sat, 2009-03-28 at 13:17 +0000, john cliff wrote:
I'd be no less SVG compliant than Illustrator, which does exactly what I'm suggesting to get round this sort of issue. Its also what we do to blurs etc when we write them to PDF, so theres precedent in the codebase already...
Personally SVG is the means to the end, not the end in itself.
Same here. I do think your proposed bitmap solution is a good way to work around the problem of other SVG renderers (first thing that popped into my head too). As much as we all love SVG and standards, SVG evolves slowly. I'd argue that we should focus on making our program more standards compliant before we start pushing beyond the current standard, however, someone had a creative itch to scratch and they did (and will probably continue to if we support them).
It seems like a lot of people want a more creatively powerful tool than SVG will currently allow (if everything is to remain scalable in other renderers). Given that, are we willing to do things less elegantly due to current SVG limitations in the name of empowering of our users?
The other side of this, what if these features do get added to the SVG standard one day and it's radically different than how it's already implemented in Inkscape. This more than likely creates a "breaking a feature" backwards compatibility issue for our users' documents... and we haven't even been willing to do this for Spirals (I seem to recall that they're not "right" formula-wise).
Cheers, Josh
On Sat, Mar 28, 2009 at 4:32 PM, Joshua A. Andler <scislac@...400...> wrote:
Same here. I do think your proposed bitmap solution is a good way to work around the problem of other SVG renderers (first thing that popped into my head too). As much as we all love SVG and standards, SVG evolves slowly. I'd argue that we should focus on making our program more standards compliant before we start pushing beyond the current standard, however, someone had a creative itch to scratch and they did (and will probably continue to if we support them).
OK, so the consensus for this patch seems to be: thanks, but please rework it so it uses svg:switch and provides automatic bitmap rendering (with adjustable resolution!) in the non-Inkscape branch upon saving the document. If this works well we can then reuse the same framework for implementing other non-SVG features as well, such as gradient meshes, so please try to code this as kind of object to be as universal as possible.
On Sun, Mar 29, 2009 at 12:24 AM, bulia byak wrote:
OK, so the consensus for this patch seems to be: thanks, but please rework it so it uses svg:switch and provides automatic bitmap rendering (with adjustable resolution!) in the non-Inkscape branch upon saving the document. If this works well we can then reuse the same framework for implementing other non-SVG features as well, such as gradient meshes, so please try to code this as kind of object to be as universal as possible.
Sounds good to me. Just one question, however. How will that affect our plans to definitively switch to Cairo?
Alexandre
On Sat, Mar 28, 2009 at 5:33 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Sun, Mar 29, 2009 at 12:24 AM, bulia byak wrote:
OK, so the consensus for this patch seems to be: thanks, but please rework it so it uses svg:switch and provides automatic bitmap rendering (with adjustable resolution!) in the non-Inkscape branch upon saving the document. If this works well we can then reuse the same framework for implementing other non-SVG features as well, such as gradient meshes, so please try to code this as kind of object to be as universal as possible.
Sounds good to me. Just one question, however. How will that affect our plans to definitively switch to Cairo?
The spiral gradient renderer would have to remain non-cairo, I think that's inevitable. But the patch includes the renderer, and switch to cairo does not have to be all-or-nothing anyway - for example filters would still have to be rendered outside of cairo anyway.
On Sun, Mar 29, 2009 at 12:50 AM, bulia byak wrote:
On Sat, Mar 28, 2009 at 5:33 PM, Alexandre Prokoudine
Sounds good to me. Just one question, however. How will that affect our plans to definitively switch to Cairo?
The spiral gradient renderer would have to remain non-cairo, I think that's inevitable. But the patch includes the renderer, and switch to cairo does not have to be all-or-nothing anyway - for example filters would still have to be rendered outside of cairo anyway.
That reminds me of Carl's talk at LGM last year where support for SVG filters came up as something that would love to see done. Another thing is that xlib seems to support conical gradient fills now, and doesn't Cairo rely on xlib?
Alexandre
On Sat, Mar 28, 2009 at 6:05 PM, Alexandre Prokoudine
That reminds me of Carl's talk at LGM last year where support for SVG filters came up as something that would love to see done.
We're already waiting on some things to be done in cairo before we can move ahead with it. I would hate to add to this list :)
Another thing is that xlib seems to support conical gradient fills now, and doesn't Cairo rely on xlib?
No. It can use xlib as one of the back-ends I think but it does not "depend" on it.
Am Samstag, den 28.03.2009, 17:24 -0400 schrieb bulia byak:
On Sat, Mar 28, 2009 at 4:32 PM, Joshua A. Andler <scislac@...400...> wrote:
Same here. I do think your proposed bitmap solution is a good way to work around the problem of other SVG renderers (first thing that popped into my head too). As much as we all love SVG and standards, SVG evolves slowly. I'd argue that we should focus on making our program more standards compliant before we start pushing beyond the current standard, however, someone had a creative itch to scratch and they did (and will probably continue to if we support them).
OK, so the consensus for this patch seems to be: thanks, but please rework it so it uses svg:switch and provides automatic bitmap rendering (with adjustable resolution!) in the non-Inkscape branch upon saving the document. If this works well we can then reuse the same framework for implementing other non-SVG features as well, such as gradient meshes, so please try to code this as kind of object to be as universal as possible.
And please add an option to disable all non SVG options in the GUI. I use Inkscape as an SVG editor and I like to create real "vector only" images with it and no "vector-pixmap mix images". That is even the reason, why I hate AI. In AI I can't create clean SVG files.
Regards, Tobias
Alexandre Prokoudine wrote:
On Mon, Mar 30, 2009 at 1:18 AM, Tobias Jakobs wrote:
And please add an option to disable all non SVG options in the GUI.
Hmmm, do you understand how much effort it will take to create such an option for no obvious reason?
I would like such an option too and would set my Inkscape to produce only clean SVGs, without embedded bitmaps. I don't want to have to think when using any of the tools in the toolbar: "is this supported by the SVG standard?"
On Mon, Mar 30, 2009 at 11:50 AM, Nicu Buculei wrote:
I would like such an option too and would set my Inkscape to produce only clean SVGs, without embedded bitmaps. I don't want to have to think when using any of the tools in the toolbar: "is this supported by the SVG standard?"
Nicu, with all respect due, you are contradicting yourself. Embedded bitmaps are perfectly fine in SVG.
Alexandre
Alexandre Prokoudine wrote:
On Mon, Mar 30, 2009 at 11:50 AM, Nicu Buculei wrote:
I would like such an option too and would set my Inkscape to produce only clean SVGs, without embedded bitmaps. I don't want to have to think when using any of the tools in the toolbar: "is this supported by the SVG standard?"
Nicu, with all respect due, you are contradicting yourself. Embedded bitmaps are perfectly fine in SVG.
I took a shortcut, using less words and believing the idea will get trough... those are not "real" SVG, they can't be scaled without a loss of quality and easily edited. So I could export as bitmaps and claim the job done. The increase in file size from embedding bitmaps is also a concern.
On Mon, Mar 30, 2009 at 10:23, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Mon, Mar 30, 2009 at 11:50 AM, Nicu Buculei wrote:
I would like such an option too and would set my Inkscape to produce only clean SVGs, without embedded bitmaps. I don't want to have to think when using any of the tools in the toolbar: "is this supported by the SVG standard?"
Nicu, with all respect due, you are contradicting yourself. Embedded bitmaps are perfectly fine in SVG.
Yes, it's valid SVG but no longer a real vector image.
Tobias
On Mon, 2009-03-30 at 16:58 +0200, Tobias Jakobs wrote:
On Mon, Mar 30, 2009 at 10:23, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Mon, Mar 30, 2009 at 11:50 AM, Nicu Buculei wrote:
I would like such an option too and would set my Inkscape to produce only clean SVGs, without embedded bitmaps. I don't want to have to think when using any of the tools in the toolbar: "is this supported by the SVG standard?"
Nicu, with all respect due, you are contradicting yourself. Embedded bitmaps are perfectly fine in SVG.
Yes, it's valid SVG but no longer a real vector image.
I don't think that was where Alexandre was going. He was simply stating that embedded bitmaps are part of the SVG standard. So as far as SVG is concerned, it's still a real "vector" image... it's in the name of the format even! ;)
Realistically, bitmaps are a part of the workflow out of convenience for users of the format. If you really want to be an old-school purist about this, SVG filters should be considered unacceptable as well. They're basically a "raster manipulation" of vector objects. Start zooming in on things with lighting effects and see how lovely they start to look. Now... I'm not saying I'm against them, but let's look at things for what they are. :)
Cheers, Josh
On Mon, 2009-03-30 at 08:12 -0700, Joshua A. Andler wrote:
Realistically, bitmaps are a part of the workflow out of convenience for users of the format. If you really want to be an old-school purist about this, SVG filters should be considered unacceptable as well. They're basically a "raster manipulation" of vector objects. Start zooming in on things with lighting effects and see how lovely they start to look. Now... I'm not saying I'm against them, but let's look at things for what they are. :)
No, I'd have to disagree with this. The filters are bitmap effects that are applied at the time of rendering, not at the time of saving the file. So the viewer is still choosing the resolution, not the authoring tool. So it's entirely different.
--Ted
On Mon, 2009-03-30 at 11:09 -0500, Ted Gould wrote:
On Mon, 2009-03-30 at 08:12 -0700, Joshua A. Andler wrote:
Realistically, bitmaps are a part of the workflow out of convenience for users of the format. If you really want to be an old-school purist about this, SVG filters should be considered unacceptable as well. They're basically a "raster manipulation" of vector objects. Start zooming in on things with lighting effects and see how lovely they start to look. Now... I'm not saying I'm against them, but let's look at things for what they are. :)
No, I'd have to disagree with this. The filters are bitmap effects that are applied at the time of rendering, not at the time of saving the file. So the viewer is still choosing the resolution, not the authoring tool. So it's entirely different.
But again... I'm not saying they don't scale. I'm saying go try and make your argument to vector purists in the Graphic Design field (I'm talking people who have been doing this for 20 years or so)... there is nothing you can do to change their perspective. The attitude is that even though the filters are scalable, they still are a "bitmap effect" that is applied to the real vector objects. Nothing will change that. If it could not also be achieved via the bezier & node tools it is not pure vector (yes, masks also do fall into that category too regardless of how old the feature is). That is the real purist standpoint.
Anyway, this topic has steered way off-course and we seem to be into pointless hair-splitting... Who wants to use all this time and energy to actually work on something productive instead? I do! :)
On Sun, Mar 29, 2009 at 7:18 PM, Tobias Jakobs <tobias.jakobs@...1439...> wrote:
And please add an option to disable all non SVG options in the GUI. I use Inkscape as an SVG editor and I like to create real "vector only" images with it and no "vector-pixmap mix images". That is even the reason, why I hate AI. In AI I can't create clean SVG files.
I think it's a reasonable requirement to add, and not too difficult to implement (although, admittedly, it's still some extra work).
On Mon, 2009-03-30 at 13:40 -0300, bulia byak wrote:
On Sun, Mar 29, 2009 at 7:18 PM, Tobias Jakobs <tobias.jakobs@...1439...> wrote:
And please add an option to disable all non SVG options in the GUI. I use Inkscape as an SVG editor and I like to create real "vector only" images with it and no "vector-pixmap mix images". That is even the reason, why I hate AI. In AI I can't create clean SVG files.
I think it's a reasonable requirement to add, and not too difficult to implement (although, admittedly, it's still some extra work).
Agreed, a very reasonable requirement to add.
On Sat, 2009-03-28 at 13:32 -0700, Joshua A. Andler wrote:
On Sat, 2009-03-28 at 13:17 +0000, john cliff wrote:
I'd be no less SVG compliant than Illustrator, which does exactly what I'm suggesting to get round this sort of issue. Its also what we do to blurs etc when we write them to PDF, so theres precedent in the codebase already...
Personally SVG is the means to the end, not the end in itself.
Same here. I do think your proposed bitmap solution is a good way to work around the problem of other SVG renderers (first thing that popped into my head too). As much as we all love SVG and standards, SVG evolves slowly. I'd argue that we should focus on making our program more standards compliant before we start pushing beyond the current standard, however, someone had a creative itch to scratch and they did (and will probably continue to if we support them).
I completely disagree on where this thread is going. I think of SVG like x86 byte code, it sucks in many ways, but by sticking with it we get lots of gains. For one, we have an entire committee who deals with compatibility issues for us :)
WRT the radial gradients I don't understand why the same techniques that Bulia came up with for the gradient meshes can't be used. I believe the attached file is roughly a radial gradient from black to white in the middle of a rectangle. And there's no reason we can't detect the meta data and render it in our own implementation in a faster way, but this should be vector in Firefox also.
--Ted
PS - View the file in Inkscape not RSVG. RSVG fails on this one :)
On 30 Mar 2009, at 03:34, Ted Gould <ted@...11...> wrote:
On Sat, 2009-03-28 at 13:32 -0700, Joshua A. Andler wrote:
On Sat, 2009-03-28 at 13:17 +0000, john cliff wrote:
I'd be no less SVG compliant than Illustrator, which does exactly what I'm suggesting to get round this sort of issue. Its also what we do to blurs etc when we write them to PDF, so theres precedent in the codebase already...
Personally SVG is the means to the end, not the end in itself.
Same here. I do think your proposed bitmap solution is a good way to work around the problem of other SVG renderers (first thing that popped into my head too). As much as we all love SVG and standards, SVG evolves slowly. I'd argue that we should focus on making our program more standards compliant before we start pushing beyond the current standard, however, someone had a creative itch to scratch and they did (and will probably continue to if we support them).
I completely disagree on where this thread is going. I think of SVG like x86 byte code, it sucks in many ways, but by sticking with it we get lots of gains. For one, we have an entire committee who deals with compatibility issues for us :)
WRT the radial gradients I don't understand why the same techniques that Bulia came up with for the gradient meshes can't be used. I believe the attached file is roughly a radial gradient from black to white in the middle of a rectangle. And there's no reason we can't detect the meta data and render it in our own implementation in a faster way, but this should be vector in Firefox also.
--TedPS - View the file in Inkscape not RSVG. RSVG fails on this one :)
<Radial Gradient.svg>
Three points: 1. I'm not suggesting we do something that's not valid svg. 2. Unless there's some serious speed increase in the way we render blurs etc, we should probably avoid workarounds that introduce more 3. We should probably avoid solutions where you have to say but don't look at it in one of the commonest renderers cos it won't work...
I'm not advocating the bitmap option because I like it as a solution, but because I think it's the most useable right now.
John Cliff wrote:
Three points:
- I'm not suggesting we do something that's not valid svg.
- Unless there's some serious speed increase in the way we render
blurs etc, we should probably avoid workarounds that introduce more 3. We should probably avoid solutions where you have to say but don't look at it in one of the commonest renderers cos it won't work...
I'm not advocating the bitmap option because I like it as a solution, but because I think it's the most useable right now.
Can someone perhaps explain exactly what the discussed features are? As I understand from the patch it's about spiral gradients? How *exactly* is a spiral gradient defined?
I'm just asking because it seems like it's considered obvious that there is no other way to simulate a spiral gradient than to generate a bitmap. And I'd at least like the opportunity to see for myself.
(And I did look at the actual patch, but I couldn't find any clear formula or something that defined what a spiral gradient is.)
On Mon, Mar 30, 2009 at 12:33 PM, Jasper van de Gronde wrote:
Can someone perhaps explain exactly what the discussed features are? As I understand from the patch it's about spiral gradients? How *exactly* is a spiral gradient defined?
I'm somewhat confused btw. I played with patched Inkscape a bit (the patch is missing an svg file that it mentiones in Makefile.am), but I only see conical gradient fill, not a spiral.
Alexandre
On Mon, Mar 30, 2009 at 4:56 AM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Mon, Mar 30, 2009 at 12:33 PM, Jasper van de Gronde wrote:
Can someone perhaps explain exactly what the discussed features are? As I understand from the patch it's about spiral gradients? How *exactly* is a spiral gradient defined?
I'm somewhat confused btw. I played with patched Inkscape a bit (the patch is missing an svg file that it mentiones in Makefile.am), but I only see conical gradient fill, not a spiral.
These are synonyms I guess. Just a gradient which goes along the circular arc around a center, impossible to emulate with linear or elliptic because it requires a smoothly changing rate of color change as you go farther away from the center.
On Mon, 2009-03-30 at 05:03 -0400, bulia byak wrote:
On Mon, Mar 30, 2009 at 4:56 AM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On Mon, Mar 30, 2009 at 12:33 PM, Jasper van de Gronde wrote:
Can someone perhaps explain exactly what the discussed features are? As I understand from the patch it's about spiral gradients? How *exactly* is a spiral gradient defined?
I'm somewhat confused btw. I played with patched Inkscape a bit (the patch is missing an svg file that it mentiones in Makefile.am), but I only see conical gradient fill, not a spiral.
These are synonyms I guess. Just a gradient which goes along the circular arc around a center, impossible to emulate with linear or elliptic because it requires a smoothly changing rate of color change as you go farther away from the center.
So would it be describing them as non-linear gradients be correct?
--Ted
On Mon, Mar 30, 2009 at 10:41 AM, Ted Gould <ted@...11...> wrote:
So would it be describing them as non-linear gradients be correct?
I don't know what you call "linear", anyway have a look:
http://www.dvd-replica.com/kozykorner/texteffects-6
You can't approximate that with blur IMHO.
On Mon, Mar 30, 2009 at 12:03 PM, bulia byak wrote:
I'm somewhat confused btw. I played with patched Inkscape a bit (the patch is missing an svg file that it mentiones in Makefile.am), but I only see conical gradient fill, not a spiral.
These are synonyms I guess. Just a gradient which goes along the circular arc around a center, impossible to emulate with linear or elliptic because it requires a smoothly changing rate of color change as you go farther away from the center.
OK. There are more issues with this patch in fact. E.g. when you select a color stop, it will always be black in the bottom indicator and in fill'n'stroke dialog. So whether or not we are accepting it in some form, it really needs some extra work.
Alexandre
On Mon, 2009-03-30 at 07:13 +0100, John Cliff wrote:
On 30 Mar 2009, at 03:34, Ted Gould <ted@...11...> wrote:
WRT the radial gradients I don't understand why the same techniques that Bulia came up with for the gradient meshes can't be used. I believe the attached file is roughly a radial gradient from black to white in the middle of a rectangle. And there's no reason we can't detect the meta data and render it in our own implementation in a faster way, but this should be vector in Firefox also.
Three points:
Three counter-points :)
- I'm not suggesting we do something that's not valid svg.
I understand that it's valid SVG. But, it's against the spirit of a vectored format. I personally found it inadequate when I found out that Adobe Illustrator made gradient meshes into bitmaps in SVG. Not that it wasn't valid SVG, more that it was an unreasonable workaround.
- Unless there's some serious speed increase in the way we render
blurs etc, we should probably avoid workarounds that introduce more
I'm not suggesting that *we* render it using a blur, I'm suggesting that we represent it in the SVG using a blur. Just like when drawing spirals we're not constantly editing the nodes, we're looking at the metadata, detecting it as a spiral, editing it as such, and then putting it back out as a path.
- We should probably avoid solutions where you have to say but don't
look at it in one of the commonest renderers cos it won't work...
I'm not sure that this is reasonable when it comes to RSVG. For me to say that you should look at it in RSVG you can't use features like text-on-a-path either... I think that we should support text-on-a-path :) I'm not sure that RSVG is the most common renderer either, I believe that Firefox and Safari would be.
I'm not advocating the bitmap option because I like it as a solution, but because I think it's the most useable right now.
I'm not against bitmaps because I don't want this feature. I'm against it because it's a way to not really fix the problem, and will generally socialize the situation where we allow for things that don't match user expectations of what Inkscape does. It's likely to lead down a path of people starting to get excited, and then extremely disappointed in the end.
--Ted
On Mon, 2009-03-30 at 08:24 -0500, Ted Gould wrote:
I understand that it's valid SVG. But, it's against the spirit of a vectored format. I personally found it inadequate when I found out that Adobe Illustrator made gradient meshes into bitmaps in SVG. Not that it wasn't valid SVG, more that it was an unreasonable workaround.
Many old-school vector artists think that SVG filters are also against the spirit of a vectored format... myself included. Ask any vector purist what they think of using bitmap anything (effects, textures, etc) in a "vector" image. The reality is that most people aren't purists and are willing to compromise when it's for very useful features. I think I abuse filters more than most... simply because I'm utilizing features of a powerful tool. And if filters weren't a part of the SVG standard? If inkscape offered them, I'd still use them. SVG is just a means to an end for me. As long as things are scalable in Inkscape, my needs are met.
Oh, and Adobe's gradient meshes are in no way a priority for scalable representation in SVG... it's totally a reasonable workaround for them. I don't think that hindering the abilities of their graphics application in the name of supporting a secondary format (as far as they're concerned) would make any sense. I guess what I'm getting at... Illustrator has some great features, if they can't provide a scalable alternative with SVG, should they just refuse to export? Either way, bringing up Illustrator is pointless... their goal isn't primarily to be an SVG editor, the fact that it exports to the format is a bonus for their users.
- Unless there's some serious speed increase in the way we render
blurs etc, we should probably avoid workarounds that introduce more
I'm not suggesting that *we* render it using a blur, I'm suggesting that we represent it in the SVG using a blur. Just like when drawing spirals we're not constantly editing the nodes, we're looking at the metadata, detecting it as a spiral, editing it as such, and then putting it back out as a path.
Editing vs representation in the doc was not the issue. However, what you said, us rendering something one way in inkscape and then us making other renderers render it in a different way, is an issue. I would think that it looking the same in different renderers would be a higher priority.
I would also think it would be nice of us to be considerate to our users, especially if we are going to abuse blur. Do we then put a nag screen saying "You used feature X, we have blurred the heck out of A, B, and C for the benefit of scalability in other renderers, so expect the app you open this in to be unresponsive for a couple minutes... oh and it may not look the same as it did in inkscape anyway"? Yes, it's exaggerated... but without such a nag, our bug tracker would implode from the weight of the reports of us producing SVGs that lock up every other app that opens them.
Again, I don't think anyone is saying a bitmap workaround would be optimal. So I think that we're all wasting time and energy agreeing on the fundamentals.
As for user expectations, let's say we have groups A and B... A wants the best and most capable vector graphics app, B wants an SVG editor. The question is do we implement features in a wonky way (meaning comparable features for every other vector app look significantly different) for the sake of scalability in other renderers? Do we refuse to implement features because there's no scalable solution for SVG? Or, do we make a compromise and allow things to behave and look right in Inkscape, and limit the scalability of the output but keep it compliant? To me, the last one is the best solution if there would be a big enough benefit to the user (and users that don't want to use the features for religious reasons don't have to).
Cheers, Josh
2009/3/30 Ted Gould <ted@...11...>:
On Mon, 2009-03-30 at 07:13 +0100, John Cliff wrote:
On 30 Mar 2009, at 03:34, Ted Gould <ted@...11...> wrote:
WRT the radial gradients I don't understand why the same techniques that Bulia came up with for the gradient meshes can't be used. I believe the attached file is roughly a radial gradient from black to white in the middle of a rectangle. And there's no reason we can't detect the meta data and render it in our own implementation in a faster way, but this should be vector in Firefox also.
Three points:
Three counter-points :)
- I'm not suggesting we do something that's not valid svg.
I understand that it's valid SVG. But, it's against the spirit of a vectored format. I personally found it inadequate when I found out that Adobe Illustrator made gradient meshes into bitmaps in SVG. Not that it wasn't valid SVG, more that it was an unreasonable workaround.
What else are they meant to do with the gradient meshes? dump them? The format lacks the ability to define things users want, so a workaround is necessary. SVG Spec changes arent exactly the quickest thing to get sorted, look how long the text things taken... Are we just meant to ignore these things in the mean time?
- Unless there's some serious speed increase in the way we render
blurs etc, we should probably avoid workarounds that introduce more
I'm not suggesting that *we* render it using a blur, I'm suggesting that we represent it in the SVG using a blur. Just like when drawing spirals we're not constantly editing the nodes, we're looking at the metadata, detecting it as a spiral, editing it as such, and then putting it back out as a path.
I'd rather use a workaround that looks the same as what we render, and the blur thing will be very hard to guarantee that with. So unless thats how we render them I dont think its a reasonable option.
- We should probably avoid solutions where you have to say but don't
look at it in one of the commonest renderers cos it won't work...
I'm not sure that this is reasonable when it comes to RSVG. For me to say that you should look at it in RSVG you can't use features like text-on-a-path either... I think that we should support text-on-a-path :) I'm not sure that RSVG is the most common renderer either, I believe that Firefox and Safari would be.
Well they dont work in the mobile version of safari either... just out of interest, Why doesnt text on path work in RSVG?
I'm not advocating the bitmap option because I like it as a solution, but because I think it's the most useable right now.
I'm not against bitmaps because I don't want this feature. I'm against it because it's a way to not really fix the problem, and will generally socialize the situation where we allow for things that don't match user expectations of what Inkscape does. It's likely to lead down a path of people starting to get excited, and then extremely disappointed in the end.
It only does that when they step outside inkscape with SVG, which I think you'll find an awfully large portion probably dont. And having a 'stick to SVG features' button is a viable workround for this for the people that do care...
On Mon, 2009-03-30 at 19:57 +0100, john cliff wrote:
- I'm not suggesting we do something that's not valid svg.
I understand that it's valid SVG. But, it's against the spirit of a vectored format. I personally found it inadequate when I found out that Adobe Illustrator made gradient meshes into bitmaps in SVG. Not that it wasn't valid SVG, more that it was an unreasonable workaround.
What else are they meant to do with the gradient meshes? dump them? The format lacks the ability to define things users want, so a workaround is necessary.
I'm not sure what they could do with them. But, I know that Adobe has some very smart people there, I'd imagine the smart people weren't asked about it anymore once someone decided to dump it to bitmap. I think Bulia came up with an interesting way to represent it.
- Unless there's some serious speed increase in the way we render
blurs etc, we should probably avoid workarounds that introduce more
I'm not suggesting that *we* render it using a blur, I'm suggesting that we represent it in the SVG using a blur. Just like when drawing spirals we're not constantly editing the nodes, we're looking at the metadata, detecting it as a spiral, editing it as such, and then putting it back out as a path.
I'd rather use a workaround that looks the same as what we render, and the blur thing will be very hard to guarantee that with. So unless thats how we render them I dont think its a reasonable option.
We'll always end up with compatibility issues with everything like this. We have in the past with spirals and other shapes. We can't guarantee, but we can test and I think that Jasper's test suite has been doing a pretty good job at keeping us honest.
- We should probably avoid solutions where you have to say but don't
look at it in one of the commonest renderers cos it won't work...
I'm not sure that this is reasonable when it comes to RSVG. For me to say that you should look at it in RSVG you can't use features like text-on-a-path either... I think that we should support text-on-a-path :) I'm not sure that RSVG is the most common renderer either, I believe that Firefox and Safari would be.
Well they dont work in the mobile version of safari either... just out of interest, Why doesnt text on path work in RSVG?
Work on my iPhone. I'm guessing that test-on-a-path doesn't work in RSVG because you haven't finished the patch yet ;) I don't think there's a technical reason why not.
--Ted
On Mon, Mar 30, 2009 at 4:24 PM, Ted Gould wrote:
I understand that it's valid SVG. But, it's against the spirit of a vectored format.
Ted,
It seems to me that we are slowly drifting to the "right vs. comfortable" type of discussion :) I'm afraid that by being overidealistic we are hurting ourselves.
Honestly, SVG on the Web right is as rare as a Stradivari violin in a country-side music school and it isn't changing much from what I can tell (maybe Jon Cruz as someone who visited SVG Open last year could provide some insight here). There definitely is an interest from GIS users, but I've yet to see a single (online) map where conical gradient fills are used.
For most Inkscape users final file format is either PNG or PDF, and Inkscape does rasterization in both cases.
There's quite a number of features Inkscape does not have simply because SVG does not support them yet and will not support in the foreseeable future. We cannot speed up development of the standard, so we either find workarounds keeping in mind who our users are, or continue to concentrate on tasks that don't require workarounds. We've done a damn good job with the last option, but IMO we could have done much better with both of them.
Alexandre
On Mon, 2009-03-30 at 23:00 +0300, Alexandre Prokoudine wrote:
On Mon, Mar 30, 2009 at 4:24 PM, Ted Gould wrote:
I understand that it's valid SVG. But, it's against the spirit of a vectored format.
It seems to me that we are slowly drifting to the "right vs. comfortable" type of discussion :) I'm afraid that by being overidealistic we are hurting ourselves.
Your thinking that I'm being an SVG idealist, which is simply not the case. Actually what I'm being is a pessimist on our ability to keep the project at a high level if we allow for the bitmap fallback option. It's easy, it's simple, and it's ugly. And, right now, I'm not convinced it is necessary.
If we accept a bitmap fallback option would there be such a thing as LPEs? One of the hardest things there is figuring out how to connect it back into a path and make it reasonable for future editing. I think that, if we allowed bitmap fallbacks, it would be unlikely that we'd have such a cool feature that required a fair amount of upfront leg work for a very interesting result. I'm not convinced that upfront work would have happened without a policy of being able to show up in other SVG renderers.
I'm not fan of the SVG standardization process. I've bitched about it publicly and privately, and I think I even have complained to Chris Lilley about it at LGM. But, that doesn't mean that we should effectively abandon it. Quite the contrary. The reality is by sticking to a standard for our format, we've both simplified and added complexity to Inkscape. But, what we've removed 100% is dealing with format issues and debating them on this list. Formats are tricky, and difficult to get right, I'd hate to be in the business of doing just that.
Since it seems that I'm a minority opinion on this issue, I'll stick to trying to limit the spread of this cancer in the codebase. What I'd like to see is that for every bitmap fallback, it's *proven* that what we're falling back on can't be implemented in SVG. Explain the solutions that have been tried and why they can't work. The whole thing. I'd like it to really be a last resort.
--Ted
Ted Gould wrote:
... Since it seems that I'm a minority opinion on this issue, I'll stick to trying to limit the spread of this cancer in the codebase. What I'd like to see is that for every bitmap fallback, it's *proven* that what we're falling back on can't be implemented in SVG. Explain the solutions that have been tried and why they can't work. The whole thing. I'd like it to really be a last resort.
What about "approximating" a conical gradient with feDiffuseLighting on an actual cone? This seems to give reasonably good results by itself, and if need be we could probably improve the approximation with things like feComponentTransfer and feComposite (possibly even dividing the space into separate regions so each region can be approximated individually). It should be possible to get a quite good approximation this way.
If you're wondering what to do about gradients with multiple stops and stuff like that, if worst comes to worst we could always resort to using the computed values for a lookup using feDisplacementMap.
If you're wondering what to do about gradients with multiple stops and stuff like that, if worst comes to worst we could always resort to using the computed values for a lookup using feDisplacementMap.
Can you please post an example image? I'd like to know how it would look like.
Regards, Tobias
Tobias Jakobs wrote:
If you're wondering what to do about gradients with multiple stops and stuff like that, if worst comes to worst we could always resort to using the computed values for a lookup using feDisplacementMap.
Can you please post an example image? I'd like to know how it would look like.
No example image yet, but I started a Wiki page on how we could approximate more advanced gradients: http://wiki.inkscape.org/wiki/index.php/Advanced_Gradients
Feel free to comment and/or expand on the ideas there. I'll have a look later to see if I can whip up some more.
There is currently lots of <math> stuff that doesn't look right (because the Wiki doesn't seem to support it). I hope that we can simply enable that for our Wiki. And otherwise I'll take care of that later.
Jasper van de Gronde wrote:
No example image yet, but I started a Wiki page on how we could approximate more advanced gradients: http://wiki.inkscape.org/wiki/index.php/Advanced_Gradients
Feel free to comment and/or expand on the ideas there. I'll have a look later to see if I can whip up some more.
There is currently lots of <math> stuff that doesn't look right (because the Wiki doesn't seem to support it). I hope that we can simply enable that for our Wiki. And otherwise I'll take care of that later.
I'm not sure if this is relevant to the discussion but since advanced gradients (that are not in SVG) are mentioned it might be worthwhile to take a look at Diffusion Curves http://artis.imag.fr/Publications/2008/OBWBTS08/ It's amazing how complex illustrations can be created with so few objects, they're very artist friendly.
On Tue, Mar 31, 2009 at 9:47 PM, Mihaela wrote:
I'm not sure if this is relevant to the discussion but since advanced gradients (that are not in SVG) are mentioned it might be worthwhile to take a look at Diffusion Curves http://artis.imag.fr/Publications/2008/OBWBTS08/ It's amazing how complex illustrations can be created with so few objects, they're very artist friendly.
They are on radar for a while now :)
Alexandre
On Tue, 2009-03-31 at 21:53 +0300, Alexandre Prokoudine wrote:
On Tue, Mar 31, 2009 at 9:47 PM, Mihaela wrote:
I'm not sure if this is relevant to the discussion but since advanced gradients (that are not in SVG) are mentioned it might be worthwhile to take a look at Diffusion Curves http://artis.imag.fr/Publications/2008/OBWBTS08/ It's amazing how complex illustrations can be created with so few objects, they're very artist friendly.
They are on radar for a while now :)
What else is on the radar that I may have never seen before? :) Because that's pretty dang nifty. Other than this, meshes, and shapeburst gradients, what other kinds of super-nifty ones exist?
Cheers, Josh
P.S. Thanks for sharing that Mihaela!
-----Original Message----- From: Joshua A. Andler [mailto:scislac@...400...] Sent: 01 April, 2009 02:52 To: Alexandre Prokoudine Cc: Inkscape Devel List Subject: Re: [Inkscape-devel] more gradients
On Tue, 2009-03-31 at 21:53 +0300, Alexandre Prokoudine wrote:
On Tue, Mar 31, 2009 at 9:47 PM, Mihaela wrote:
I'm not sure if this is relevant to the discussion but since advanced gradients (that are not in SVG) are mentioned it might be worthwhile
to
take a look at Diffusion Curves http://artis.imag.fr/Publications/2008/OBWBTS08/ It's amazing how complex illustrations can be created with so few objects, they're very artist friendly.
They are on radar for a while now :)
What else is on the radar that I may have never seen before? :) Because that's pretty dang nifty. Other than this, meshes, and shapeburst gradients, what other kinds of super-nifty ones exist?
Simplex noise http://webstaff.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf
Preben
Cheers, Josh
P.S. Thanks for sharing that Mihaela!
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Tobias Jakobs wrote:
If you're wondering what to do about gradients with multiple stops and stuff like that, if worst comes to worst we could always resort to using the computed values for a lookup using feDisplacementMap.
Can you please post an example image? I'd like to know how it would look like.
I've posted a few examples on-line: http://home.hccnet.nl/th.v.d.gronde/gradients/
The idea is documented on, feel free to comment, improve, etc.: http://wiki.inkscape.org/wiki/index.php/Advanced_Gradients (Sorry, not nicely formatted math, yet.)
However, as you can see on that page the rendering is not (yet) very pretty. With the linear gradient it's not too bad, but the conical gradient is quite bad. In addition, there is a reason I rendered those with Batik, Inkscape's filters are not yet able to properly render them. On the other hand I guess these make nice test cases :)
The quality of the renderings can definitely be improved by using higher bit-depths, higher quality implementations of the filters and increasing the complexity (for example by segmenting the region). But of course there may still be better ways to create a conical gradient (or any other gradient) that I haven't found yet.
On Tue, 2009-03-31 at 12:48 +0200, Jasper van de Gronde wrote:
Ted Gould wrote:
... Since it seems that I'm a minority opinion on this issue, I'll stick to trying to limit the spread of this cancer in the codebase. What I'd like to see is that for every bitmap fallback, it's *proven* that what we're falling back on can't be implemented in SVG. Explain the solutions that have been tried and why they can't work. The whole thing. I'd like it to really be a last resort.
What about "approximating" a conical gradient with feDiffuseLighting on an actual cone? This seems to give reasonably good results by itself, and if need be we could probably improve the approximation with things like feComponentTransfer and feComposite (possibly even dividing the space into separate regions so each region can be approximated individually). It should be possible to get a quite good approximation this way.
If you're wondering what to do about gradients with multiple stops and stuff like that, if worst comes to worst we could always resort to using the computed values for a lookup using feDisplacementMap.
I think that sounds interesting. I was looking at using a couple of radial gradients and a custom composition function. I keep getting bogged down in some of the math though. Your way sounds cleaner, mock it up, let's get a few ideas out there :)
--Ted
On Tue, Mar 31, 2009 at 6:24 PM, Ted Gould wrote:
I think that sounds interesting. I was looking at using a couple of radial gradients and a custom composition function. I keep getting bogged down in some of the math though. Your way sounds cleaner, mock it up, let's get a few ideas out there :)
Still it would be great if somebody commented at https://bugs.launchpad.net/bugs/346681, because it's two weeks since the original submission of a patch that adds a major feature. Could we be a little nicer to the guy please?
Alexandre
On Sun, 2009-03-29 at 21:34 -0500, Ted Gould wrote:
I completely disagree on where this thread is going. I think of SVG like x86 byte code, it sucks in many ways, but by sticking with it we get lots of gains. For one, we have an entire committee who deals with compatibility issues for us :)
Does it deal with the compatibility issues of our users creative needs and a slowly evolving format? ;)
WRT the radial gradients I don't understand why the same techniques that Bulia came up with for the gradient meshes can't be used. I believe the attached file is roughly a radial gradient from black to white in the middle of a rectangle. And there's no reason we can't detect the meta data and render it in our own implementation in a faster way, but this should be vector in Firefox also.
I'm not saying I'm committed to the bitmap solution. Nor do I believe anyone else did. It was one (of many possible) workarounds available, and would be one that would be more performance friendly to other renderers.
Cheers, Josh
All,
OK there is an obvious set of problems that you can't currently solve in SVG 1.1, and the extensions in SVG 1.2 only go so far.
But Inkscape needs at authoritative master source format. You can't go round creating images that others can't edit, it's just not good enough.
Using SVG is a very good way of allowing re-editing.
But having editable elements that are none vector based is a maddening situation. What am I to do if I want to make something to print on the moon? Do I have to save a special 4 billion pixels per inch version?
No, no no, this won't do at all. Go back, join the SVG W3C forum and get SVG 1.3 spec written up, if your so desperate for meshes and spirals. There is such a thing as doing a half asrsed hack in the standards world.
I have no problems with group element extensions. No issues with render level filters. But raster objects that are only editable in inkscape? Hell no!
Sweetest Regards, Martin
On Sat, 2009-03-28 at 13:32 -0700, Joshua A. Andler wrote:
On Sat, 2009-03-28 at 13:17 +0000, john cliff wrote:
I'd be no less SVG compliant than Illustrator, which does exactly what I'm suggesting to get round this sort of issue. Its also what we do to blurs etc when we write them to PDF, so theres precedent in the codebase already...
Personally SVG is the means to the end, not the end in itself.
Same here. I do think your proposed bitmap solution is a good way to work around the problem of other SVG renderers (first thing that popped into my head too). As much as we all love SVG and standards, SVG evolves slowly. I'd argue that we should focus on making our program more standards compliant before we start pushing beyond the current standard, however, someone had a creative itch to scratch and they did (and will probably continue to if we support them).
It seems like a lot of people want a more creatively powerful tool than SVG will currently allow (if everything is to remain scalable in other renderers). Given that, are we willing to do things less elegantly due to current SVG limitations in the name of empowering of our users?
The other side of this, what if these features do get added to the SVG standard one day and it's radically different than how it's already implemented in Inkscape. This more than likely creates a "breaking a feature" backwards compatibility issue for our users' documents... and we haven't even been willing to do this for Spirals (I seem to recall that they're not "right" formula-wise).
Cheers, Josh
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Mar 30, 2009 at 6:31 PM, Martin Owens <doctormo@...400...> wrote:
All,
OK there is an obvious set of problems that you can't currently solve in SVG 1.1, and the extensions in SVG 1.2 only go so far.
But Inkscape needs at authoritative master source format. You can't go round creating images that others can't edit, it's just not good enough.
Okay, what about Live Path Effects that other editors can't edit the same way? Spirals? Stars? Rectangles? Ellipses? Our flow-text? Yeah, there are ways to edit them... but not in a very user friendly way compared to Inkscape.
Using SVG is a very good way of allowing re-editing.
Except for all of the Inkscape specific stuff which doesn't allow for easy re-editing in other programs.
I have no problems with group element extensions. No issues with render
level filters. But raster objects that are only editable in inkscape? Hell no!
For the 10th time, no one said this is a final conclusion for "the best" workaround... it was one of a couple proposed to work around the limitations of SVG. Additionally, we've already discussed having an option to disable any such tools for users that don't want to use them.
Again... with the stipulation that all non-scalable editing features abide by the "non-standards off switch", THIS IS A NON-ISSUE!
Hey Josh,
Okay, what about Live Path Effects that other editors can't edit the same way? Spirals? Stars? Rectangles? Ellipses? Our flow-text? Yeah, there are ways to edit them... but not in a very user friendly way compared to Inkscape.
I would argue that these are just mathematical conveniences. Just like the proposal I made that certain group elements be treated like extended objects with special editing functionality (see barcodes) But You can still edit these shapes, if you knew what you were doing you could reshape a star or barcode into a new form. You can't reshape a raster image, it's fixed.
Except for all of the Inkscape specific stuff which doesn't allow for easy re-editing in other programs.
Not easy no, but at least it's possible, and it would also be useful to get some of those things put into a spec too.
For the 10th time, no one said this is a final conclusion for "the best" workaround...
That's the problem, I'm against workarounds. You shouldn't have to fight your authoritative format specification.
it was one of a couple proposed to work around the limitations of SVG. Additionally, we've already discussed having an option to disable any such tools for users that don't want to use them.
Yes, and I can see how that could be demanded, but then I'd have to explain to people how I have to reject their poster because it's not printable because it doesn't follow the vector only guidelines. Even though they didn't know it.
Even the off switch solution is just a breeder of ignorance and complexity.
Regards, Martin
On Tue, 2009-03-31 at 10:15 -0400, Martin Owens wrote:
Hey Josh,
Hey Martin,
it was one of a couple proposed to work around the limitations of SVG. Additionally, we've already discussed having an option to disable any such tools for users that don't want to use them.
Yes, and I can see how that could be demanded, but then I'd have to explain to people how I have to reject their poster because it's not printable because it doesn't follow the vector only guidelines. Even though they didn't know it.
I would even go as far to say that it should be off by default.
Even the off switch solution is just a breeder of ignorance and complexity.
For the record, this whole "more gradients" discussion started because Alexandre wanted to make sure we didn't ignore a new contributor to the project. I think that one of the things that has brought us all together here over the years is the open, approachable, and friendly community. So, a key with this whole thing is that we had someone who already wrote something, but, unfortunately we can't accept the patch as-is because it's not SVG friendly.
So really, we just need figure out what guidance and feedback can be given to make it acceptable... and again, the bitmap thing was one of many proposed solutions, and the one Jasper just recently proposed WOULD be scalable. (we'd just need to see it in action) :)
Cheers, Josh
On Tue, Mar 31, 2009 at 5:31 AM, Martin Owens wrote:
OK there is an obvious set of problems that you can't currently solve in SVG 1.1, and the extensions in SVG 1.2 only go so far.
But Inkscape needs at authoritative master source format. You can't go round creating images that others can't edit, it's just not good enough.
Using SVG is a very good way of allowing re-editing.
Martin, with all respect due you seem to be missing the point that conical/spiral gradient fills *are* re-editable in Inkscape. Why don't you just apply the patch and try it yourself? :)
But having editable elements that are none vector based is a maddening situation. What am I to do if I want to make something to print on the moon? Do I have to save a special 4 billion pixels per inch version?
A word comes to mind: workflow :) When you go for printing, you export to PDF. And if you ever exported to PDF from Inkscape you would notice that you can select resolution. We do rasterization for blurs and SVG filters on exporting to PDF *already*. Just how much different would it be?
No, no no, this won't do at all. Go back, join the SVG W3C forum and get SVG 1.3 spec written up, if your so desperate for meshes and spirals.
Now I'm officially getting tired of that thread. SVG 1.1 which we rely on dates back to 2001. SVG 1.2 with its modules is not even finished, and it's 2009 here. SVG 1.3 is out of question for next gazillion of years. I'm sorry, but what was the point of your angry email?
Alexandre
Martin, with all respect due you seem to be missing the point that conical/spiral gradient fills *are* re-editable in Inkscape. Why don't you just apply the patch and try it yourself? :)
Ah yes, "In Inkscape", Yes it's a lovely feature. Too bad it's not an honest feature. You going to make this very complex and not very clean in the end, random things will be rendered into raster just like Microsoft Publisher 97. Yuk.
But having editable elements that are none vector based is a maddening situation. What am I to do if I want to make something to print on the moon? Do I have to save a special 4 billion pixels per inch version?
A word comes to mind: workflow :) When you go for printing, you export to PDF. And if you ever exported to PDF from Inkscape you would notice that you can select resolution. We do rasterization for blurs and SVG filters on exporting to PDF *already*. Just how much different would it be?
And now that I know that, it explains why I had such horrible results exporting to PDF recently and had to manual go in and remove anything with transparency and bluring. Pravo, my workflow was wrecked and I didn't even know it was inkscape, I just thought it was the PDF format.
but what was the point of your angry email?
It wasn't angry, it was sardonic. We shouldn't have to have this discussion.
Regards, Martin
On Tue, Mar 31, 2009 at 6:22 PM, Martin Owens wrote:
And now that I know that, it explains why I had such horrible results exporting to PDF recently and had to manual go in and remove anything with transparency and bluring. Pravo, my workflow was wrecked and I didn't even know it was inkscape, I just thought it was the PDF format.
Obviously not everything can be expressed in terms of vectors.
but what was the point of your angry email?
It wasn't angry, it was sardonic.
What a perfect excuse
We shouldn't have to have this discussion.
Yes, we definitely shouldn't have a **sardonic** discussion. I see no reason why there shouldn't be a normal polite one. Too bad you don't want one.
Alexandre
Sent from my iPhone
On 31 Mar 2009, at 15:22, Martin Owens <doctormo@...400...> wrote:
Martin, with all respect due you seem to be missing the point that conical/spiral gradient fills *are* re-editable in Inkscape. Why don't you just apply the patch and try it yourself? :)
Ah yes, "In Inkscape", Yes it's a lovely feature. Too bad it's not an honest feature. You going to make this very complex and not very clean in the end, random things will be rendered into raster just like Microsoft Publisher 97. Yuk.
Wow, a comparison to publisher talk about an insult... We're not talking about random things, we're talking about a very specific feature, that we're proposing be disablable (that's prob not a word but I really don't care..)
But having editable elements that are none vector based is a maddening situation. What am I to do if I want to make something to print on the moon? Do I have to save a special 4 billion pixels per inch version?
No, print it from inkscape...
A word comes to mind: workflow :) When you go for printing, you export to PDF. And if you ever exported to PDF from Inkscape you would notice that you can select resolution. We do rasterization for blurs and SVG filters on exporting to PDF *already*. Just how much different would it be?
And now that I know that, it explains why I had such horrible results exporting to PDF recently and had to manual go in and remove anything with transparency and bluring. Pravo, my workflow was wrecked and I didn't even know it was inkscape, I just thought it was the PDF format.
It is the PDF format, it has no support for blur or other filters. Again, what are we meant to do?
but what was the point of your angry email?
It wasn't angry, it was sardonic. We shouldn't have to have this discussion.
Great, so it wasn't angry, it was just derisively mocking, sorry that the difference got lost in the written nature of the discussion, I took it as angry too. And if we didn't have the discussion then we wouldn't know there were users that cared quite this much would we?
Regards, Martin
participants (16)
-
Alexandre Prokoudine -
bulia byak -
Ivan Louette -
Jasper van de Gronde -
john cliff -
John Cliff
-
Jon A. Cruz -
Josh Andler -
Joshua A. Andler -
Martin Owens -
Mihaela -
Nicu Buculei -
Preben Soeberg -
Ted Gould -
Thomas Worthington -
Tobias Jakobs