Fixes the two nightly frontend jobs that started failing after #7163 (new design, part one). Two unrelated causes, one small fix each. ## Accessibility scan (`--c-primary-hover`) The full a11y scan flagged a colour-contrast violation on the portal pipelines ToolPicker story. #7163 moved the light canvas from `--p-gray-50` (#f9fafb) to the slightly darker `--p-paper` (#f5f4f1), but the accent text colour stayed put. That token doubles as the label colour for quiet and tertiary buttons, so the pairing slipped from 4.64:1 to 4.41:1 purely from the background change. Darkening the custom-theme mix from 85% to 80% primary puts it back at 4.89:1. It is also the hover fill for primary buttons, where a marginally deeper blue is if anything more correct. Only the nightly caught this because PR runs scan just the stories whose files changed, and #7163 did not touch that story file. ## Cross-browser Playwright (right-click Copy menu) Failed in Firefox only. The feature itself is fine in every browser. The test hit-tested a word using a fixed fraction of the page box, and the page is auto-fit to the viewer, so the rendered text scales with the viewport. The Firefox and WebKit projects run at 1280x720, where the page renders about 375px wide and the first line of text is only a few pixels tall. #7163 shrank the viewer area slightly (the rails now float with a gutter), which shrank the auto-fit page just enough to tip that fraction to landing below the glyphs. Nothing was selected, so no menu appeared. Pinning 1920x1080 for that one test makes the glyphs comfortably larger than the click tolerance everywhere, rather than re-tuning a fraction that was only ever a couple of pixels from failing. A Firefox skip was considered and rejected: the sibling clipboard test is already Chromium-only and its comment states the Copy menu is covered cross-browser by this test, so skipping would leave the menu with no Firefox coverage at all. ## Verification Test pinned run is green across chromium, firefox and webkit. Contrast checked with the theme linter's contrast report.
Stirling PDF - The Open-Source PDF Platform
Stirling PDF is a powerful, open-source PDF editing platform. Run it as a personal desktop app, in the browser, or deploy it on your own servers with a private API. Edit, sign, redact, convert, and automate PDFs without sending documents to external services.
Key Capabilities
- Everywhere you work - Desktop client, browser UI, and self-hosted server with a private API.
- 50+ PDF tools - Edit, merge, split, sign, redact, convert, OCR, compress, and more.
- Automation & workflows - No-code pipelines direct in UI with APIs to process millions of PDFs.
- Enterprise‑grade - SSO, auditing, and flexible on‑prem deployments.
- Developer platform - REST APIs available for nearly all tools to integrate into your existing systems.
- Global UI - Interface available in 40+ languages.
For a full feature list, see the docs: https://docs.stirlingpdf.com
Quick Start
docker run -p 8080:8080 docker.stirlingpdf.com/stirlingtools/stirling-pdf
Then open: http://localhost:8080
For full installation options (including desktop and Kubernetes), see our Documentation Guide.
Resources
Support
- Community: Discord
- Bug Reports: GitHub Issues
Contributing
We welcome contributions! Please see CONTRIBUTING.md for guidelines.
This project uses Task as a unified command runner for all build, dev, and test commands. Run task dev to get started running the editor, run task to see the most common commands, or see the Developer Guide for full details.
For adding translations, see the Translation Guide.
License
Stirling PDF is open-core. See LICENSE for details.

