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

[Ray Molenkamp]

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