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

Thu Jul 25 05:16:58 PDT 2013

We seem not to have too much choices as we require such level of
integration with cairo which is not an option with the other 3rdpty
libraries.
We might probably encapsulate the interface for librsvg into a dynamically
loadable library (ie a plugin) which passes over the decision about the
licensing model to the end user from the binary distributor.

Your initial suggest is ok technically, I just wanted to make sure
distributors will be able to switch to this new option without compromises.

Best regards,

Tamas

2013/7/25 thomas bonfort <thomas.bonfort at gmail.com>

> Tamas,
> Unless you have a more pragmatic solution, I would like to move on
> with this. Note that the status-quo you are advocating is leaving us
> in a situation where:
> - users cannot easily use svg symbols as the dependency isn't packaged
> by distros
> - the featureset of libsvg-cairo means some svg symbols aren't
> rendered correctly or at all
> - users of recent cairo library will run into compile time or runtime
> errors due to libsvg-cairo's usage of a long-deprecated API.
>
> regards,
> Thomas
>
> On 25 July 2013 11:20, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> > Even,
> > If I understand correctly, that would be one of the options for a
> > third party SVG *parser*, i.e. this falls in the second point I made
> > in my previous email in the sense we still would need to do all the
> > plumbing to connect that to the cairo and/or agg rendering primitives.
> >
> > regards,
> > thomas
> >
> > On 25 July 2013 10:28, Even Rouault <even.rouault at mines-paris.org>
> wrote:
> >> 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
> >>>
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130725/1378ae00/attachment-0001.html>