-
Notifications
You must be signed in to change notification settings - Fork 1.5k
ENH: Add page-level actions #3382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Sets entries in a page object’s additional-actions dictionary.
Ideally want to be able to add open and close actions. To avoid a future deprecation, can we add this as |
I do not understand what you are referring to. Could you please elaborate? |
I could have described better...
Currently adds either open or close page action. To be able to add both will require modifying the function signature. Or maybe change it so that if given an open action keeps any close action and vice versa. |
We shouldn't have public API that is internal as it might break in the future. Do you have an actual use case for implementing this? Or is this just because the implementation allows this? I have to be honest that I personally never actively used Javascript in PDF files. |
Let me know if you have a good way to modify this, or the functionality requirements needed. Currently use the catalog OpenAction but the JavaScript at page-level is more flexible to only run the JavaScript once opening or closing a page. Will also do a new PR for these tests, as could be in same function? pypdf/tests/test_javascript.py Lines 23 to 51 in 5252c2f
|
I am not completely sure if I can follow you here, but I would just let the user pass the NameObject and document the basics.
Sorry, but I am rather confused what you want to say/ask with this. |
Modified. Is easier to pass a str. Ignore the comment on tests. @stefan6419846 can this PR be merged? |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3382 +/- ##
==========================================
+ Coverage 96.97% 96.99% +0.01%
==========================================
Files 54 56 +2
Lines 9337 9394 +57
Branches 1711 1716 +5
==========================================
+ Hits 9055 9112 +57
Misses 168 168
Partials 114 114 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
pypdf/_page.py
Outdated
else: | ||
self[NameObject("/Annots")] = value | ||
|
||
def add_js(self, javascript: str, /, action_type: Literal["O", "C"] = "O") -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is always tied to an action, why use the generic add_js
name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is at the page level, either opening or closing a page, so although generic is somewhat self-documenting with code completion on a page object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, but how does "self-documenting" and using a specific name correlate here? add_js
sounds rather generic, but this only provides the option to execute JavaScript on opening the page (regardless of whether the PDF standard allows for more JavaScript-related functionality or not).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A page object’s additional-actions dictionary only has two trigger events (when the page is opened or closed) but you are correct there are multiple action types (listed in Table 201 — Action types), and it would be better to have a generalized interface.
add_js
is now add_action
. Because there are many actions this PR will just add a JavaScript action, while providing future extensibility.
@stefan6419846 thanks for the reviews, the previous attempts were not using the correct terminology. Because this function will need to be extensible for future action types, very much welcome your feedback. I could also put this as a discussion.
>>> output.add_action("/C", "JavaScript", 'app.alert("This is page " + this.pageNum);') | ||
# Example: This will display the page number when the page is closed. | ||
Note that this will replace any existing open or close event on this page. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These limitations still sound like we should further refine the public API. add_action
should add the new action in a defined manner, not overwrite existing ones - especially when the specification supports having both events defined on the page, but our API design only allows one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this needs to be robust; and extensible to the many action types. May be worth posting as a discussion to get ideas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can of course open a discussion, but with JavaScript being ignored by many PDF readers and (at least from my experience) limited adoption, I guess there will not be much feedback.
This is one of the reasons why we usually ask to open issues first to discuss new APIs, although we might have missed this there as well and additional feedback would most likely have been sparse as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, feedback and demand may be limited. Although this is initially for JavaScript, it will be extensible and generic for other action types. The many and varied action types means this is a route to upgrading the interactive features that pypdf can provide.
Sets entries in a page object’s additional-actions dictionary.