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

[Julian Eisel]

Hi,

I'm not at all convinced that we’ll need Cairo “down the road”, at least not
beause of Wayland.

UI team/contributors already agreed years ago that it would be nice to do
window decorations ourselves, to make better use of space [1]. We could do
that with our existing graphics abstractions and don't need Cairo for that. Cairo
was just proposed because that happens to be what libdecoration used, and even
that is designed to support multiple graphics plugins, see [2].

We're in no hurry to switch to Wayland, for now X is still fine for us. Of
course it would be nice, but the patch proposes dependencies that I don't think
are a worth the overhead (libdecoration & Meson & D-Bus & Cairo).

In my opinion we should either wait until libdecoration supports other graphics
plugins, create our own, or - preferably - work on our own client-side
decorations for all platforms. The UI team wouldn't plan this for soon, but it
could be put on the medium-term agenda.
Note that there's also a Wayland protocol in the works that should eventually
replace the need for D-Bus, it's also a good idea to wait for that IMHO.

I voiced my opinion in the patch too [3]. Please excuse my little rant on required
client side decorations there :)

[1] https://archive.blender.org/wiki/index.php/Dev:2.8/UI/Workshop_Writeup/#Top_Bar
[2] https://gitlab.gnome.org/jadahl/libdecoration
[3] https://developer.blender.org/D7989#243849

> On 11. Dec 2020, at 19:12, Ray Molenkamp via Bf-committers <bf-committers at blender.org> wrote:
> 
> Seems reasonable (and I agree) however playing devils advocate:
> 
> if we're going to need cairo down the road anyhow we may
> as well rip that band-aid off now and deal with the pain
> of building it rather than building libharu now and cairo later.
> 
> --Ray
> 
> 
> On 2020-12-11 10:47 a.m., Brecht Van Lommel via Bf-committers wrote:
>> 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 at 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 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
>>> 
>> _______________________________________________
>> 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

———————————————————————————————————————————
Julian Eisel - julian at blender.org - www.blender.org
Software Developer
Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands
----------------------------------------------------------------------------------------