Re: Using/requiring Cairo

[David Kastrup]

address@hidden writes:

> Han-Wen Nienhuys:
>> On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup <address@hidden> wrote:
>> > What does that mean?  Mainly a viable migration strategy where we might
>> > be able to drop catering for a whole lot of graphics programming
>> > ourselves by introducing a dependency on Cairo.  I am not overly
>> 
>> what "catering for graphic programming" mean? There is graphical
>> programming, but a lot of it is done already. Moving towards a new
>> library will be a big undertaking, so it could use more justification.
> ...
>> > It would be a large amount of work to bring LilyPond's graphics
>> > programming up to scratch.  Moving to Cairo's data structures alone
>> > would be quite advantageous and would likely speed up backend operations
>> > significantly.
>> 
>> which ones? In terms of graphics, the backend just does interval
>> unions and offsets (floating point comparisions and additions) through
>> the Stencil object. Unless you also restructure how objects are
>> grouped, it's going to be similar.
>
> If no one else like to care for postscript, I can step in to handle it.

I don't know what that means.  My proposed migration plan would not have
changed the PostScript backend at first, but it certainly would have
been slated for eventual retirement.

>> > We might also be able to forego creating PostScript as an
>> > intermediate stage to creating PDF and create bitmap formats
>> > without using PostScript as well (again, this should really speed
>> > up things).
>
> I use PS as the final format.  Cairo can export to postscript but it's
> PS is not nice to read, lilypond PS is much better in that respect.

PostScript is not intended to be human-readable rather than
human-writable and streamable, two characteristics PDF no longer cares
about in return for better computer-readability and processability.

LilyPond PostScript defines a whole lot of its own macros and passes
stuff for PDF processing.  That makes it a lot less likely to be
suitable for mechanical processing (like using "Tailor") than PostScript
generated from a general-purpose representation with commonly used
toolkits.

>> > Drawbacks?  Like other things, being on Guile-2.x would make for
>> > synergies with existing projects (not least of all guile-cairo
>> > though I haven't checked its suitability in general, with the new
>> > PDF-level features, and possible compatibility with Guile-1: I
>> > think it supported Guile-1 at some point of time).
>
> http://git.savannah.nongnu.org/cgit/guile-cairo.git/tree/README
>
> Build dependencies
> ==================
>
> * Guile 1.8.0 or newer
>   http://www.gnu.org/software/guile/
> * Cairo 1.2.0 or newer
>   http://cairographics.org/

Well, it's maintained by Andy Wingo.  That makes it more likely to
update to newer Guile versions than newer Cairo versions.  But at least
configure.ac appears to support Guile 1.8 still explicitly.

> ...
>> I would suggest trying make a GUILE binding of sorts for Cairo, adding
>> that in parallel to existing GS support, and hacking untili you have
>> feature parity. Then drop the GS support, and migrate the cairo data
>> structures more towards the core of the program as needed.
>
> There already are guile bindings for cairo:
>
>  https://savannah.nongnu.org/projects/guile-cairo

One would have to evaluate whether their data structures work well for
the intent of providing a good data representation for use internal to
LilyPond's graphics processing.  If we end up with a whole lot of
back-and-forth conversion (and particularly lots of small storage
allocations) after all for crossing Scheme/C/C++ boundaries, it might
still make more sense to create one's own wrapping layer.  If the wrap
is a good fit, it might be good to make use of.

-- 
David Kastrup