Undo and redo tool for macOS

The PDFNet SDK has a low-level facility for undo and redo operations. It is a API that applies to any edits made to a particular document (not just annotations). It walks back and forth on a fully general, bit-exact list of document states.

Given a set of changes to a document, the undo-redo API allows one to take snapshots after a group of changes. Then, one may move between these snapshots using the API. In return, the functions return objects representing state changes. (It is also possible for one to retrieve objects representing document states in certain ways, if one finds it necessary to keep track of or compare these.)

A fragment of a concrete example:

PDFDoc doc = new PDFDoc(filename);

// Retrieve the undo manager.
UndoManager undo_manager = doc.GetUndoManager();

// Take a snapshot to which we can undo after making changes.
ResultSnapshot snap0 = undo_manager.TakeSnapshot();

// perform some document processing using read write operations 
// found under 'Editing Page Content' or 'Page Manipulation'

// Take a snapshot after making changes, so that we can redo later (after undoing first).
ResultSnapshot snap1 = undo_manager.TakeSnapshot();

if (undo_manager.CanUndo())
{
	ResultSnapshot undo_snap = undo_manager.Undo();
	
	if (undo_manager.CanRedo())
	{
		ResultSnapshot redo_snap = undo_manager.Redo();
	}
}

A low-level facility for undo and redo operations
Full sample code which applies to any edits made to a particular document (not just annotations). It shows how to walk back and forth on a fully general, bit-exact list of document states.

An important thing to realize about the undo-redo API is that saving in a mode that is not 'incremental' will (among other things) wipe out the undo-redo state list; the API will not be able to access old snapshots anymore. The reason for this is that full saves irrevocably change the entire document, whereas incremental saves append changes to the end (thus allowing undos and redos to be done).

Generally speaking, the undo-redo API is driven by the user via calls to the member functions of the UndoManager object (which is in the ::pdftron::SDF namespace in C++), which is retrieved from the PDFDoc via the GetUndoManager member function. Those functions of UndoManager which are concerned with creating or performing state transitions (TakeSnapshot, Redo, Undo) return ResultSnapshots, which represent state transitions (between document states). There are some other functions that allow retrieval of document states (which are represented by DocSnapshots).

The functions which perform state transitions between snapshots (Undo, Redo) are permissive in that attempting to perform transitions when there are no corresponding snapshots will return an invalid snapshot, allowing the user to check their validity. However, it is also possible to use the functions CanUndo and CanRedo to check for the ability to undo and redo prior to performing the undo or redo operation.

In general, undo-redo workflow takes place as follows:

Initialize PDFNet
	Open or create a PDFDoc
	[
		[
			UndoManager TakeSnapshot
			Make some changes
		] (repeat 0-n times)
		
		[
			call UndoManager CanUndo to check if it is possible to undo
			If true, call UndoManager Undo - changes are undone
		] (repeat 0-n times)
		
		[
			Save incrementally
		] (repeat 0-n times)
		
		[
			UndoManager TakeSnapshot
			Make some changes
		] (repeat 0-n times)
		
		[
			call UndoManager CanRedo to check if it is possible to redo
			If true, call UndoManager Redo - changes are undone
		] (repeat 0-n times)
		
		[
			Save incrementally
		] (repeat 0-n times)
	] (repeat 0-n times)

Miscellaneous information: - Save operations themselves do not create new states in the state list. - UndoManager Undo and Redo operations themselves do not save to disk; it is necessary to call Save on PDFDoc.