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

thomas bonfort thomas.bonfort at gmail.com
Thu Jul 25 02:20:32 PDT 2013


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


More information about the mapserver-dev mailing list