Jon A. Cruz wrote:

On May 8, 2007, at 6:29 PM, Aurélio A. Heckert wrote:

...

The inkscape can have a suport for the OpenRaster format and allow

the OpenRaster name space on the SVG XML.

When we try to change the contrast on a raster image the XML

changes from:

<image xlink:href="img.jpg" />

to this:

openraster:image

<openraster:layers>

    <openraster:brightness-contrast contrast='1.4'/>

    <openraster:layer src='img.jpg'/>

</openraster:layers>

</openraster:image>

We can use the menu "object > raster > aplay raster changes"

and the OpenRaster block comes to a svg:image. It will

help to send the SVG file to other softwares.

Well... the first problem is that SVG only requires software to support PNG, JPEG and SVG, so we really can't have <image> tag linked to anything else and still stay universal.

The second, and larger, problem is that switching from using standard SVG <image> conventions to some custom namespace will make the SVG file non-standard. That is, if we send the SVG over to an arbitrary program that handles SVG, it will not display correctly unless the destructive change back to <image> has taken place.

To balance that we could just have the linked <image> updated whenever the openraster parts are updated, but that looses a bit.

Isn't there a <foreignObject> tag or something like that which is analogous to the <object> tag in HTML?

Tim Rowley (the other <tor>) from IBM is the Mozilla guy who worries about the problems with SVG in a browser, with all of its issues. Maybe he would be the best guy to ask.

bob

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.)