[mapserver-dev] libsvg-cairo / librsvg [vote]

[thomas bonfort]

Tamas,
Unfortunately there are no existing other libraries that I know of
that would fit our needs with reasonable effort.

- agg has a primitive svg parser that SteveW and I extensively tested
a year ago ( http://imaptools.com:8080/svg-test/index-agg-svg.html ,
https://github.com/mapserver/mapserver/issues/4252 ). While the
licence fits much better, it has some shortcomings by which some svg
primitives aren't supported, and it would also imply that we'd need to
rasterize svg symbols for our pdf and svg outputformats instead of
including the native vector primitives.
- we could roll our own SVG renderer based on a more liberal SVG
parser. Aside from the fact that we'd need to find a parser that's as
compliant and maintained as rsvg, this also requires substantial
funding (i.e. if the GPL doesn't fit a distributor he has the option
to fund an alternative, which is playing along the rules of gpl in the
first place).

regards,
thomas

On 25 July 2013 09:03, Tamas Szekeres <szekerest at gmail.com> wrote:
> Thomas,
>
> While I'm not sure about all technical details, but having librsvg licensed
> with GPL is a bit discouraging. Not sure if all the distributors of
> MapServer would want to change their licenses to GPL because of this.
> Supporting both librsvg and libsvg-cairo in parallel seems to be a short
> term approach only. If we don't think the libsvg-cairo will be supported,
> that line will die shortly.
>
> Don't we have other alternatives?
>
> Best regards,
>
> Tamas
>
>
>
> 2013/7/24 thomas bonfort <thomas.bonfort at gmail.com>
>>
>> Devs,
>>
>> While implementing svg symbology support, we made the choice to go
>> with libsvg+libsvg-cairo for parsing and rendering of svg files, as
>> those were the libraries that had the least dependencies. It turns out
>> both those libraries are more or less abandonware, resulting in their
>> absence from a number of distros, and an incompatibility with newer
>> cairo apis.
>>
>> Along with release 6.4, I propose to add an SVG symbol implementation
>> based on librsvg [ https://wiki.gnome.org/LibRsvg ], with the
>> following consequences:
>>
>> - the user can decide at compile time wether to use libsvgcairo or librsvg
>> - librsvg is maintained and present in distros, being a core component of
>> gnome
>> - librsvg has a number of dependencies, making its compilation/usage
>> on non-standard platforms possibly problematic (c.f. previous point:
>> but it is distributed by distros).
>> - librsvg is GPL, with all that that might imply for people releasing
>> mapserver binaries.
>>
>> This seems like the only way out if we want to continue supporting SVG
>> symbols in the longer run. I understand the limitations, however the
>> user still has the option to fall back to the current situation with
>> libsvg-cairo.
>>
>> Jeff: concerning windows, all I can say is that librsvg support on
>> windows can't be worse than that of libsvg-cairo.
>>
>> I'm not sure this really warrants a vote, but here goes in case anyone
>> wants to veto.
>>
>> +1 for adding librsvg as an alternative to libsvg-cairo for rendering
>> svg symbols.
>>
>> best regards,
>> thomas
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>