I am sorry but GIMP doesn't use librsvg, at least not in the core where
gradients are handled. librsvg also wouldn't help for loading SVG gradients
since all it does is rendering an SVG file to a raster image.

As far as I understand your bug-report is about adding the ability to load
gradients from SVG files. I don't think this belongs into GIMP. It can be easily
implemented in a script that converts these SVG files to the GIMP gradient format.
We could include such a script in the tools directory if someone wants to write it.

BTW, the gradients at http://www.openclipart.org/cgi-bin/navigate/Gradients lack
a proper XML header as well as an SVG namespace declaration. You should
definitely get them changed so that they become valid SVG files.

> As far as I understand your bug-report is about adding the ability to load
gradients from SVG files.

Yes that is it exactly

> doesn't use librsvg, at least not in the core where gradients are handled

okay I was hoping that librsvg could be reused but i guess not 

I want to be able to use standardised interoperable file formats and use the
same files for both the Gimp and Inkscape (and other apps).  
Converting and duplicating the files would not be what I had in mind at all (I
know they are small but I dont want to keep two different sets, there are over
100 of them already).  

With the addition of gradient-fu I might be able to script something.    

I'll see about validating the SVG files.  Some of the files are propererly
validated but I think the ones that contained named colours instead of hex
values were not automatically given the xml header and namespace declaration.  

It would certainly make sense to switch to a standardized file format for
gradients. SVG gradients are however non-trivial to parse and I don't think they
are well-suited as a replacement for the GIMP gradient format. Perhaps in the
long run when GIMP starts to make use of a real XML parser...

I wasn't thinking of a script that imports the files at run-time. It should be a
lot simpler to write a conversion script between the two file formats.

I had a closer look at the SVG spec. Actually I have most of the code written
for a SVG gradient loader but when I looked again at your gradients I found that
the gradient stops do not adhere to the SVG specification. But perhaps I am only
interpreting the spec wrongly. A typical gradient stop from one of your
gradients looks like this:

  <stop offset="50%" style="stop-color:blue;stop-opacity:1" />

The example gradient in the SVG spec however has this:

  <stop offset="0.5" stop-color="blue" />

Is there a particular reason to use CSS here even though the SVG spec defines a
clean (and easily parseable) way of defining the stop color? I don't think I
want to add a CSS parser to GIMP so that would pretty much block this feature
request.

The gradients were produced using Jasc Web Draw (and a text editor), presumably
as they needed to implement styles anyway for the rest of the application it was
easier to do it that way (it is also possible that it is due to an option i
ticked).  

I looked at a file generated by Inkscape it does gradients this way too
<stop
         style="stop-color:#000000;stop-opacity:0.41237113;"
         offset="0.0000000"
         id="stop1562" />

I see that in this example the linear gradient is done as you describe
http://www.w3.org/TR/2001/PR-SVG-20010719/pservers.html
But also the examples gradients in these older documents styles them
http://www.w3.org/TR/2000/CR-SVG-20000802/pservers.html#LinearGradients
http://www.w3.org/TR/2000/03/WD-SVG-20000303/pservers.html#LinearGradients
      <linearGradient id="MyGradient">
        <stop offset="5%" style="stop-color:#F60"/>
        <stop offset="95%" style="stop-color:#FF6"/>
      </linearGradient>

Changing to not use styles may just be a trivial change (hopefully) that has no
side effects.  I'll need to check Inkscape and WebDraw and get back to you.  

Added a first version of the parser code to CVS. Works for gradients that
specify the color using the attributes described in the spec. Needs more work
though...

2004-07-22  Sven Neumann  <sven@gimp.org>

	* app/core/gimp.c
	* app/core/gimpgradient-load.[ch]
	* app/core/gimpgradient.h: added preliminary support for loading
	simple SVG gradients (see bug #148127).  Be careful with this new
	feature; editing the loaded gradient will cause the SVG file to be
	overwritten! Work in progress...

These are the problems that still need to be addressed:

- The SVG XML parser needs to be changed to also handle gradients that are
  not defined at the top-level. Could perhaps even share code with the vectors
  SVG parser.

- If the SVG is placed in the users gradient folder, the loaded gradient will
  be editable and GIMP will overwrite the SVG with the GIMP gradient format
  then. Editing should be disabled, we can seek for a better solution later.

- It would make sense to add a very simple CSS style parser. This code could
  also become useful if we want to import stroke styles one day.

- Error handling in the parser is not perfect yet. This is pure lazyness,
  can be easily fixed.

Dealt with most of the problems:

2004-07-23  Sven Neumann  <sven@gimp.org>

	* app/core/gimpgradient-load.c: changed SVG parser to handle
	gradients that are defined more deeply in the SVG hierarchy. Added
	a simplistic CSS style parser to deal with gradient definitions
	that use CSS to define the gradient stop properties (closes bug
	#148127).

2004-07-23  Sven Neumann  <sven@gimp.org>

        * app/core/gimpgradient-load.c (gimp_gradient_load_svg): fixed
        error handling.

Despite my comment in the ChangeLog, the bug should better be kept open until
the gradient is marked as read-only. This will need changes to GimpDataFactory.

> it is also possible that it is due to an option i ticked

I had chosen to use CSS formatting instead of pure XML formattting which
produces gradients formatted wiht stop-color and stop-opacity as parameters as
you were expecting.  

I'll have to check Inkscape and OpenClipart but I'm sure that they also want to
use the best, homogenous, most compatible SVG possible.  

I can make the changes if they are still necessary but it could take quite a
while.  

I would like to inform the Inkscape developers of this new functionality, and I
would have done so already but I thougth you might want to do so yourself.  
I hope they will be as pleased and as impressed as I am.  

After some more fixes which are now in CVS, all gradients from the clipart
collection seem to be loaded correctly now. Further testing and feedback would
be appreciated.

I am closing this bug-report now. Will open a new one for the GimpDataFactory
problem. There are also some enhancements that could be requested (but would not
necessarily be handled immidiately):

 - DND of SVG gradients (for example drag from Sodipodi to the GIMP blend tool
   options). Of course this will need support from sodipodi and inkscape.

 - Load multiple gradients from a single SVG. Trivial to implement in the
   but doesn't quite work with GimpDataFactory since it assumes a file per
   data object.

Should read "Trivial to implement in the parser..." of course.

GimpDataFactory has been changed, gradients loaded from SVG are marked as
read-only now. We have also changed the code to load all gradients from an SVG,
not only the first one.

We would also like to add support DND of gradients but only if sodipodi or
inkscape developers signal interest in implementing their part. Alan, can you
send a mail to their mailing-lists? I don't feel like subscribing to more lists.

Alan, there's one thing I'd like to suggest for the SVG gradients: At the moment
if you render the SVG gradient files with an SVG viewer or a converter like rsvg
you end up with an empty image. Only minor changes would be necessary to let the
SVG render a preview of the gradient. File managers such as nautilus could then
display thumbnails for them.

Here's an example of modified SVG file (metadata omitted):

<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
        "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="500" height="100">
  <g>
    <defs>
       <linearGradient id="bruce-lee-game-of-death" x1="0%" y1="0%" x2="100%"
                       y2="0%" spreadMethod="pad" gradientUnits="objectBoundingBox">
         <stop offset="0%"    style="stop-color:yellow;stop-opacity:1"/>
         <stop offset="42.5%" style="stop-color:yellow;stop-opacity:1"/>
         <stop offset="42.5%" style="stop-color:black;stop-opacity:1"/>
         <stop offset="47.5%" style="stop-color:black;stop-opacity:1"/>
         <stop offset="47.5%" style="stop-color:yellow;stop-opacity:1"/>
         <stop offset="52.5%" style="stop-color:yellow;stop-opacity:1"/>
         <stop offset="52.5%" style="stop-color:black;stop-opacity:1"/>
         <stop offset="57.5%" style="stop-color:black;stop-opacity:1"/>
         <stop offset="57.5%" style="stop-color:yellow;stop-opacity:1"/>
         <stop offset="100%" style="stop-color:yellow;stop-opacity:1"/>
       </linearGradient>
    </defs>

    <rect fill="url(#bruce-lee-game-of-death)" stroke="black" stroke-width="5"
          x="0" y="0" width="100%" height="100%"/>
  </g>
</svg>

Is there an OpenClipart Bugzilla where I could submit this enhancement request?

I've tried and tried again but I'm reluctant to do that because I makes it
impossible to use the files with Jasc Webdraw which is the very program I
created them with.  However, adding the RDF required by Openclipart.org also
breaks WebDraw but they provide a (perl) script to both annotate as well as
strip out any annotations.  (I'd like OpenClipart.org to make an effort to
support more than just Inkscape).   

For the website someone created a script (perl agian i believe) that
automatically creates a object that uses the gradient, I'll ask them if they can
add a function to strip it out as well so that the crappy parser of Jasc Webdraw
can still be supported.  with a bit of luck you will probably have the change
you want for the next release or two.  
 
I also tried looking at it from the other direction and asked if perhaps librsvg
could be modified to provide thumbnails of files that contain only a definition
(gradients, patterns) but it was immediately rejected (by Dom.  I wasn't
suprised to be honest it was a long shot).  

I do feel a little bit bad about drastically reducing the user experience for
Gnome/KDE users but I'd feel more stupid if I there was no way to open the files
in the very program that was used to create them.  Part of my reason for being
so obtuse was to give the Inkscape developers more reason to improve their
gradient support and to move OpenClipart towards starndardising and homogenising
the SVG being used and for it really to be more than just an extension of
Inkscape.  

(The OpenClipart list has already taken note of the ability to import SVG
gradients into the GIMP and they seem very pleased.  I intend to check my
backlog of messages and inform the Inskcape developers this evening in case they
do not also subscribe to the openclipart list).  

In summary: I'll probably be doing exactly what you suggest eventually, but I'm
reluctant to do it straight away.  

I agree with Dom for not adding such an arbitrary hack, The modifications to the
SVG that are needed to make it render the gradient are trivial.  Changing the
renderer would be stupid. Jasc Webdraw is the tool that needs to be fixed here.
If that is impossible, it should be simple to modify the script that adds the
Creative Commons License so that it takes care of this.

> Is there an OpenClipart Bugzilla where I could submit this enhancement request?

There is now a bug tracker for openclipart.org online:
http://openclipart.org/mantis/main_page.php