RFC: require librsvg to implement SVG image support

[Jean Abou Samra]

Hi,

There are still some rough edges, but I basically got binaries
with librsvg to build with the infrastructure in release/binaries/,
for Linux/macOS/Windows, so here is the proposal.

As a summary if you haven't followed the recent threads on Cairo:

The Cairo backend supports embedding EPS images, but only
in PS/EPS output, which is not what most users want.

!1787 adds support for PNG images. However, this still has
the limitation that PNGs are raster graphics, while EPSes
can contain vector graphics.

In order to keep support for vector graphics, even if not
with EPS, we can add support for embedding SVG images.
This requires the ability to render an SVG to a Cairo
surface. Cairo doesn't do this itself. It is the job of
the librsvg library, which is part of the GNOME stack
(like GLib and Pango which we already require).

There is also PDF, which could be made to work via Poppler.
However, it is built with CMake, for which the release
infrastructure does not have support so far. Jonas said
cross-compilation was difficult with CMake, and I believe
him.

Therefore, the proposal here is to add librsvg as a dependency
to LilyPond. The transitive dependencies it pulls in are
libxml2, GdkPixbuf, and libjpeg (the latter for GdkPixbuf).

Build systems are

- librsvg: Cargo (Rust package manager; cross-compilation
  was relatively seamless) + Autotools (for the C API)

- libxml2 and libjpeg: Autotools

- GdkPixbuf: Meson


In terms of licensing, everything looks fine. To elaborate:

- librsvg itself is LGPL-2.1-or-later

- libxml2 is MIT-licensed.

- GdkPixbuf is LGPL-2.1-or-later.

- libjpeg:

  In my understanding, there are two versions of "libjpeg"
  in the wild, the original libjpeg, and the modified version
  libjpeg-turbo, which has a compatible API. GdkPixbuf
  can be built with both of them. The original libjpeg is
  released under a license called the Independent JPEG
  Group license (IJG license), which is described as
  GPL-compatible on

https://www.gnu.org/licenses/license-list.html#ijg

  The original-libjpeg-compatible part of libjpeg-turbo
  is documented as being under the IJG license as well:

https://github.com/libjpeg-turbo/libjpeg-turbo/blob/main/LICENSE.md

  Note that in the release scripts, I prefer using
  the original libjpeg because it's built with Autotools,
  whereas libjpeg-turbo would require adding CMake
  support to our infrastructure.


What do you think:

* Do you agree with adding these dependencies?

* If so, how do we manage the transition? Do we make them
  optional at first, and if so, for how long?


Regards,
Jean

OpenPGP_signature
Description: OpenPGP digital signature