On May 9, 2007, at 8:07 AM, Aurélio A. Heckert wrote:
Thanks! You help the idea! Change on my proposal:
The svg:image and openraster:image still existing forever. Like that: <image id="image123" xlink:href="data:image/png;base64..." inkscape:orlink="#or123" /> <openraster:image id="or123"> openraster:layers <openraster:brightness-contrast contrast='1.4'/> <openraster:layer src='img.jpg'/> </openraster:layers> </openraster:image>
When a image is selected the Inkscape knows the OpenRaster reference and allow the user to change the OpenRaster defs by some "Raster Properties" window. When it is updated, a new PNG image data is updated on <images>'s xlink:href attribute.
Well. The designer boss will be happy and the SVG will still viewable for other programs. :-)
OK. This is sounding good, and close to how I would imagine the workflow to function.
First of all we have three files involved. 1) the SVG file. 2) the 'result' image file that gets published (PNG or JPEG) 3) the 'source' image file that is original content and is preserved.
Although adding some openraster inline at some point might be good, at this point in time I think external support might work well enough. That is, we could get a similar workflow by having just an extra attribute to specify the 'source' image. Then when the user right-clicks on the image, he well be presented an "Edit original" option in the menu. This then would allow an openraster image to be used for the source, and to be manipulated from within an openraster program. The way I see it, the workflow would be close to embedding openraster directly.
*However*
We do happen to have a Summer of Code project being done by Christopher Brown that aims to add some raster functionality to Inkscape itself. I believe that the proposed support would benefit from the option to have a source image to allow for non-destructive editing.
A second thing would be to craft the SoC implementation so that it could easily be extended to use openraster at some point in the future when there is a viable library for it. (The subject came up this past weekend at LGM, and at the moment there is not yet a library for it. Nor does it make sense for them to start with a library, since Krita and Gimp have such different internals, etc.)