Reimplement PDF and SVG backend

[ReneHollander]

Reimplement the svg and pdf backend removed in 454691b

[piranna]

I think this should be the ones that needs more attention, since the tests are not passing (so it will not be accepted upstream) and also seems there's some movement there regarding this backends, so we need to fix them as soon as possible to don't get outdated.

[ReneHollander]

👍
I just stopped development for the moment, because I saw work on a new branch. If this branch gets merged we have a ton of things to fix so I decided to wait until it gets merged before I add more features...

[ReneHollander]

Shoudl have posted the actual merge request for more infos: Automattic#580

[piranna]

Oh, ok, good idea 👍 I don't think that these changes on that branch would make too much hurt so I would continue with the PDF & SVG support, but if you want to wait, it's good to me :-)

[ReneHollander]

It should be straight forward to fix I hope...
I will look into getting your changes to the gyp files and related things merged first and then look into reimplementing the backends.

also seems there's some movement there regarding this backends

Where did you get this information from?

[piranna]

I've read the topic and seems there's still too much time that NAN-2 is available, so I would retake the work against master and try to get it merged... X11 is giving some problems for some basic examples (only one that seems to work is the animated clock, so there's some extrange filling issues). Also you can be able to take a look for my backend API improvements and give some comments :-)

[piranna]

I will look into getting your changes to the gyp files and related things merged first and then look into reimplementing the backends.

Ok 👍

Where did you get this information from?

When I merge the code from @Automattic I get a conflic on src/Canvas.cc, and reviewing it I saw the added two included for cairo-pdf.h and cairo-svg.h...

[ReneHollander]

Ok

[ReneHollander]

I think the biggest problem with those backends is, that we need to move all the code for toBuffer, toPNG/JPEGStream and all the sync and async stuff into the backend system. It looks really messy and I have no idea where to start...
Or we check by the name of the backend and then just do sume other stuff in the toBuffer method like they are doing it...

[piranna]

I think the biggest problem with those backends is, that we need to move all the code for toBuffer, toPNG/JPEGStream and all the sync and async stuff into the backend system. It looks really messy and I have no idea where to start...

I think this is really buggy, at leask PNGStream. I've got a lot of problems with the FbDev and X11 backends like invaid mode or something similar... Don't know why but seems they are incompatible...

And to be honest, I think this "extras" should be removed from node-canvas to an independent module and node-canvas focus only on standard Canvas API:

Or we check by the name of the backend and then just do sume other stuff in the toBuffer method like they are doing it...

This seems hackerish, and in fact the backend mechanism could be able to fix this kind of things. What others backends are there at this moment?

[ReneHollander]

I think this is really buggy, at leask PNGStream. I've got a lot of problems with the FbDev and X11 >backends like invaid mode or something similar... Don't know why but seems they are incompatible...

And to be honest, I think this "extras" should be removed from node-canvas to an independent module >and node-canvas focus only on standard Canvas API:

I am looking into a different library (LodePNG) to encode the data to a png image.

This seems hackerish, and in fact the backend mechanism could be able to fix this kind of things. What others backends are there at this moment?

Only X11, FBDev and Image at the moment.

[piranna]

Only X11, FBDev and Image at the moment.

I was talking about backends on node-canvas that need to be ported :-P Maybe there would be others easier than PDF and SVG to be done first :-)