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

[Tamas Szekeres]

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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130725/08291f47/attachment.html>