k...@aspodata.se writes: > Han-Wen Nienhuys: >> On Sat, Jun 24, 2017 at 12:43 PM, David Kastrup <d...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel