Crude PDF stream implementation #781
Conversation
|
Nice.
Could you explain how the current streams are synchronous please? This came up when I was working on revising streams in #740, but I'm not sure in what way a stream can be synchronous. |
|
Because they block the event loop by running on the same thread as V8. For example, this keeps going (with intermittent calls to the JS stream callback) until all data in the Cairo surface has been processed. To make them async, they should run in a separate thread. However, what I would like to see is a way of operating directly on a stream, without storing an entire Cairo surface in memory. For example, create a Canvas bound to a stream which could then be redirected to a file (or a Buffer, or a socket, or anything else). Operations on the Canvas would stream out in chunks, never using more memory than the size of a chunk. A canvas created in this fashion could not conceivably support |
| stream.on('end', function () { | ||
| done(); | ||
| }); | ||
| stream.on('error', function () { |
There was a problem hiding this comment.
Missing err in the functions parameter list...
There was a problem hiding this comment.
Ah, yes. I must have missed it. However, the code always returns CAIRO_STATUS_SUCCESS, since nothing can fail in that sense, so there will actually never be an error event. But I guess it's better to leave it in case someone changes the code in the future.
|
Sorry for the delay on merging this, just one tiny nit and then we're good to go 👍 |
|
Any progress on this? Was the "tiny nit" fixed? |
|
Sorry for the delay, merging now 👍 |
A Minimial Working PDFStream.
Fixes #778
However, I would not advise merging it as such. It would be better to clean up all the streams code, avoiding the need to keep everything in memory and eliminating unnecessary copying of data. It would also be nice to finally have the asynchronous streams. This would entail a major rewrite of the library and its API, which I do not have time to do.