PDF XChange Forum

PDF-XChange doesn't add an item to the undo list when annotations are added through javascript. To reproduce, run this in console with a single page pdf open:

Hi Mathew,
Yes, annotations added by a script cannot be undone. This behaviour is by design and aims to prevent flooding the undo list with operations that the user can be unaware of.

Understood. But it's a bit inconsistent because modifying annotations does have an undo.

Could I request a feature to be able to set a flag within javascript for when undos are tracked as a single "undo", such as:

Hello, Mathew

Thank you for the suggestion, If there was a way to classify the entire script as a single "undo step" that would certainly be a viable solution. I will forward this idea to the Devs to see what can be done in that respect, but I cannot make any promises at this time.

Kind regards,

Yes, Mathew, you are right about the inconsistency.
We should exclude annotation modification from the undo list as well, when done from script.
We will discuss your proposed feature and let you know. However, it is unlikely to be included in the upcoming release of the Editor because lack of time.

Oh No! please don't exclude annotation modification done by a script. That could be very aggravating, especially if the script did something I don't want it to do.

I think excluding script actions from the undo list is very counterintuitive. If I run a script that makes changes on a document, if the undo ignores it, I won't be able to save the changes (PDF-XChange will act like nothing has changed). I have to make a manual change before it even un-greys the save button.

Case in point: I made a tool to draw hatch patterns on shapes, but the new pattern does not show up as an undo option. You can undo everything, and still the hatch pattern is there.

Generally, people expect undo to return the document to the state it was before the last operation they did. The current implementation does not do that.

I've been thinking about this: One of the stellar aspects of PDF-XChange is the robust JavaScript support (besides the great tech support, that we don't have to use a subscription, the UI, all the great functionality...) It allows me to make scripts when there's something repetitive or inconvenient and not rely on it being part of the software.

I agree that it is a mess when all the individual actions a script may do become individual undo items, so making it default to not record undo's during scripts feels like a simple workaround: However, allowing a script to run and make changes to a pdf without any evidence of those changes seems like both a security issue and counterintuitive for a user.

Ideal in my mind would be the following:

• By default, actions that change the document are recorded in the script individually.
• If a user doesn't like the mess this causes, there could be a preference option to not record scripted changes to undo.
• Scripts can invoke a queuing mechanism such as begin/endUndoQueue() and a way to either discard that queue or save it (ie if a script makes temporary changes to a document it would be good to be able to discard them along with the temporary change - see 'preview' in the hatch script listed below)

I understand it's a big ask, as I have no idea how that could really be implemented and not break scripts that go to other PDF applications. I think it would add hugely to the JavaScript power in PDF-XChange, because scripts could work like built-in functionality.

An example of a script that adds multiple undo steps from one script run is my mirror annotations tool: viewtopic.php?t=39917

An example of a script that makes changes to the document that are invisible to undo is my hatch tool: viewtopic.php?t=40329

BTW the functionality I'm thinking of is similar to php's ob_start() ob_end_flush() ob_end_clean() for output buffering: https://www.php.net/manual/en/function.ob-start.php

Mathew wrote: ↑Wed May 31, 2023 1:53 am I think excluding script actions from the undo list is very counterintuitive. If I run a script that makes changes on a document, if the undo ignores it, I won't be able to save the changes (PDF-XChange will act like nothing has changed). I have to make a manual change before it even un-greys the save button.

No, the document we be marked as modified anyways.

I agree with you that this is a good idea to have a way to enable logging script operations in the undo list. I just discussed it with the team and it was generally welcome.

Mathew wrote: ↑Tue May 30, 2023 6:27 pm PDF-XChange doesn't add an item to the undo list when annotations are added through javascript.

It adds an undo item for every other change javascript does to annotations. I agree that it's not great to be adding many, many undos, but at least until a better way (such as grouping undos within scripts), can this be changed to be consistent? It currently makes for some really strange situations when javascript moves annotations, or makes changes, and also adds annotations. The added annotations stay put and cannot be undone, but everything else can be undone, including deleting that annotation. Run this script and then undo:

Hi, Mathew

We need to have an internal discussion of this feature, as it affects not only the Javascript api.

In general we should be careful with any product specific extensions to the JS api, as it increases the probability of name conflicts - some scripts that work as expected in Actobat may start to behave differently in the Editor.