We are about to switch to a new forum software. Until then we have removed the registration on this forum.
I want to save the current frame as PDF, but only if a button has been pressed in that frame as well. The examples (e.g. the "PDF Files from 3D Geometry (With Screen Display)" from https://processing.org/reference/libraries/pdf/ appear to do something similar, but are essentially different: they use a variable to then save the NEXT frame.
I'd like to do something like the sample from https://processing.org/reference/beginRaw_.html (below) - to call beginRaw() every frame, and call endRaw() only if a key was pressed - but if no key was pressed at the end of draw(), i'd like to dispose of the recording of the current frame. Since there is not call to something like "disposeRaw()", beginRaw() creates a new PDF file each frame.
import processing.pdf.*;
Boolean saveFrame = false;
void setup() {
size(400, 400, P2D);
}
void draw() {
beginRaw(PDF, "raw"+frameCount+".pdf");
line(pmouseX, pmouseY, mouseX, mouseY);
if (saveFrame == true) endRaw();
else // disposeRaw();
}
void keyPressed() {
if (key == ' ') {
saveFrame = true;
}
}
How would I dispose of PDF file creation for frames which already called beginRaw()?
Answers
Very impressive - thanks!
Your version uses image() to copy the recorded data, resulting in the PDF file to contain a rasterized version - and no longer scalable vector data.
How would I modify your code, so that actual vector data gets exported (of the current frame)?
Thanks!
Sorry for my late reply - was in transit.
Your solution works fine for my initial example - thank you a lot for your energy and dedication!
However, my actual usecase sadly is far more complex, making extended use of a variety of rendering libraries and techniques. It's not really an option to write my own PDF exporter (as this example might give the impression) - I simply don't have access to all required vector data and state changes.
Which brings me back to my initial question: Do we need to write our own PDF exporter if we want to save the current frame? Is it only possible to save the upcoming frame? This seems so weird! It seems a minor, yet fundamental design flaw of that exporter.
Wouldn't a dispose() function for the exporter solve this issue? Right now, we're forced to follow through on an export initiated with beginRaw() - which in most cases is wanted ;) But when trying to export the current frame, it seems too limited.