2009/3/30 Ted Gould <ted@...>:
> On Mon, 2009-03-30 at 07:13 +0100, John Cliff wrote:
>> On 30 Mar 2009, at 03:34, Ted Gould <ted@...> 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 :)
>> 1. 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?
>> 2. 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.
>> 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 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
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...