<div>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.</div><div>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.</div>
<div><br></div><div>Your initial suggest is ok technically, I just wanted to make sure distributors will be able to switch to this new option without compromises.</div><div><br></div><div>Best regards,</div><div><br></div>
<div>Tamas</div><div><br></div><br><br><div class="gmail_quote">2013/7/25 thomas bonfort <span dir="ltr"><<a href="mailto:thomas.bonfort@gmail.com" target="_blank">thomas.bonfort@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tamas,<br>
Unless you have a more pragmatic solution, I would like to move on<br>
with this. Note that the status-quo you are advocating is leaving us<br>
in a situation where:<br>
- users cannot easily use svg symbols as the dependency isn't packaged<br>
by distros<br>
- the featureset of libsvg-cairo means some svg symbols aren't<br>
rendered correctly or at all<br>
- users of recent cairo library will run into compile time or runtime<br>
errors due to libsvg-cairo's usage of a long-deprecated API.<br>
<br>
regards,<br>
Thomas<br>
<div class="HOEnZb"><div class="h5"><br>
On 25 July 2013 11:20, thomas bonfort <<a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a>> wrote:<br>
> Even,<br>
> If I understand correctly, that would be one of the options for a<br>
> third party SVG *parser*, i.e. this falls in the second point I made<br>
> in my previous email in the sense we still would need to do all the<br>
> plumbing to connect that to the cairo and/or agg rendering primitives.<br>
><br>
> regards,<br>
> thomas<br>
><br>
> On 25 July 2013 10:28, Even Rouault <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>> wrote:<br>
>> Selon thomas bonfort <<a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a>>:<br>
>><br>
>>> Tamas,<br>
>>> Unfortunately there are no existing other libraries that I know of<br>
>>> that would fit our needs with reasonable effort.<br>
>>><br>
>>> - agg has a primitive svg parser that SteveW and I extensively tested<br>
>>> a year ago ( <a href="http://imaptools.com:8080/svg-test/index-agg-svg.html" target="_blank">http://imaptools.com:8080/svg-test/index-agg-svg.html</a> ,<br>
>>> <a href="https://github.com/mapserver/mapserver/issues/4252" target="_blank">https://github.com/mapserver/mapserver/issues/4252</a> ). While the<br>
>>> licence fits much better, it has some shortcomings by which some svg<br>
>>> primitives aren't supported, and it would also imply that we'd need to<br>
>>> rasterize svg symbols for our pdf and svg outputformats instead of<br>
>>> including the native vector primitives.<br>
>>> - we could roll our own SVG renderer based on a more liberal SVG<br>
>>> parser. Aside from the fact that we'd need to find a parser that's as<br>
>>> compliant and maintained as rsvg, this also requires substantial<br>
>>> funding (i.e. if the GPL doesn't fit a distributor he has the option<br>
>>> to fund an alternative, which is playing along the rules of gpl in the<br>
>>> first place).<br>
>><br>
>> Perhaps a potential candidaty, very likely under Apache licence (I've not<br>
>> verified) :<br>
>> <a href="https://blogs.apache.org/OOo/entry/native_svg_support_for_apache" target="_blank">https://blogs.apache.org/OOo/entry/native_svg_support_for_apache</a> . Although I'd<br>
>> fear I'd bet it depend much of OpenOffice internal APIs (XML parsing,<br>
>> rendering), which might make it impractical to use it by MapServer.<br>
>><br>
>><br>
>>><br>
>>> regards,<br>
>>> thomas<br>
>>><br>
>>> On 25 July 2013 09:03, Tamas Szekeres <<a href="mailto:szekerest@gmail.com">szekerest@gmail.com</a>> wrote:<br>
>>> > Thomas,<br>
>>> ><br>
>>> > While I'm not sure about all technical details, but having librsvg licensed<br>
>>> > with GPL is a bit discouraging. Not sure if all the distributors of<br>
>>> > MapServer would want to change their licenses to GPL because of this.<br>
>>> > Supporting both librsvg and libsvg-cairo in parallel seems to be a short<br>
>>> > term approach only. If we don't think the libsvg-cairo will be supported,<br>
>>> > that line will die shortly.<br>
>>> ><br>
>>> > Don't we have other alternatives?<br>
>>> ><br>
>>> > Best regards,<br>
>>> ><br>
>>> > Tamas<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > 2013/7/24 thomas bonfort <<a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a>><br>
>>> >><br>
>>> >> Devs,<br>
>>> >><br>
>>> >> While implementing svg symbology support, we made the choice to go<br>
>>> >> with libsvg+libsvg-cairo for parsing and rendering of svg files, as<br>
>>> >> those were the libraries that had the least dependencies. It turns out<br>
>>> >> both those libraries are more or less abandonware, resulting in their<br>
>>> >> absence from a number of distros, and an incompatibility with newer<br>
>>> >> cairo apis.<br>
>>> >><br>
>>> >> Along with release 6.4, I propose to add an SVG symbol implementation<br>
>>> >> based on librsvg [ <a href="https://wiki.gnome.org/LibRsvg" target="_blank">https://wiki.gnome.org/LibRsvg</a> ], with the<br>
>>> >> following consequences:<br>
>>> >><br>
>>> >> - the user can decide at compile time wether to use libsvgcairo or librsvg<br>
>>> >> - librsvg is maintained and present in distros, being a core component of<br>
>>> >> gnome<br>
>>> >> - librsvg has a number of dependencies, making its compilation/usage<br>
>>> >> on non-standard platforms possibly problematic (c.f. previous point:<br>
>>> >> but it is distributed by distros).<br>
>>> >> - librsvg is GPL, with all that that might imply for people releasing<br>
>>> >> mapserver binaries.<br>
>>> >><br>
>>> >> This seems like the only way out if we want to continue supporting SVG<br>
>>> >> symbols in the longer run. I understand the limitations, however the<br>
>>> >> user still has the option to fall back to the current situation with<br>
>>> >> libsvg-cairo.<br>
>>> >><br>
>>> >> Jeff: concerning windows, all I can say is that librsvg support on<br>
>>> >> windows can't be worse than that of libsvg-cairo.<br>
>>> >><br>
>>> >> I'm not sure this really warrants a vote, but here goes in case anyone<br>
>>> >> wants to veto.<br>
>>> >><br>
>>> >> +1 for adding librsvg as an alternative to libsvg-cairo for rendering<br>
>>> >> svg symbols.<br>
>>> >><br>
>>> >> best regards,<br>
>>> >> thomas<br>
>>> >> _______________________________________________<br>
>>> >> mapserver-dev mailing list<br>
>>> >> <a href="mailto:mapserver-dev@lists.osgeo.org">mapserver-dev@lists.osgeo.org</a><br>
>>> >> <a href="http://lists.osgeo.org/mailman/listinfo/mapserver-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
>>> ><br>
>>> ><br>
>>> _______________________________________________<br>
>>> mapserver-dev mailing list<br>
>>> <a href="mailto:mapserver-dev@lists.osgeo.org">mapserver-dev@lists.osgeo.org</a><br>
>>> <a href="http://lists.osgeo.org/mailman/listinfo/mapserver-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
>>><br>
>><br>
>><br>
</div></div></blockquote></div><br>