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

[Lime, Steve D (MNIT)]

Thomas: I thought the text associated with your pull request summed things up pretty well. Folks releasing binaries
definitely have a way couple of ways forward: either not supporting SVG symbols or living with the peculiarities of
the libsvgcairo approach. So I'm ok with your proposal: +1.

Steve

-----Original Message-----
From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort
Sent: Thursday, July 25, 2013 4:21 AM
To: Even Rouault
Cc: MapServer Dev Mailing List
Subject: Re: [mapserver-dev] libsvg-cairo / librsvg [vote]

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