-
-
Notifications
You must be signed in to change notification settings - Fork 688
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
more ViewerPreferences #745
Conversation
address issue Hopding#744
address issue Hopding#744
Hello @mcshaz! It would be awesome to have setters and getters for the ViewerPreferences. Thanks for working on this. Over all the code looks good, but there are some spots that will need to be tweaked to match the patterns & conventions of this codebase. I'll leave some specific review comments in the next few days when I have some time. Though some things I'll just polish up myself after merging. Regarding the rollup and tsconfig changes: If either of those things need to be changed, that should happen in a dedicated PR. I try not to fix code/features with config and compiler changes when possible. For this PR, please implement the logic under the current rollup and tsconfig setup. Please hold off for now on opening a separate PR for rollup/tsconfig changes, those things can impact consumers of the library in unexpected ways and may result in unintentional breaking changes, so they need to be considered very carefully. |
OK I'll remove the target directive - I looked more closely at the TS spec and saw that target might not be a good one to play with as arrow functions will no longer be transpiled to function statements. However, developing in visual studio code, a significant number of files within this library use functions and objects which are not part of the ES5 spec (listed in #747) and are therefore displayed as warnings within the debugger. What about including a lib directive to ES2016. The lib directive is described at https://www.typescriptlang.org/tsconfig#lib-config - obviously I'll put this as a separate pull request. |
ensure it does not show up as a change in the diff
Another question to think about is how to get and set the array pairs to the Let me know your thoughts. |
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.
Thanks again for working on this @mcshaz! I've gone through the PR and made some change requests. Once they're addressed this should be good to merge and release. Let me know if you have any questions!
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.
Thanks again for all your work on this @mcshaz! These new setters/getters will go out in the next release of pdf-lib 🎉
* more ViewerPreferences address issue #744 * PDFHexString ViewerPreferences * Update ViewerPreferences.ts * neaten ViewerPreferences * type assertIsOneOf values * clearer documentation of viewerPreferences * Update tsconfig target * README with viewer pref * tests for viewer preferences * more ViewerPreferences address issue #744 * revert to ES5 target * fix tsconfig es case ensure it does not show up as a change in the diff * address Hopding coments 1 * minor viewerpref doc changes * doc viewerPref with pageMode * set pagemode * test existing viewerPrefs in doc * document viewerPref enums * lint viewerPreferences * comment linting * comments in 0 printpage index
address issue #744 and complete the rest of the spec for ViewerPreferences (with the exception of all key-value pairs for which the spec states 'Most conforming readers disregard it.'). includes documentation and unit tests.
potential further tests not included (but I can write if you tell me your thoughts & where you would like them):
Also address #747 (minor). If you want to support back to ES5, I can alter the Rollup workflow (using babel) so that both a modern and ES5 version of the code is produced, but as per the comments in the issue, I think this should actually be the responsibility of the consuming code.
P.S. I tried a rebase but failed - If you would like to merge this code, can you please squash everything to a single commit during the merge- thanks.