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

[Even Rouault]

Selon 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).

Perhaps a potential candidaty, very likely under Apache licence (I've not
verified) :
https://blogs.apache.org/OOo/entry/native_svg_support_for_apache . Although I'd
fear I'd bet it depend much of OpenOffice internal APIs (XML parsing,
rendering), which might make it impractical to use it by MapServer.


>
> 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
> >
> >
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>