Soooooo.. this thread has a good run, lots of good feedback, but it still seems decision-less, I'll happily do the work to make this happen,
but who makes the final call here? --Ray On 2020-12-15 9:19 p.m., Campbell Barton via Bf-committers wrote: > To follow up on previous messages: > > - On my system the stripped library is ~830kb, > over half of the libraries file-size is binary data for fonts and > character encoding tables, > if we wanted we could remove these - bringing the size down to ~350kb. > > - This library is available on mainstream Linux distributions, > so even if this isn't maintained by the author, it's not exactly > abandon-ware either. > From checking suse [0] & debian's [1] repository, their patches > aren't likely to be useful to us > since they're only tweaks for building & header guards. > > - I ran some (admittedly basic) tests with valgrind & ASAN > which didn't show up any issues that would be cause for concern. > > So while I'm still not so keen to depend on unmaintained code. > +1 to include this as an optional library. > > [0] https://build.opensuse.org/package/show/openSUSE:Factory/libharu > [1] https://packages.debian.org/stable/source/libharu > > On Tue, Dec 15, 2020 at 1:17 AM Sybren A. Stüvel via Bf-committers > <bf-committers@blender.org> wrote: >> On Fri, 11 Dec 2020 at 18:55, Brecht Van Lommel via Bf-committers >> <bf-committers@blender.org> wrote: >>> 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. >> I agree. IMO such an abstraction layer is generally only really worth >> it if you already have two different libraries to support, and you >> know enough about the differences in architecture that you can >> actually create the proper abstractions. >> >>> libharu seems like the most reasonable solution. >> I agree, although the "not maintained since 2013" is a bit scary. The >> fact that we won't be using the known-buggy parts of the code helps, >> but I do think this should then be documented properly somewhere. If >> the inclusion of the library is done under the assumption that no >> images will be read, and no PDF will be imported, because these are >> buggy code paths, this should be clear to future contributors as well. >> Without such warnings in place, people are bound to be looking at the >> library to create some PDF-to-GP importer. >> >> Sybren >> _______________________________________________ >> 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
