Haj,
I’ve found Itextsharp which is a c# port of Itext which is the library processing use to export pdf from sketches.
So more than ever, pdf export out from vvvv seems possible but with the current plugin limitation, i only managed to export strings or spread of data out from vvvv.
So, dear dev, is there a way to access to the renderer with the current plugin version ? If not do you plan to integrate such functionnalities in the future ?
regards,
O.
shouldn’t a workaround either with shared memory or converting texture to string be possible? :)
As you can embed image binaries in PDF this would surely a way. But then you would have only raster images in the PDF. In the same spirit you could use ShellExecute to convert a JPG to PDF with some little console applicaton.
Modifying the Renderer itself would not really make sense, as the Renderer is not really having an internal list of things to draw - it just provides some basics and a window for the connected nodes to draw themselves in their specific way. So we would need to rewrite all of the nodes who actually do something any kind of rendering. In case of using shaders the final data of drawn objects do not even reside somewhere in the main memory of your computer, so there is no chance to write them to an pdf. This is also the reason vvvv is generally much faster than processing.
What IS possible and has been discussed occasionally here is writing nodes who basically encapsulate the drawing primitives of the pdf format (some user have done this with EPS files, which use exactly the same graphic primitives as PDF files). So you could just wire your screen rendering and PDF rendering nodes in parallel.
Patching these nodes is basically an application for long nested subpatches mainly made out of [+ (String](https://vvvv.org/documentation/+-(String) nodes with some occasional Map (Value) and AsString (Value) nodes.
Making these nodes compatible to the existing nodes and accepting Transformations and Vertex Buffers would obviously the key to make this a really cool solution. Taking the time to deal with the many bizarre Adobe PostScript/PDF idiosyncrasies which date back to years like 1976 would be also be quite interesting.
But encapsulating textsharp into a set of nodes also sounds like a nice proposal. But indeed the plugin API will not let you transfer vertex buffers, textures or transformations as native pins.
Thx a lot both for theses informations !