Re: Cairo based backend
Am Mittwoch, dem 07.07.2021 um 19:48 + schrieb Werner LEMBERG: > > No, we're in the post-C++11 era, > > Are we? I thought that LilyPond shouldn't use features more recent > than C++11. Yeah, post-adoption-of-C++11 era. Range-based for loops are C++11. Jonas signature.asc Description: This is a digitally signed message part
Re: Please review Pygments lexer and style
Le 25/06/2021 01:40, Dan Eble <[1]d...@faithful.be> a écrit : On Jun 24, 2021, at 14:17, Jean Abou Samra <[2]j...@abou-samra.fr> wrote: Ok, I already simplified it, but it's still too complicated. Consider approaching from the other direction. If you had only italic, bold, and red to work with, how would you use them? Here is how far I could get it this evening. I plan on removing the draft status from the pull request somewhere in the end of the week. Cheers Jean References 1. mailto:d...@faithful.be 2. mailto:j...@abou-samra.fr example.rtf Description: RTF file
Re: Cairo based backend
> No, we're in the post-C++11 era, Are we? I thought that LilyPond shouldn't use features more recent than C++11. Werner
Re: Cairo based backend
Am Mittwoch, dem 07.07.2021 um 19:42 +0200 schrieb Knut Petersen:
> Hi Jonas
>
> > I saw that you opened a merge request (actually, two...),
> I managed to screw up my git commands.
>
>
> > The first one is about *how* the backend should be added. In the
> > previous thread, I proposed that it should be optional at first and I
> > meant this to imply that Cairo should not become a required
> > dependency from the beginning. Actually, I think it may be even
> > better to only compile the backend if passing a flag to configure,
> > say --enable-cairo. In particular the requirement on version 1.16
> > will cut out many active distributions, most importantly Ubuntu 18.04
> > used in the CI pipelines and representing, more or less, the minimum
> > versions required for LilyPond. (Is there a particular reason for
> > 1.16 or could the code work with older versions? Debian 9 Stretch has
> > 1.14.8 and is supported until next year, but not really required once
> > the backend is optional.)
> 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.
> 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...
>
>
> > The code in !837 also depends on libpng to write out images, where
> > the
> > use of setjmp made me frown. It appears that Cairo has a (very
> > simple)
> > API available for writing PNGs, any reason not to use that?
> The cairo people call their png support a "toy api" and recommend to
> use the real library.
> 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.
>
>
> > Briefly looking through the code, I find the macros MCRA, MCRB,
> > MSURA,
> > and MSURB very hard to read (no clue what they stand for). I'd have
> > to
> > look into it, but I hope there are nicer ways to write that.
> It's just a way to save about 250 lines of code for functions that do
> nothing than to establish functions that loop over a set of cairo
> surfaces/contexts instead of writing to only one surface/context.
>
> > void mcr_cairo_arc(double a, double b, double c, double d, double e)
> > MCRA cairo_arc(*itcrs, a, b, c, d, e); MCRB
> would normally be written as
> void mcr_cairo_arc(double a, double b, double c, double d, double e)
> {
> itcrs=crs.begin();
> while (itcrs != crs.end()) {
> cairo_arc(*itcrs, a, b, c, d, e);
> itcrs++; }
> }
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? 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.
> > Also the amount of global variables is worrying...
> Ok. A c++ programmer is talking to somebody who likes to use assembly
> language ;-))
> 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.
Jonas
> Knut
signature.asc
Description: This is a digitally signed message part
Re: Cairo based backend
Hi Jonas
I saw that you opened a merge request (actually, two...),
I managed to screw up my git commands.
The first one is about *how* the backend should be added. In the
previous thread, I proposed that it should be optional at first and I
meant this to imply that Cairo should not become a required dependency
from the beginning. Actually, I think it may be even better to only
compile the backend if passing a flag to configure, say --enable-cairo.
In particular the requirement on version 1.16 will cut out many active
distributions, most importantly Ubuntu 18.04 used in the CI pipelines
and representing, more or less, the minimum versions required for
LilyPond. (Is there a particular reason for 1.16 or could the code work
with older versions? Debian 9 Stretch has 1.14.8 and is supported until
next year, but not really required once the backend is optional.)
The cairo pdf support is old, but pdf hyperlink support unfortunately requires
at least cairo 1.16.
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.
The code in !837 also depends on libpng to write out images, where the
use of setjmp made me frown. It appears that Cairo has a (very simple)
API available for writing PNGs, any reason not to use that?
The cairo people call their png support a "toy api" and recommend to use the
real library.
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.
Briefly looking through the code, I find the macros MCRA, MCRB, MSURA,
and MSURB very hard to read (no clue what they stand for). I'd have to
look into it, but I hope there are nicer ways to write that.
It's just a way to save about 250 lines of code for functions that do nothing
than to establish functions that loop over a set of cairo surfaces/contexts
instead of writing to only one surface/context.
void mcr_cairo_arc(double a, double b, double c, double d, double e) MCRA
cairo_arc(*itcrs, a, b, c, d, e); MCRB
would normally be written as
void mcr_cairo_arc(double a, double b, double c, double d, double e)
{
itcrs=crs.begin();
while (itcrs != crs.end()) {
cairo_arc(*itcrs, a, b, c, d, e);
itcrs++; }
}
Also the amount of global variables is worrying...
Ok. A c++ programmer is talking to somebody who likes to use assembly language
;-))
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?
Knut
Re: Cairo based backend
Am Montag, dem 05.07.2021 um 00:10 +0200 schrieb Knut Petersen: > Hi everybody! > > The attached patch implements a new backend based on Cairo. > To test select the desired output formats by any combination of the '--pdf', > '--ps' and '--svg' command line options and add '-dbackend=cairo'. The > '--svg' option must precede the '-dbackend=cairo' option. > > Features: > > * Faster than all other backends. > * It is easy to add support for other image formats. > * Safer than the postscript backend. > * Files that fail with the svg backend produce valid svg output with the > cairo backend. I saw that you opened a merge request (actually, two...), but I think there are some high-level things that should be discussed on the mailing list. The first one is about *how* the backend should be added. In the previous thread, I proposed that it should be optional at first and I meant this to imply that Cairo should not become a required dependency from the beginning. Actually, I think it may be even better to only compile the backend if passing a flag to configure, say --enable-cairo. In particular the requirement on version 1.16 will cut out many active distributions, most importantly Ubuntu 18.04 used in the CI pipelines and representing, more or less, the minimum versions required for LilyPond. (Is there a particular reason for 1.16 or could the code work with older versions? Debian 9 Stretch has 1.14.8 and is supported until next year, but not really required once the backend is optional.) The code in !837 also depends on libpng to write out images, where the use of setjmp made me frown. It appears that Cairo has a (very simple) API available for writing PNGs, any reason not to use that? (Although I'd say the first MR should focus on PDF only as the default format.) Briefly looking through the code, I find the macros MCRA, MCRB, MSURA, and MSURB very hard to read (no clue what they stand for). I'd have to look into it, but I hope there are nicer ways to write that. Also the amount of global variables is worrying... Regards Jonas signature.asc Description: This is a digitally signed message part
