danfickle / danfickle/openhtmltopdf

A11y rendering NPE on valid markup

Open
#527 1 comment 0 reactions 1 assignee Claimed by @danfickle View on GitHub
Dominant language
Java
Stars
2.2k
Forks
423
PR merge metrics
No merged PRs in 30d

Description

Hello,

I’ve run into repeat null pointer exceptions when spinning out reports once accessibility (and fast mode) are turned on, with seemingly innocuous html strings. For instance:

```


SOMETEXT



```

results in a NPE, while

```


SOMETEXT



```

does not (.pull-left just having a css property of 'float:left', but the markup is in the correct order to be read properly). Our html output that gets processed appears valid, and works perfectly with A11y turned off.

From what we can tell it appears that some of the hierarchy that gets pieced together in the A11y toolset are becoming orphaned.

Here’s a snippet of the stack trace:

```
ERROR [calculationReportExecutor-1] HTMLtoPDFConvertor.createPDFReport(86) | Exception rendering pdf
java.lang.NullPointerException
at org.apache.pdfbox.cos.COSArray.add(COSArray.java:62)
at com.openhtmltopdf.pdfboxout.PdfBoxAccessibilityHelper.finishNumberTree(PdfBoxAccessibilityHelper.java:851)
at com.openhtmltopdf.pdfboxout.PdfBoxFastOutputDevice.finish(PdfBoxFastOutputDevice.java:910)
at com.openhtmltopdf.pdfboxout.PdfBoxRenderer.writePDFFast(PdfBoxRenderer.java:661)
at com.openhtmltopdf.pdfboxout.PdfBoxRenderer.createPdfFast(PdfBoxRenderer.java:550)
at com.openhtmltopdf.pdfboxout.PdfBoxRenderer.createPDF(PdfBoxRenderer.java:468)
at com.openhtmltopdf.pdfboxout.PdfBoxRenderer.createPDF(PdfBoxRenderer.java:405)
at com.openhtmltopdf.pdfboxout.PdfBoxRenderer.createPDF(PdfBoxRenderer.java:387)
at com.gossamer.voyant.report.HTMLtoPDFConvertor.createPDFReport(HTMLtoPDFConvertor.java:83)
```

I've gone through the A11y checklist in the wiki. I did notice that skipped heading levels cause the same exception, and I've got those corrected.

In a fork we have some logging to assist in determining where the failures are occurring in the markup. We’ve tried checking for orphaned boxes and adding them back to the root when it detects the above exception, but this obviously affects the order in which items are read. Is this something that others have handled before?

For context, we have a robust report set with hundreds of templates that are put together dynamically based on customer selections. Things like order, branding, languages and the data used in our images generally are different in each report generation, so to this point narrowing down the pieces of markup that are not working correctly has been a challenge.

Thank you,

Ryan

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.