Partial SVG backend

[Ralith]

Lightly tested; produces output similar to the cairo backend for test images 1, 3 and 4. Attempts to use text and images will produce NotSupported error; the unimplemented invocations are all statically unreachable as a result.

For some reason I couldn't get SVG line elements to display, but paths work fine and are more concise anyway.

[Ralith]

Implementing TextLayout faithfully would present some challenges because we're not actually rendering anything. At minimum, I think we'd need to pull in a text shaping engine (perhaps behind a feature flag) and disclaim any prospect of correctness if the document isn't displayed using exactly the same fonts that were specified when generating the file.

Images present a different challenge: we can embed base64'd png or jpeg (or other?) data, but calling out to an image encoder when someone calls make_image is pretty weird. This could also be behind a feature flag, and configured (to e.g. select codec and compression level) via inherent methods.

[Ralith]

A better solution to the text issue might be to render text as paths, for which there at least exists an authoritative answer to the queries. Shame not to have working copy/paste though.

[raphlinus]

Generally this looks like a good start. I'm ok with this going in unfinished, but would like at least a short docstring at the module level explaining that, and at least a one line docstring for all public interfaces.

From what I can tell, images are largely a function of resource linking. But these could be done as base64 data uri's?

Text is going to be difficult. I'm not a fan of flattening to paths, as I think a large part of the value of SVG is preserving some structure. Longer term, we should probably have some plan for working with real fonts, but they present at least as many problems as images.

[raphlinus]

Naming doesn't follow the pattern, this should be "basic-svg.rs". That said, I agree the naming scheme is not ideal, and the d2d one also doesn't follow the pattern.

[Ralith]

Thanks for the review!

From what I can tell, images are largely a function of resource linking. But these could be done as base64 data uri's?

We can easily add backend-specific methods for linking external resources, and probably that's what we should direct users towards here. My concern is mainly about implementing make_image, which consumes raw bitmap data. Pulling in an image codec just to support a really ugly and inefficient embedding is unfortunate, and hardwiring any one codec would tend to give bad results for many inputs. Is there maybe a way to encode raw bitmap data in a data URI directly?

[RazrFalcon]

Is there maybe a way to encode raw bitmap data in a data URI directly?

AFAIK, SVG allows only image/png, image/jpeg and image/svg+xml.

[raphlinus]

It's a good question. It's certainly possible to generate a PNG without actually doing compression, so if we really didn't want to depend on any other crates, it's possible. But I think perhaps the best thing to do here is pull in the png crate - that crate alone is not a super heavy dependency.

It's starting to seem like there might need to be a more general mechanism for resources that are not generated through factory methods on the render context. I can see that coming into play, for example, for images that are generated gpu-side, for the other backends. I'll continue to think about this.

[Ralith]

Added (very) brief documentation and renamed the example, and tweaked types for better forwards-compatibility.

[cmyr]

What's the status of this?

[Ralith]

I think this is ready to go.

[cmyr]

Just out of curiosity, what was the original motivation for this?

I have one little nit about version numbers but otherwise I'm happy. It might be good to have an issue outlining the work that's missing?

[Ralith]

Just out of curiosity, what was the original motivation for this?

My current use of druid is a 2D vector graphics toy which I want to support both interactive editing and export. Using the same drawing code for both is extremely attractive, for obvious reasons.

[cmyr]

thanks! :)