PDF Tables flow outside margin

minvws / nl-kat-coordination

OpenKAT scans networks, finds vulnerabilities and creates accessible reports. It integrates the most widely used network tools and scanning software into a modular framework, accesses external databases such as shodan, and combines the information from all these sources into clear reports. It also includes lots of cat hair.

https://openkat.nl

European Union Public License 1.2

127 stars 58 forks source link

PDF Tables flow outside margin #2493

Closed zcrt closed 7 months ago

zcrt commented 9 months ago

Describe the bug Tables in the vulnerability section of the new reporting module flow outside of the .pdf-margin, which makes them not readable.

To Reproduce Steps to reproduce the behavior:

Have vulnerablities
Create aggregate report
Look at the pdf

Expected behavior All information visible in the pdf.

OpenKAT version 1.14.1

underdarknl commented 9 months ago

Dear @zcrt Since PDF's are tied to their paper format, what layout options would you prefer? Line-breaks when possible, or some other column count when dealing with tables that might become wide?

We could also possibly move some longer strings out to an apendix to make sure they dont end up growing the tables beyond what is reasonable or expected on paper.

zcrt commented 9 months ago

Dear @underdarknl, It probably depends, though line-breaks sound reasonable. A configurable font-size may also help, as the current font is quite large, thus requiring more space.

Moving out longer strings may be a good solution for some specific vulnerabilities. Especially, when there are multiple vulnerabilities with the same string, which would otherwise result in a lot repetition. Alternatively, some smart aggregation could be applied there. In addition, it is not uncommon for high-resolution PDF's to require zooming capabilities for large tables, though my assumption would be that that is not yet necessary for the current table.

underdarknl commented 8 months ago

Use human readable variants of asset primary keys.
Use references if we know a given string is always going to be too long for the table / pagewidth.

Rieven commented 8 months ago

underdarknl commented 8 months ago

Weasprint has some issues in parsing css. Lets discuss moving to a real browser engine instead.

madelondohmen commented 8 months ago

We've come to the conclusion that more research needs to be done.

A few options have been discussed, but no conclusion has been reached:

Keeping WeasyPrint and making adjustments so that the formatting of the PDF matches the HTML (especially the flexboxes)
Using browser engine PDFs instead of WeasyPrint. The downside is that that this may not support the report flow in the future (with many and large reports)