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

Thu Jul 25 05:48:46 PDT 2013

Thanks Tamas.

On 25 July 2013 14:16, Tamas Szekeres <szekerest at gmail.com> wrote:
> 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.

Binary-only distributors shipping private/proprietary modifications to
mapserver won't be able to do that anymore without compromise, for
sure. As I said, if such a distributor exists, is sufficiently upset
by the GPL clause, and needs SVG symbols, he can fund the development
of an interface to a free svg parser. Holding up the support of SVG
symbols for everyone because of this would be a pity imho.

cheers,
thomas

>
> 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
>> >>>
>> >>
>> >>
>
>