Added scan filter feature
Description of Changes
Please provide a summary of the changes, including:
This pull request introduces the "Fake Scan" feature, which simulates scanned PDFs with customizable settings. The changes include the removal of a work-in-progress controller, the addition of a new request model, and updates to the frontend to support the feature.
Backend Changes:
- Removed the unfinished
FakeScanControllerWIP: The entireFakeScanControllerWIPclass, which contained unimplemented and experimental code for processing PDFs, has been removed. This cleanup eliminates unused code and dependencies. Some of the original code of removed file was ported to the new Controller. - Added
FakeScanRequestmodel: Introduced a new model classFakeScanRequestto handle input parameters for the "Fake Scan" feature. It includes fields for file input, quality, rotation, colorspace, and other advanced settings, with validation and default values.
Frontend Changes:
- Localization updates for the "Fake Scan" feature: Added new localization keys for the "Fake Scan" feature, including titles, descriptions, and advanced settings options like quality, rotation, and colorspace.
- **Added "Fake Scan" card to the homepage
Pictures:
Front-end
Example document (based on defaults; can be drastically changed according to need.):
Quirks/known issues
- Performance: It might take even reasonable hardware to convert bigger pdf >500KB more than a few minutes.
- Yellowish filter applies to the whole document and also incl to the background. (not desirable in some instances)
- There is some randomness involved in the default preset, helps imitate scan but some user might find it annoying. (but it can be disabled through advanced settings).
- Some features might confusing to people with no additional context.
Closes #458
Checklist
General
- [x] I have read the Contribution Guidelines
- [x] I have read the Stirling-PDF Developer Guide (if applicable)
- [ ] I have read the How to add new languages to Stirling-PDF (if applicable)
- [x] I have performed a self-review of my own code
- [x] My changes generate no new warnings
Documentation
- [ ] I have updated relevant docs on Stirling-PDF's doc repo (if functionality has heavily changed)
- [ ] I have read the section Add New Translation Tags (for new translation tags only)
UI Changes (if applicable)
- [x] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR)
Testing (if applicable)
- [x] I have tested my changes locally. Refer to the Testing Guide for more details.
🚀 Translation Verification Summary
🔄 Reference Branch: pr-branch-messages_en_GB.properties
📃 File Check: messages_en_GB.properties
- Test Status: ✅ Passed
- Test Status: ✅ Passed
- Test Status: ✅ Passed
✅ Overall Check Status: Success
Thanks @Balazs-Szucs for your help in keeping the translations up to date.
/deploypr
🚀 PR Test Deployment
Your PR has been deployed for testing!
🔗 Test URL: http://185.252.234.121:3530 Security Disabled
This deployment will be automatically cleaned up when the PR is closed.
Awesome feature thanks for the work! I think there is some optimisation changes that might be able to be made before release however overall good feature!
Hi!
Thanks for feedback. If there's anything I should do please feel free comment :)
If you wish I can convert this to draft, however if we are talking more minor things then I can just work on them as is. Looking forward to your suggestions :)
As for performance optimisation, I'm not sure what to do, as most PDFBox things probably can't be easily parallelised. (I might need more research on this, but at first I can see an easy way to do it.) it is also noted in Apache forum threads I read that generally PDFBox was not optimized for speed either so there is that.
I think the front end might need some love. I am however generally not that confident with JS things.
General ways to make it more "intuitive" would also be nice, but I also might need guidance on that.
These were some of my thoughts but let me know if there are other things I didn't consider.
Hi!
With the recent Junit pull request by Frooodle, I am wondering if you want me to add unit tests to this feature also? I think it would definitely make sense in general, but if this would be merged as well as the unit testing request then it would leave this endpoint/feature untested while all others would have their unit test.
Hi!
Quick heads up: removed homepage-legacy.html from this pull request to resolve the a conflict.
Hi!
I've improved the fakeScanRequest so that it doesn't complain about deprecated API in 5b657fd
Hi!
Resolved conflicts, made very minor improvements, and resolved import error that stammed from refactor.
/deploypr
🚀 PR Test Deployment
Your PR has been deployed for testing!
🔗 Test URL: http://185.252.234.121:3530 Security Disabled
This deployment will be automatically cleaned up when the PR is closed.