mirror of
https://github.com/arsvendg/Stirling-PDF.git
synced 2026-07-15 11:00:47 +02:00
4ada46ca567cb6d929a1297845422f6b3cf06e0d
19
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Reece BrowneandGitHub
|
76aa5c7e2f |
Fix encrypted pdf handling (#6088)
Fix and improve encrypted pdf handling |
||
 James BruntonandGitHub
|
a3e45bc182 |
Add frontend autoformatting and set CI to require formatted code for all languages (#6052)
# Description of Changes Changes the strategy for autoformatting to reject PRs if they are not formatted correctly instead of allowing them to merge and then spawning a new PR to fix the formatting. The old strategy just caused more work for us because we'd have to manually approve the followup PR and get it merged, which required 2 reviewers so in practice it rarely got done and just meant everyone's PRs ended up containing reformatting for unrelated files, which makes code review unnecessarily difficult. If the PR's code is not formatted correctly after this PR, a comment will be added automatically to tell the author how to run the formatter script to fix their code so it can go in. This also enables autoformatting for the frontend code, using Prettier. I've enabled it for pretty much everything in the frontend folder, other than 3rd party files and files it doesn't make sense for. I also excluded Markdown because it sounds likely to be more annoying to have to autoformat the Markdown in the frontend folder but nowhere else. Open to changing this though if people disagree. > [!note] > > Advice to reviewers: The first commit contains all of the actual logic I've introduced (CI changes, Prettier config, etc.) > The second commit is just the reformatting of the entire frontend folder. > The first commit needs proper review, the second one just give it a spot-check that it's doing what you'd expect. |
||
 ConnorYohandGitHub
|
0e29640766 |
fix: get all Playwright E2E tests loading and expand CI to run full suite (#6009)
## Fix Playwright E2E tests and expand CI to run full suite ### Problem The full Playwright suite was broken in two ways: 1. **`ConvertE2E.spec.ts` crashed at import time** — `conversionEndpointDiscovery.ts` imported a React hook at the top level, which pulled in the entire component tree. That chain eventually required `material-symbols-icons.json` (a generated file that didn't exist), crashing module resolution before any tests ran. 2. **CI only ran cert validation tests** — both `build.yml` and `nightly.yml` hardcoded `src/core/tests/certValidation` as the test path, silently ignoring everything else. ### Changes **`ConvertE2E.spec.ts` — complete rewrite** The old tests were useless in practice: all 9 dynamic conversion tests were permanently skipped unless a real Spring Boot backend was running (they called a live `/api/v1/config/endpoints-enabled` endpoint at module load time). Replaced with 4 focused tests that use `page.route()` mocking — no backend required, same pattern as `CertificateValidationE2E`. New tests cover: - Convert button absent before a format pair is selected - Successful PDF→PNG conversion shows a download button (mocked API response) - API error surfaces as an error notification - Convert button appears and is enabled after selecting valid formats **`conversionEndpointDiscovery.ts` — deleted** Only existed to support the old tests. The `useConversionEndpoints` React hook it exported was never imported anywhere else. **`ReviewToolStep.tsx`** Added `data-testid="download-result-button"` to the download button — required for the happy-path test assertion. **CI workflows (`build.yml`, `nightly.yml`)** - Added a `Generate icons` step before Playwright runs (`node scripts/generate-icons.js`) — the icon JSON is generated by `npm run dev` locally but skipped by `npm ci` in CI - Removed the `src/core/tests/certValidation` path filter so the full suite runs |
||
|
ConnorYohandGitHub
|
dd44de349c |
Shared Sign Cert Validation (#5996)
## PR: Certificate Pre-Validation for Document Signing ### Problem When a participant uploaded a certificate to sign a document, there was no validation at submission time. If the certificate had the wrong password, was expired, or was incompatible with the signing algorithm, the error only surfaced during **finalization** — potentially days later, after all other participants had signed. At that point the session is stuck with no way to recover. Additionally, `buildKeystore` in the finalization service only recognised `"P12"` as a cert type, causing a `400 Invalid certificate type: PKCS12` error when the **owner** signed using the standard `PKCS12` identifier. --- ### What this PR does #### Backend — Certificate pre-validation service Adds `CertificateSubmissionValidator`, which validates a keystore before it is stored by: 1. Loading the keystore with the provided password (catches wrong password / corrupt file) 2. Checking the certificate's validity dates (catches expired and not-yet-valid certs) 3. Test-signing a blank PDF using the same `PdfSigningService` code path as finalization (catches algorithm incompatibilities) This runs on both the participant submission endpoint (`WorkflowParticipantController`) and the owner signing endpoint (`SigningSessionController`), so both flows are protected. #### Backend — Bug fix `SigningFinalizationService.buildKeystore` now accepts `"PKCS12"` and `"PFX"` as aliases for `"P12"`, consistent with how the validator already handles them. This fixes a `400` error when the owner signed using the `PKCS12` cert type. #### Frontend — Real-time validation feedback `ParticipantView` gains a debounced validation call (600ms) triggered whenever the cert file or password changes. The UI shows: - A spinner while validating - Green "Certificate valid until [date] · [subject name]" on success - Red error message on failure (wrong password, expired, not yet valid) - The submit button is disabled while validation is in flight #### Tests — Three layers | Layer | File | Coverage | |---|---|---| | Service unit | `CertificateSubmissionValidatorTest` | 11 tests — valid P12/JKS, wrong password, corrupt bytes, expired, not-yet-valid, signing failure, cert type aliases | | Controller unit | `WorkflowParticipantValidateCertificateTest` | 4 tests — valid cert, invalid cert, missing file, invalid token | | Controller integration | `CertificateValidationIntegrationTest` | 6 tests — real `.p12`/`.jks` files through the full controller → validator stack | | Frontend E2E | `CertificateValidationE2E.spec.ts` | 7 Playwright tests — all feedback states, button behaviour, SERVER type bypass | #### CI - **PR**: Playwright runs on chromium when frontend files change (~2-3 min) - **Nightly / on-demand**: All three browsers (chromium, firefox, webkit) at 2 AM UTC, also manually triggerable via `workflow_dispatch` |
||
|
Reece BrowneandGitHub
|
63d38e382d |
Chore/v2/transforms as root (#5868)
Any task that changes file type or produces more/fewer files than the input are now consumed as root files not incremented versions of the input. |
||
  
|
9b0610b2cc |
feat: split pdf into small chunks by pdfbox (#5718)
Co-authored-by: Ubuntu <[email protected]> Co-authored-by: Anthony Stirling <[email protected]> |
||
 Balázs SzücsandGitHub
|
91b4a3484c | feat(conversion): add PDF to Excel (XLSX) conversion (#5778) | ||
|
b8ce4e47c1 |
Preserve local paths for desktop saves (#5543)
# Summary - Adds desktop file tracking: local paths are preserved and save buttons now work as expcted (doing Save/Save As as appropriate) - Adds logic to track whether files are 'dirty' (they've been modified by some tool, and not saved to disk yet). - Improves file state UX (dirty vs saved) and close warnings - Web behaviour should be unaffected by these changes ## Indicators Files now have indicators in desktop mode to tell you their state. ### File up-to-date with disk <img width="318" height="393" alt="image" src="https://github.com/user-attachments/assets/06325f9a-afd7-4c2f-8a5b-6d11e3093115" /> ### File modified by a tool but not saved to disk yet <img width="357" height="385" alt="image" src="https://github.com/user-attachments/assets/1a7716d9-c6f7-4d13-be0d-c1de6493954b" /> ### File not tracked on disk <img width="312" height="379" alt="image" src="https://github.com/user-attachments/assets/9cffe300-bd9a-4e19-97c7-9b98bebefacc" /> # Limitations - It's a bit weird that we still have files stored in indexeddb in the app, which are still loadable. We might want to change this behaviour in the future - Viewer's Save doesn't persist to disk. I've left that out here because it'd need a lot of testing to make sure the logic's right with making sure you can leave the Viewer with applying the changes to the PDF _without_ saving to disk - There's no current way to do Save As on a file that has already been persisted to disk - it's only ever Save. Similarly, there's no way to duplicate a file. --------- Co-authored-by: James Brunton <[email protected]> Co-authored-by: James Brunton <[email protected]> |
||
|
Balázs SzücsandGitHub
|
0f5a0e694a |
feat:(pdfa-conversion) Implement Strict PDF/A Mode with Verification (#5663)
# Description of Changes This PR introduces a new "Strict Mode" for the PDF to PDF/A conversion tool. When enabled, the application will use VeraPDF to verify that the resulting file is perfectly compliant with the selected PDF/A standard. If validation fails, the system will return a descriptive error instead of a non-compliant file. <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> <img width="371" height="993" alt="image" src="https://github.com/user-attachments/assets/a22d50b0-ad7c-46b0-be79-b79c2bc80d92" /> --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing) for more details. --------- Signed-off-by: Balázs Szücs <[email protected]> |
||
|
|
4d84dcdd42 |
[V2] feat(convert): add PDF/X export option (#5285)
# Description of Changes This pull request adds support for converting PDF files to PDF/X format in the frontend, alongside the existing PDF/A conversion. The changes include UI updates, translation strings, configuration, and processing logic to enable PDF to PDF/X conversion using the same backend endpoint as PDF/A, with appropriate user options and warnings. **PDF/X Conversion Support:** - Added a new `ConvertToPdfxSettings` component for configuring PDF/X conversion options, including output format selection and digital signature warnings. (`frontend/src/core/components/tools/convert/ConvertToPdfxSettings.tsx`) - Updated the conversion settings UI to display PDF/X options when converting from PDF to PDF/X. (`frontend/src/core/components/tools/convert/ConvertSettings.tsx`) **Configuration and Processing Logic:** - Extended conversion constants and parameters to recognize PDF/X as a target format, map it to the PDF/A backend endpoint, and ensure correct file naming and processing behavior. (`frontend/src/core/constants/convertConstants.ts`, `frontend/src/core/hooks/tools/convert/useConvertOperation.ts`, `frontend/src/core/hooks/tools/convert/useConvertParameters.ts`) - Ensured that PDF/X conversions are processed separately per file, similar to PDF/A. (`frontend/src/core/hooks/tools/convert/useConvertOperation.ts`) **UI and Translation Updates:** - Updated translation strings to include PDF/X options, descriptions, and warnings. (`frontend/public/locales/en-GB/translation.toml`) <img width="366" height="998" alt="image" src="https://github.com/user-attachments/assets/b28fa095-9350-4db2-a0b5-bddcf003fa46" /> <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing) for more details. --------- Signed-off-by: Balázs Szücs <[email protected]> Co-authored-by: Anthony Stirling <[email protected]> |
||
|
|
b00bd760c8 |
feat(conversion): add PDF to EPUB/AZW3 conversion support and settings (#5434)
# Description of Changes This pull request introduces support for converting PDF files to eBook formats (EPUB and AZW3) in the frontend. It adds new user interface options for PDF-to-eBook conversion, updates the conversion logic and parameters, and ensures the new formats are integrated into the conversion matrix and endpoints. The most important changes are grouped below: **PDF to eBook (EPUB/AZW3) Conversion Support** * Added a new `ConvertToEpubSettings` component that provides UI controls for PDF-to-eBook options, including chapter detection, target device selection, and output format. (`frontend/src/core/components/tools/convert/ConvertToEpubSettings.tsx`) * Updated `ConvertSettings` to render the new eBook options when converting from PDF to EPUB or AZW3, and set default values for these options. (`frontend/src/core/components/tools/convert/ConvertSettings.tsx`) * Extended the `ConvertParameters` interface and default parameters to include `epubOptions` for the new settings. (`frontend/src/core/hooks/tools/convert/useConvertParameters.ts`) **Conversion Logic and API Integration** * Updated the conversion endpoints, endpoint names, and conversion matrix to support PDF-to-EPUB/AZW3 conversions. (`frontend/src/core/constants/convertConstants.ts`) * Modified the conversion operation logic to handle `epubOptions` and ensure that PDF-to-eBook conversions process each file separately and send the correct options to the backend. (`frontend/src/core/hooks/tools/convert/useConvertOperation.ts`) **Localization and Tool Registry Updates** * Added localization strings for the new eBook conversion options. (`frontend/public/locales/en-GB/translation.toml`) * Registered the new PDF-to-eBook operation in the tool catalog and test helpers. (`frontend/src/core/data/useTranslatedToolRegistry.tsx`, `frontend/src/core/tests/helpers/conversionEndpointDiscovery.ts`) <img width="364" height="995" alt="image" src="https://github.com/user-attachments/assets/c54c50c0-1b86-4074-aef8-b038c6caeb49" /> <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> --- ## Checklist ### General - [X] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [X] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (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](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### 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](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing) for more details. Signed-off-by: Balázs Szücs <[email protected]> Co-authored-by: Anthony Stirling <[email protected]> |
||
|
Balázs SzücsandGitHub
|
84ed1d7ecb |
feat(conversion): refactor EML parser to use Simple Java Mail library and add MSG support (#5427)
# Description of Changes Note on Simple Java Mail: - SJM contains Angus/Jakarta Mail in it. - SJM is a very thin layer on Angus Mail; see here: https://github.com/bbottema/simple-java-mail - SJM gives high level methods to more reliably parse in email via Angus Mail, but also contains lots of other interesting features. - SJM is Apache 2 licensed This pull request updates the email processing utilities to add support for parsing and validating Outlook MSG files, refactors the `EmlProcessingUtils` utility class to use instance methods and improved resource management, and enhances the handling and styling of generated email HTML. The changes also introduce external CSS resource loading with a fallback mechanism, and update dependencies to support MSG file parsing. **MSG file support and validation:** - Added `simple-java-mail` and `outlook-module` dependencies to enable EML and MSG file parsing, and updated validation logic to recognize and accept MSG files by checking their magic bytes. (`app/common/build.gradle`, `EmlProcessingUtils.java`) **Refactoring and modernization of `EmlProcessingUtils`:** - Converted static methods and fields in `EmlProcessingUtils` to instance methods/fields, improving testability and future extensibility. (`EmlProcessingUtils.java`) **Enhanced HTML/CSS styling for email rendering:** - Updated HTML generation to use consistent formatting and improved style variable usage, and refactored CSS injection to load from an external resource (`email-pdf-styles.css`) with a synchronized cache and a minimal fallback if the resource is missing. (`EmlProcessingUtils.java`) **Attachment and content rendering improvements:** - Improved the formatting of meta-information (e.g., CC, BCC, Date) and attachment sections in generated email HTML, and ensured more robust handling of empty or missing content. (`EmlProcessingUtils.java`) **General code cleanup and logging:** - Added SLF4J logging for error handling when loading CSS resources, and cleaned up imports and method signatures for clarity and maintainability. (`EmlProcessingUtils.java`) <img width="367" height="991" alt="image" src="https://github.com/user-attachments/assets/0cfb959c-da92-4cff-9e52-ff4ab7fa806e" /> <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> --- ## Checklist ### General - [X] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [X] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md) (if applicable) - [X] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (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](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] 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](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing) for more details. --------- Signed-off-by: Balázs Szücs <[email protected]> |
||
|
|
182eb504de |
[V2] feat(convert): add support for CBR to PDF and PDF to CBR conversions (#4833)
# Description of Changes TLDR: - Introduced `ConvertFromCbrSettings` and `ConvertToCbrSettings` components for handling conversion-specific settings. - Updated `ConvertSettings` to include CBR-related configurations. - Updated `useConvertParameters` with new parameters: `cbrOptions` and `pdfToCbrOptions`. - Updated locales with CBR-related translations. - Added endpoints and updated conversion matrix for CBR formats in `convertConstants`. - Modified `useConvertOperation` to handle CBR-specific parameters during form data preparation. For backend see this PR: #4581 This pull request adds support for converting between CBR (Comic Book Archive) and PDF formats in the frontend. It introduces new UI components for configuring conversion options, updates the conversion constants and logic, and ensures parameters for these conversions are handled correctly throughout the app. **CBR/PDF Conversion Features:** * Added new UI components: `ConvertFromCbrSettings` for CBR to PDF conversions (option to optimize for ebook readers), and `ConvertToCbrSettings` for PDF to CBR conversions (DPI selection for image rendering). These are conditionally rendered in `ConvertSettings.tsx` based on selected formats. **Conversion Logic and Constants:** * Extended conversion endpoints, format options, conversion matrix, and endpoint mappings to support CBR to PDF and PDF to CBR conversions. * Updated `shouldProcessFilesSeparately` logic to handle PDF to CBR conversions, ensuring each PDF generates its own archive. **Parameter Handling:** * Added new parameters (`cbrOptions` and `pdfToCbrOptions`) to the conversion parameter interface and default values, ensuring they are set/reset appropriately during format changes * Modified form data construction to include new options for CBR/PDF conversions (optimize for ebook, DPI). ### Frontend <img width="1291" height="861" alt="image" src="https://github.com/user-attachments/assets/fb63be66-6f40-4dde-8235-86c9ddfa1f7c" /> <img width="1411" height="1000" alt="image" src="https://github.com/user-attachments/assets/529593c4-6f32-4b11-9754-7f334f40d32e" /> Note on RAR5. You can go back-and-forth with this converter due to the fact on default pdf to cbr makes RAR5 meanwhile, cbr to pdf can only RAR4 and below. This is unfortunate limitation of JunRAR library. In the real world, generally RAR5s are not that common, and they mostly unsupported by open-source software. <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> --- ## Checklist ### General - [X] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [X] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (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](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### 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](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing) for more details. --------- Signed-off-by: Balázs Szücs <[email protected]> Co-authored-by: Anthony Stirling <[email protected]> Co-authored-by: Reece Browne <[email protected]> |
||
|
James Brunton
|
cddd5e7d15 | Convert V2 translations to Toml | ||
|
Balázs SzücsandGitHub
|
a05c5a53c7 |
[V2] feat(convert): add support for CBZ to PDF and PDF to CBZ conversion (#4831)
# Description of Changes TLDR: - Implemented `ConvertFromCbzSettings` component for CBZ to PDF options - Added `ConvertToCbzSettings` component for PDF to CBZ options - Extended conversion constants with new CBZ-related formats and mappings - Updated `ConvertSettings` to include CBZ-specific configuration forms - Updated `useConvertOperation` to handle CBZ conversion parameters For backend reference see this PR: #4472 This pull request adds support for converting between CBZ (Comic Book Zip) and PDF formats in the frontend conversion tool. It introduces new UI components for CBZ-to-PDF and PDF-to-CBZ conversion options, updates the conversion parameters and form data logic, and integrates these formats into the available conversion options and endpoints. **CBZ/PDF Conversion Support:** * Added `ConvertFromCbzSettings` and `ConvertToCbzSettings` components to provide user options for CBZ-to-PDF and PDF-to-CBZ conversions, including "Optimize for ebook" and DPI settings. **Conversion Logic and Parameters:** * Extended the `ConvertParameters` interface and default parameters to include `cbzOptions` (for CBZ-to-PDF) and `cbzOutputOptions` (for PDF-to-CBZ). **Conversion Matrix and Endpoint Integration:** * Added CBZ to the supported "from" and "to" format lists, updated the conversion matrix to allow CBZ-to-PDF and PDF-to-CBZ, and mapped the new conversions to appropriate API endpoints. * Updated URL mapping to recognize `/cbz-to-pdf` and `/pdf-to-cbz` as conversion tool routes. ### Front-end <img width="1852" height="994" alt="image" src="https://github.com/user-attachments/assets/b902438a-8ce7-4eed-a4f8-d80677c0c796" /> <img width="270" height="994" alt="image" src="https://github.com/user-attachments/assets/87556380-e0c5-4974-93c2-d36f86268b49" /> <img width="417" height="389" alt="image" src="https://github.com/user-attachments/assets/1889a3ec-0c06-442a-b3bb-71e1a7c34e4c" /> <img width="1853" height="994" alt="image" src="https://github.com/user-attachments/assets/d6d68f5f-ed70-4be9-89b1-2e4b7cd90921" /> <img width="265" height="994" alt="image" src="https://github.com/user-attachments/assets/36a05dd5-164f-46a7-b8af-aa815d6c0767" /> <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> --- ## Checklist ### General - [X] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [X] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (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](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### 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](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing) for more details. --------- Signed-off-by: Balázs Szücs <[email protected]> |
||
|
|
74a1438c21 |
[V2] feat(unzip/front-end): Implement ZIP extraction confirmation for archives over 20 files (#4834)
# Description of Changes TLDR: - Introduced a user confirmation dialog for extracting ZIP files with more than **20 files**. - Created `useZipConfirmation` hook to handle confirmation dialog logic and state. - Implemented `ZipWarningModal` component to display the confirmation dialog. - Updated `zipFileService` to count files in ZIP and trigger confirmation callback for large files. - Integrated confirmation flow into `FileContext` and `useToolResources`. - Added translations for new ZIP warning dialog messages. This pull request introduces a user confirmation dialog when attempting to extract large ZIP files (**over 20 files**), improving safety and user experience by preventing accidental extraction of very large archives. The implementation includes a reusable confirmation modal, a custom hook to handle dialog state and resolution, and updates to the ZIP extraction logic to support this workflow. **User Experience Improvements** * Added a new localized warning dialog (`ZipWarningModal`) that prompts users for confirmation when extracting ZIP files containing more than 20 files. This dialog displays the ZIP file name, file count, and offers "Cancel" and "Extract" actions, with responsive layouts for desktop and mobile **ZIP Extraction Workflow Enhancements** * Updated the ZIP extraction logic in `ZipFileService` to count the number of files in a ZIP and invoke a confirmation callback if the file count exceeds the threshold. Extraction proceeds only if the user confirms; otherwise, the ZIP remains unextracted. * Added a new hook (`useZipConfirmation`) to manage the confirmation dialog’s state and provide a promise-based API for requesting user confirmation. **Integration with Application State** * Integrated the confirmation workflow into `FileContext`, passing the confirmation function into ZIP extraction calls and rendering the modal dialog at the appropriate time. * Updated relevant interfaces and method signatures to support the optional confirmation callback for large ZIP extractions throughout the codebase. <img width="515" height="321" alt="image" src="https://github.com/user-attachments/assets/f35a7588-4635-4ccd-9ee6-95edb17fee99" /> <img width="515" height="321" alt="image" src="https://github.com/user-attachments/assets/0525acf3-4174-42cd-8912-910e754c467c" /> <!-- Please provide a summary of the changes, including: - What was changed - Why the change was made - Any challenges encountered Closes #(issue_number) --> --- ## Checklist ### General - [X] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [X] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (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](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### 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](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing) for more details. --------- Signed-off-by: Balázs Szücs <[email protected]> Co-authored-by: Anthony Stirling <[email protected]> |
||
|
James BruntonandGitHub
|
45389340ed |
Remove ambiguous translations and fix invalid translations (#4841)
# Description of Changes
`i18next` allows this pattern for translations, which we use quite a few
times in our current translation files:
```json
{
"a": {
"b": "hello"
},
"a.b": "world"
}
```
This makes it ambiguous when selecting `a.b` which string will be
retrieved. We have seen issues in other languages in the current release
like this:
<img width="325" height="249" alt="image"
src="https://github.com/user-attachments/assets/f24a29f0-550f-49b8-b355-c5e5eb436558"
/>
because we are expecting this:
<img width="1022" height="210" alt="image"
src="https://github.com/user-attachments/assets/b6d5cdd4-96cd-4b2b-8f1a-465da8bf70c8"
/>
but the Spanish file has:
<img width="312" height="136" alt="image"
src="https://github.com/user-attachments/assets/1e13392c-8484-47d1-b0c4-19d52b3ea5eb"
/>
and no `removeDigitalSignature` key on its own.
This PR resolves all of these ambiguities in the source by restructuring
all of the keys to uniquely target either an object or a string, not
both. It also adds a test which will fail on any keys with a `.` in
their name, therefore making it impossible to add anything ambiguous.
|
||
|
James BruntonandGitHub
|
85ec882950 |
Improve diff for missing translations test (#4790)
# Description of Changes Improve diff for missing translations test |
||
|
James BruntonandGitHub
|
d2b38ef4b8 |
Restructure frontend code to allow for extensions (#4721)
# Description of Changes Move frontend code into `core` folder and add infrastructure for `proprietary` folder to include premium, non-OSS features |