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 :-)

[ReneHollander]

I think only PDF and SVG are currently implemented.

[piranna]

D'oh! :-/ Then, we'll need to look at them directly.

So, PNG y JPEG are extras build on top of Image?

[ReneHollander]

I don't now atm. I am still thinking on how to do it and what is the best way. Maybe move all the export functionality into the backend. So you would need to get for example the png data as follows:
ImageBackend:

canvas.backend.toPNG(function(data) {
  writeToFile("test.png", data);
});

canvas.backend.createPNGStream().pipe(fs.createWriteStream("out.png"));

canvas.backend.toDataUrl(function(data) {
 console.log(data);
});

canvas.backend.toJPEG(function(data) {
  writeToFile("test.jpeg", data);
});

X11 Backend:
Won't have toPNG or toJPEG because the cairo backend doesn't support it.

SVG:

canvas.backend.getSVG(function(xmldata) {
  console.log(xmldata);
})

This change would break everything, but It would be easier to use and would not be as confusing.
But to overcome the issue a little bit, we could inject the functions of the backend with some prototyping into the canvas object directly.

[piranna]

I would start by adding the PDF and SVG backends the same way it's currently done with the FbDev, X11 and Image, and later think about how to integrate the helper functions. It will be easier.

[ReneHollander]

The problem is, if we implement the SVG and PDF backend before fixing the issue that all functions that get the image data are in canvas, we will never be able to get the PDF and SVG data out of the backend. We could draw to it, but thats it...

[piranna]

It's a first start. Maybe it's time to change that API, or maybe it's not
needed to change it at all...
El 25/07/2015 15:39, "Rene Hollander" [email protected] escribió:

The problem is, if we implement the SVG and PDF backend before fixing the
issue that all functions that get the image data are in canvas, we will
never be able to get the PDF and SVG data out of the backend. We could draw
to it, but thats it...

—
Reply to this email directly or view it on GitHub
#4 (comment)
.