[Bf-committers] GPencil I/O Project: Request to integrate libharu lib to export PDF format

[Brecht Van Lommel]

There appears to be consensus that libharu is the way to go, and a week has
passed for people to give feedback.

Let's considered this decided then, and let Antonio and the platform
maintainers take care of the implementation.



On Wed, Dec 16, 2020 at 4:03 PM Ray Molenkamp via Bf-committers <
bf-committers at blender.org> wrote:

> 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 at blender.org> wrote:
> >> On Fri, 11 Dec 2020 at 18:55, Brecht Van Lommel via Bf-committers
> >> <bf-committers at 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 at blender.org
> >> https://lists.blender.org/mailman/listinfo/bf-committers
> >
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>