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

[thomas bonfort]

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