[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using/requiring Cairo

From: David Kastrup
Subject: Re: Using/requiring Cairo
Date: Sat, 24 Jun 2017 19:08:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

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

>> > 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).
> Build dependencies
> ==================
> * Guile 1.8.0 or newer
> * Cairo 1.2.0 or newer

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]