Add SVG support about imv

[siiptuo]

I would find this feature very useful.

The best option to implement it would probably be librsvg because it's quite popular and feature complete. However it comes with many dependencies to GNOME libraries like Cairo and GLib.

Alternatively nanosvg could be considered but its features, especially rasterization, isn't as good as in librsvg. I believe that in this case image quality and correctness is more important than code size.

There are some other libraries out there but these two look like the only complete and active ones. There are naturally other open source implementations but they are not available as simple standalone libraries.

Of course the whole SVG support could be an optional feature or even support multiple libraries.

[ddevault]

👍

[eXeC64]

SVG is a very tempting format to support. I don't have any plans to implement support for multiple back ends in imv, but I'd consider patches.

This could be done in two parts:

1. Wrapping existing use of FIBITMAP in a struct.

• Updating imv_loader to return the new struct
• Updating imv_texture to load the struct
• Providing a function to properly destroy the struct

2. Creating a loader interface

• Adapting the existing one to be the 'FreeImage' loader.
• Have a table/list of loaders, routing to them based on file type.
• Implement new loaders (one for SVG, etc.)

This raises the possibility to escape GPLv2 long term too. At present there have been 10 code contributors since being forced to license GPLv2, 5 of whom I know would agree to MIT licensing of their contributions, or have already done so. 4 of the other contributors only have one line changes.

Getting proper authorisation shouldn't be an issue.

[eXeC64]

I've merged changes to master that resolve this issue: Support for multiple backends, with a librsvg backend.

[ddevault]

Thanks!