On Sat, Jun 26, 2021 at 10:52 PM Jonas Hahnfeld via Discussions on LilyPond development <lilypond-devel@gnu.org> wrote: > > Am Samstag, dem 26.06.2021 um 19:43 +0000 schrieb Werner LEMBERG: > > > No, it's definitely too soon for a merge request. A few > > > stencils->cairo procedures need to be added, a bit of error > > > handling > > > (to prevent at least possible segfaults) is necessary, a bit of > > > logical cleanup is desirable, etc. > > > > Well, you can start the commit message of the merge request with > > 'WIP:'; this prevents execution of the CI stuff, AFAIK. > > No, it doesn't. There are ways to not run CI jobs for a particular > commit, but I don't really see the point just for the sake of pushing > the current demonstrator into a merge request. > > May I instead propose an incremental approach? Implementing a fully > capable Cairo backend probably won't happen in a single MR, and making > it the default will be even further down the road. I think for a first > step the Cairo stuff needs to be optional and in a proper backend, not > hacked into the current Postscript code. Then others can test, missing > features can be added over time, and it's possible to evaluate further > steps.
I agree. Creating a new backend is actually fairly simple. Just copy framework-ps.scm to framework-cairo.scm. That should be enough to get you support for -dbackend=cairo. If you want, you can also copy output-ps.scm, but that's not strictly necessary (anything that populates the dispatch alist for the paper-outputter will work.) I had a quick look at the C++ code. The global variables are a bit concerning. As a start, you could put them into class Cairo_context { RefPtr<Cairo::Context> cr; ... } this struct will then later be a natural candidate to create a smob from. However, I wonder why you want to go through Scheme in the first place, as the output mechanism (Cairo) lives in C++, while steering the output goes through C++ as well (see paper-outputter.cc). For the prototype, I think it would be better to insert the Cairo data (Cairo::Context etc.) into Paper_outputter itself. Then, you can intercept the Stencils directly in Paper_outputter::output_scheme. Once that works, we can figure out something with inheritance to factor out the cairo-specific code. Hope this helps, Han-Wen > > Jonas -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen