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

[thomas bonfort]

Tamas,
that is not possible as those libraries are lgpl.

On 25 July 2013 10:17, Tamas Szekeres <szekerest at gmail.com> wrote:
> Thomas,
>
> Wouldn't that be easier to take over to support libsvg-cairo and implement
> missing features inside (probably by adding that in mapserver svn, like we
> have already added the agg sources)?
>
> Best regards,
>
> Tamas
>
>
>
> 2013/7/25 thomas bonfort <thomas.bonfort at gmail.com>
>>
>> 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
>> >
>> >
>
>