If we do the following in mutool run: var doc = new mupdf.PDFDocument("test.pdf"); doc.enableJournal() console.log("#1", doc.canUndo(), doc.countPages()) console.log(doc.loadPage(0).toStructuredText().copy([0,0],[1000,1000])) doc.beginOperation("rearrange") doc.deletePage(0) doc.endOperation() console.log("#2", doc.canUndo(), doc.countPages()) console.log(doc.loadPage(0).toStructuredText().copy([0,0],[1000,1000])) doc.undo() console.log("#3", doc.canUndo(), doc.countPages()) console.log(doc.loadPage(0).toStructuredText().copy([0,0],[1000,1000])) // here page 0 is not referencing the page 0 as expected in the console #1 stage, it hasn't appeared to have "undone" the page deletion. Associated issue: https://github.com/ArtifexSoftware/mupdf.js/issues/114
I think the short answer to this is that I hadn't expected to be able to undo across page deletions. Undo/Redo works by capturing PDF object changes. I think page deletion probably changes data structures other than pdf objects, and so undoing doesn't put those back. This is definitely a bug, as (at the very least) the page deletion should clear th undo history. I will have to investigate for a bit to see if I can make undo work with page deletion.
commit 24319da56b1b52585ba996edae8a91d195c3f91b Author: Tor Andersson <tor.andersson@artifex.com> Date: Wed Sep 25 16:44:14 2024 +0200 Bug 708052: Fix life times of objects during undo/redo. Update live pdf_page and pdf_annot objects when reordering pages and using undo and redo. Any pdf_page and pdf_annot objects that point to pages and annotations that are no longer in the document after undo are neutralized by setting the internal pdf_obj pointer to NULL.