I've been conducting a systematic review of our open-source license compliance posture using FOSSA, generating reports for several of our larger repositories. When attempting to share these findings with our legal and security teams via the PDF export function, I've encountered significant and reproducible formatting issues that render the documents nearly unusable for formal review.
The problem manifests specifically in reports exceeding approximately 25 pages. The corruption includes:
* **Page break misalignment:** Content is truncated mid-sentence, with the remainder appearing on the following page after a large, unintended blank space.
* **Table fragmentation:** Dependency tables, which are core to the report, are split in illogical places, often separating column headers from the data rows.
* **CSS overflow failure:** Long package names or license identifiers that should be text-wrapped overflow the cell boundaries, making the text unreadable.
I attempted to mitigate this by testing different report types (e.g., "Third-Party Audit Report" vs. "Compliance Summary") and toggling the "Detailed Findings" option, but the corruption is consistent across all report variants when the page count is high. This suggests an issue with the PDF rendering engine's handling of multi-page, table-heavy documents.
I am operating on version 2.39.14 of the FOSSA CLI, and the exports are generated via the web interface. My workflow is:
1. `fossa analyze`
2. `fossa test`
3. Generate and download the report via the project dashboard.
Has anyone else in the community performed a longitudinal analysis and encountered similar output degradation? I am particularly interested in whether this is a known constraint of the current version or if there are undocumented configuration parameters to control PDF pagination. The lack of machine-readable report formats (like a structured JSON summary) for programmatic consumption exacerbates this issue, forcing a reliance on the broken PDF export for stakeholder communication.
- Dr. C
Nullius in verba
Yes, saw the same in v3.2.1 with our Java monorepo report. The pagination engine can't handle nested tables in large dependency lists.
Workaround: export to HTML and use Chrome's "Print to PDF". Keeps formatting intact. Add "--no-sandbox" if you're running headless.
If you need the native PDF for automation, you're stuck. Their support ticket #SR-8814 has been open for 9 months.
Trust, but verify
HTML workaround works until you try to batch it. Chrome's PDF in headless mode still chokes on memory above 50 pages in my tests.
That support ticket timeline is brutal. It's a core reporting feature.
Benchmarks or bust.
Oof, 9 months? That's discouraging. So even the Chrome workaround hits a wall with bigger batch jobs. Have you found any other tools that handle these long FOSSA reports better, or is everyone just stitching screenshots together?
Yeah, you've nailed the exact symptoms. It's definitely the pagination engine failing on those complex, nested dependency tables. I see it consistently across client projects around that 25-page threshold too.
What's frustrating is that the HTML source it generates is actually valid and well-structured. The issue is entirely in their PDF renderer, which seems to be a secondary, poorly maintained library they've bolted on. I've had clients try to use these corrupted PDFs in official audits and it's caused unnecessary back-and-forth.
One extra nuance I've found: the corruption gets exponentially worse if your project has any custom logo or branding in the report header. It's like the renderer allocates space for the image but then fails to account for it in the page flow for the rest of the document.
Integrate or die
Interesting point about the custom logo making it worse. That tracks with my experience, though I'd pin it more on the CSS box model calculations failing than just the image allocation. Once you introduce a floated or positioned header element, the entire pagination logic seems to fall apart.
It's the classic sign of a brittle, third-party PDF library they haven't invested in. The fact that the HTML is clean proves the core product works, but the export feature is just a black box they can't fix. Makes you wonder if they're even using a supported version of whatever renderer they chose.
Have you noticed if the corruption is predictable? Like, does it always break after the same number of rows in a table, or is it completely random? I'm trying to see if there's a way to pre-emptively structure a report to avoid the triggers, even if it's hacky.
No, stitching screenshots is a non starter for a compliance audit trail.
If you need a clean, automated PDF and the HTML workaround fails, your only real option is to process the HTML yourself. We wrote a small Python script using WeasyPrint. It's deterministic and handles 100+ page reports without the memory issues of headless Chrome.
The FOSSA HTML is clean, so any decent HTML-to-PDF library that isn't their broken one will work. It's an extra step, but it's reliable.
I've seen the same CSS overflow failure specifically with SPDX license identifiers in long dependency lists. The "LicenseRef-MIT-Style-1" type strings breach the cell boundary and then the entire column alignment shifts for subsequent rows, compounding the page break errors you described.
You mentioned testing different report types. Did you also try generating the report with the "Group by License" option toggled off? In my tests, the corruption is more severe when that grouping is active, because it creates more complex, multi-level tables that the PDF renderer can't handle. The flat list view, while less organized, sometimes makes it past the 30-page mark before completely failing.
It's interesting that you see it across all report variants. That points to a fundamental issue in their document assembly pipeline, not just a single template. I'd be curious if the CSV export from those same reports has any oddities, like truncated fields or missing rows.
Logs don't lie.
Yeah, it breaks at 25 pages like clockwork. It's the page renderer's hardcoded buffer size, not your report. They're probably using an unmaintained wkhtmltopdf fork or something equally ancient.
The "detailed findings" toggle just adds more rows to the same broken table layout. You're not fixing it, you're just hitting the overflow faster.
We stopped using their PDF export for anything formal. Print the HTML to PDF from a real browser or script it with something that isn't garbage.
If it ain't broke, don't 'upgrade' it.