I think we should only use extern/ if the alternative is not possible for some reason, and I'm not aware of any. So following that libharu would go to the svn libraries.
Personally I don't really see a significant advantage in bundling it as a separate executable. It helps in some ways, but then you potentially get issues with proper passing of arguments, unicode and escaping, error handling, etc. Adding an abstraction layer so theoretically the library can be switched out for another is probably not very helpful. If we were using this in many places maybe, but in my experience, these kinds of abstraction layers get in the way more than they help. Cairo is not that big a library when enabling most backends, but it still has a required additional dependency (pixman). I guess overall it's probably not going to simplify building and maintenance. So weighing the options, to me libharu seems like the most reasonable solution. On Fri, Dec 11, 2020 at 1:51 AM Campbell Barton via Bf-committers < bf-committers@blender.org> wrote: > By this logic we could blindly accept any patch that's had some production > testing, without considering long term maintenance. > > It's possible alternative solutions that call out to existing well > maintained > converters would have been fine in production too. > It's not that I'm pushing back against including this entirely, > I'm just not a fan of this "it worked in a production test - so lets > include it" -- attitude. > > Over the years I believe we've spent significant time investigating > issues with 3rd party libraries (resource leaks, conflicting symbols, > linking problems, platform specific errors etc). > If there is a good chance we can avoid this entirely, it could be > worth looking into. > > If we do include libharu, how would this be included? in extern/ or > would we bundle it in SVN's lib? > > On 12/10/20 8:26 PM, Dalai Felinto wrote: > > Hi, > > > > My suggestion would be the following: > > > > * Stick to libharu since it was proven that works for the intended use > > case. > > * Make sure libharu integration in the code goes via a layer of > > abstraction. > > > > So instead of trying now to solve an non-existent problem, we use > > development time to make sure the existing solution is robust enough to > > be replaced if needs be. > > > > Regards, > > Dalai > > > > On 09-12-2020 23:34, Campbell Barton via Bf-committers wrote: > >> rsvg-convert (which uses cairo), is a utility that converts SVG to > >> PDF, it can create multi-page PDF's from many SVG's too. > >> > >> If for some reason we need more control then a command line utility > >> provides, there are Python multiple options regarding bindings for > >> cairo & svg conversion. > >> From what I can tell they can convert SVG to PDF quite easily. > >> > >> Regarding bundling the conversion tools, if this it's only a few > >> studios with specific requirements, we don't _necessarily_ need to > >> include the conversion utilities with Blender, although this is a > >> decision we could easily change. > >> > >> I'm not pushing for this as the final solution, just checking if it > >> might be a simpler option compared to taking on a PDF library that > >> isn't maintained anymore. > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> https://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
