Re: Cairo based backend

[Knut Petersen]

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 
autoconf
 * 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 ;-)

BTW:

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
> > > formats.
> 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
> to bother.

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.

Knut