Create a PDF PoC using a docker image with header less browser.

Previous version of this issue:

## Description Create a new platform application (PoC) for creating PDF files from HTML. ## Acceptance Criteria 1. Substantial WCAG support 2. Performance 3. PDF-A ([about](https://www.princexml.com/doc/prince-output/#pdfa)) ## Test description This test was performed on a dev system and not in any of the test environments, but we believe we've managed to prove that what we want to do is possible. **Start an app**: 1. Start LocalTest and an app. [(instructions)](https://github.com/Altinn/altinn-studio/blob/master/LOCALAPP.md#setup). Choose to run localtest in docker. **Start the PDF-generator image**: 1. Pull the latest browserless.io docker image: `docker pull browserless/chrome` 4. Run the image in docker: `docker run --rm -p 3000:3000 -e "MAX_CONCURRENT_SESSIONS=10" --network development_altinntestlocal_network browserless/chrome:latest` **Create a PDF**: 1. Through localtest (altinn3local.no), start the app to create an instance. 2. Fill in in the form etc, as many steps as you need depending on what part of the app you want to have "printed" as PDF. 3. Open browser dev tools and find the user AltinnStudioRuntime cookie. Copy the value. 4. Create a POST request to generate a PDF. Replace the values for `IP-Address-AppHost` and `AltinnStudioRuntime-Cookie-Value`, in addition to the correct AppId. ``` curl -X POST http://localhost:3000/pdf?token=MY_API_TOKEN -H 'Cache-Control: no-cache' -H 'Content-Type: application/json' -d '{ "url": "http://:5005/ttd/delayed-delete/#/instance/512345/23efbfcc-8f21-47c3-81b8-6f719fa76ffd", "options": { "displayHeaderFooter": true, "printBackground": false, "format": "A4" }, "setJavaScriptEnabled": true, "waitFor": 5000, "cookies": [ { "name": "AltinnStudioRuntime", "value": "", "domain": "" } ] }' -o 'test.pdf' ``` The waitFor option will cause the PDF-generator to wait in 5 seconds before triggering print as PDF. This can be adjusted if the app front-end is quicker.

Description

Set up a PDF-generator test using the browserless/chrome image in an app cluster for TTD in an AT environment. Create an app that use the new service to generate a PDF synchronously upon completing form filling.

Implementations

Helm charts for "PDF-Service" (private repo): dev.azure.com/brreg/altinn-apps-ops App: https://dev.altinn.studio/repos/ttd/pdf-testing-at21

Test results

We can easily use the headless chrome docker image from browserless.io to generate PDF files. We successfully performed a test where we requested the solution to generate a PDF based on HTML generated by an app.

We decieded (16.08.2022) to initially use the following existing apps for testing:

UI-components
Relle rettighetshavere (BR)
Foreldrebetaling (DiHE)

PDF inspection

PDF-A (validator):

The generated PDF is not a PDF-A.

PDF-UA (validator):

Please note that the app used in the test was very simple with only 2 input fields. The validator show that the PDF does contain some basic UA support. The issue with converting HTML to PDF is that the HTML have a div hierarchy to control the flow of the page. A lot of it is necessary for a responsive design. All those divs are also included in the PDF and show up in the validator as elements without tags.

Performance:

This needs more testing. The primary issue with the test performed here is that it waits for 5 seconds before it triggers the print regardless of how long the front-end app actually need. A better solution here would be that the PDF-generator looks for a specific HTML element on the page before triggering print.

The road forward

We postpone all worries related to PDF-A support to a future issue. This allows us to continue the work with browseless.io image without the need for any extra tooling like Ghostscript.
It might be that PDF/A is not required, since
- Archives at service owners must have the ability to convert to PDF/A anyways
- Users are not required to submit data using PDF/A
We continue testing to collect more data about UA support and performance.
- Additional testing should be done with an app page that is significantly larger than the app used so far. Not necessarily form heavy because input fields and checkboxes would normally not be used on a page created for print.

Tasks:

Altinn / altinn-pdf