[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cairo based backend
Re: Cairo based backend
Thu, 8 Jul 2021 12:44:43 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
On 07.07.21 20:41, Jonas Hahnfeld wrote:
Am Mittwoch, dem 07.07.2021 um 19:42 +0200 schrieb Knut Petersen:
The cairo pdf support is old, but pdf hyperlink support unfortunately
requires at least cairo 1.16.
Oh wow 😲 Ok, that's indeed a reason to go with at least 1.16. Which is
fine for an optional requirement, just means that making it a hard
dependency will end support for some platforms.
I think this set of rules should be acceptable:
* No cairo-devel: Disable cairo backend code and print a message during
* cairo-devel >=1.2 <1.16: build cairo backend without support for hyperlinks
and pdf metadata
* cairo-devel >= 1.16.0: build cairo backend
Even without the pdf hyperlinks and pdf metadata the backend could be of a real
value if the target system does not have ghostscript 9.53+ and rgbA colours are
used. And users should be able to test the code, especially it is important to
know if font handling on different systems works as expected.
In gub we have old cairo and libpng versions, but it should not be too
hard to change the code to work with them.
Something like the way we handle ghostscript - to use all lilypond
features 9.53+ is required, but we accept the limits of older versions.
Nevertheless, we should update cairo in gub.
... or hope that we don't use GUB anymore by that time...
Propose a less terrible solution ;-)
Do I understand it correctly that at gitlab.com we have docker images of ubuntu
16.04, ubuntu 18.04 and ubuntu 18.04 with guile 2 for the automatic/manual
tests, but that those tests do not include building with gub but only building
within the native ubuntu environments?
My code uses libpng because I a) expect feature requests beyond the
possibilities of that toy api and b) because I thought it would be a
good idea to demonstrate how to add output support for arbitrary
Hm, ok... FYI there is png_set_error_fn which looks much nicer than
those long jumps.
Yes, I'll change that. Although there should be no problem with the default
longjmp solution as we do not use any local variables after the longjmp.
No, we're in the post-C++11 era, there are range-based loops!
Ok, so as far as I understand, you have one surface / context per
output format, right?
The cairo backend uses one surface/context per output file. That means for
those formats that generate multiple files (png, svg) a new surface/context
pair is created for every new page. Of course after the old surface/context
pair has been killed.
Using sets seemed to be an elegant c++ solution to me, but it's clear that those high level constructs are probably slower than traditional c constructs. I have to admit that I use guile and c++ only because they are the programming languages that are used in lilypond. I have never looked at range
based loops before, but I'll do that now. Do you think using them would lead to faster, more elegant or more readable code?
std::set (and even std::unordered_set) is the
wrong data structure for this kind of task, but as I said before I
would focus on PDF output for now and then the first patch doesn't need
Well, postscript via cairo is only very few lines of code. svg via cairo succeeds for those files in our regression test selection that fail to compile with the traditional svg backend. The png code provides, besides the png files, the recipe how someone else can add more formats very easily in the
future. Using the cairo png toy would also entail an indirect dependency on libpng. And to keep the whole thing small I already refrained from including the direct output of x264 videos anyway ;-)
More worrying to me is the possibility to directly call the c++
stencil commands from everywhere in guile ... do we have a way of
defining the c++ functions in cairo.cc in a way that only framework-
cairo.scm code would be able to execute it?
No, AFAICT functions defined in C are currently added to the (lily)
module, which is basically available everywhere.
There are functions like 'scm_c_module_define' in the guile library ... maybe I
should have a look at those.
Re: Cairo based backend, Lukas-Fabian Moser, 2021/07/10
Re: Cairo based backend, Knut Petersen, 2021/07/10