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

[Campbell Barton]

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



-- 
- Campbell