On Fri, Mar 13, 2009 at 10:09 AM, Sven Neumann <s...@gimp.org> wrote:
> Hi,
> On Wed, 2009-03-11 at 22:22 +0530, sumith pandilwar wrote:
>> by adding support for svg files i would like to add the feature to
>> import svg file and modify its properties like colour, fade out etc
>> and use it like a brush.This would be like totally creating a new
>> brush of our own
> OK, let's have a look at using SVG for brushes in GIMP. With the current
> state of brush transformations in trunk, we are nicely prepared for
> vector brushes. Brush transformations currently are affine
> transformations and as such they can easily be applied on an SVG. So all
> that is needed is to create a new brush type GimpBrushVector similar to
> GimpBrushGenerated. This vector brush would load its data from an SVG
> file. If we accept linking the core against librsvg we can easily import
> any SVG file and render it using rsvg_handle_render_cairo(). Being able
> to render the brush to a Cairo surface is an extra plus as that will
> allow the paint tools to render a nice brush preview on the canvas as
> soon as we finally port tool drawing to Cairo.
> It's not clear though how exactly an SVG file that represents a brush
> should be interpreted. What I described above basically means we just
> treat it as a scalable image. Basically all SVG images could be used as
> brushes then and would behave like pixmap brushes except that they would
> look better when transformed. Probably not exactly what we want. We also
> need the notion of grayscale vector brushes that define a brush mask
> that is colored by the foreground color. We also need meta information
> such as the brush name and the default brush spacing. It's not entirely
> clear to me how such an SVG brush should look like. Do we expect
> GIMP-specific XML elements in the SVG ?

I think we would have to. At least, in my vision, where we want
GIH/GBR to be eventually deprecated in preference of SVG. This would
require 2 things:
 a) support multiple brushes in a SVG brush file, ala GIH (presumably
a group for each brush)
 b) support including ranks etc. information in the SVG brush file.
IMO a GIMP-specific XML element is appropriate here, for that and
brush rendering type information as you said. Probably require a
specific naming scheme, to simplify implementation of ranks.

For bitmap images in SVG brush files (eg. for patterning), we will
probably want to use embedded images. Eventually for parametrizable
brushes, we'll want to support external bitmap references (in which
case we'll need to consider how to ensure that the user gets the right
resources and that reference links are resolved correctly (probably
relative to the .gimp-2.X/ toplevel directory)).
Does inkscape do this kind of embedding? How is it accessed?

Eventually, I would expect that we could have things like brushes with
FGcolor on one side and BGcolor on the other by binding SVG object
attributes to gimp context attributes. An initial SVG brush
implementation IMO should be careful not to get in the way of this
kind of binding (mainly by respecting the possibility that the
'pixels' of a brush may change, just like gradients with FG/BG
embedded do.)

Lastly (and more distantly): Deluxe paint had a 'Animbrush' feature
which was extremely nice for animating moving objects (simple or
complex). http://www.youtube.com/watch?v=5fF1OYaobPA demonstrates how
it works. IMO this is a very helpful feature and we should accommodate
the possibility of an eventual implementation. GIH's 'sequential'
selection method comprises part of this. The other might be a method
to hook frame-flipping (so GAP could implement it's own notion of
frame flipping).

Anyway, IMO a basic SVG brush implementation would be about as simple
as you've said.

Gimp-developer mailing list

Reply via email to