Replace PDF generator

[lvbachmann]

Description

In Altinn/altinn-pdf#13 we decide how we want the PDFs to look. Now we need to decide how to make them - keep developing using the current PDF generator or try to find alternatives?

In this context receipt is the primary concept. PDF is one representation of a receipt. HTML is another way of representing the receipt. A typical flow would be to show the HTML receipt there and then once the user is done with the form, and optionally email a PDF copy to the user. The PDF can also be stored in the users inbox.

ELMER3 has some formalities defined that a receipt needs to confirm to:

• confirmation the the form is received/submitted
• contact information to the organization receiving the submitted form/data
• complete documentation of what communicated through the form (primarily the data sent in)
• other relevant information that important to the user

In scope

• [x] Altinn/altinn-studio#15
• [x] Altinn/altinn-studio#13
• [x] Altinn/altinn-studio#16
• [x] Altinn/altinn-studio#21

Considerations

Do we really need PDF generation capabilities?

YES. It is required by some orgs and it is the only way to support level 4 signing. (document signing)

Can we replace PDF with HTML receipt

YES, for some apps that would be a good option

Can we in first iteration just implement HTML receipt

MAYBE. Would it save time? MAYBE Would depend on requirements.

Overall requirements

The following requirements are expected

• [ ] Receipt can be stored forever
• [ ] Possible to create PDF-A 3 in order to support official archiving standards?
• [ ] PDF needs to be accessible and support WCAG level?
• [ ] Possible to have "dynamics" in receipt
• [ ] Possible for service owner to design how receipt should look
• [ ] Possible for end user to show in archive without app
• [ ] Possible to send receipt in email, primarily to end user

Possible technical approaches

Current

The current approach is to gather form layout and data together with options and send it to the PDF component that understands the custom form layout format.

Pro

• Reuses the formlayout

Cons

• Require Java knowledge for adding more support in PDF component
• Need to send options and other stuff to the external component to make it render the PDF correctly

Generate HTML in App and sendt it to a generic HTML-> PDF Component

In this approach, we add a new HTML backend service in the App that is able to generate HTML from form layout and data.

This HTML would then be sent to an HTML to PDF component.

• All graphics and styling would need to be embedded in HTML.

Pro

• Would be easy to generate HTML for storage
• Easy to configure PDF or HTML receipt

Send URL for print to a separate component

In this scenario, we would need to send a URL together with a user token. The URL would point to a HTML View in the application and when the PDF component calls this URL with the user token the receipt view is loaded.

Pro

• Same URL could be used by the end-user to show receipt at any time in process
• Possible to let the app developer to customization

Cons

• Need to share token
• Possible higher latency?

Consideration

The technology to render HTML can both be server side (like Razor) or based on a javascript frontend.

With a client-side solution it requires a faceless browser to render this.

With a server side it can more easily just bee downloaded by a HTTP client and sendt to a html-> pdf module

Out of scope

TBA

Analysis

TBA

Conclusion

TBA

Tasks

• [ ] Is this issue labeled with a correct area label?
• [ ] QA has been done

[ivarne]

Another suggestion for PDF generation by using a special print view and suggest the user can "print to pdf" in Altinn/apps-backlog#6.

At UDI we created a similar service where the PDF was generated by headless chrome (controlled by selenium (or pupeteer)) just loading a special view of the react app. That way we only had to optimize for print once.

[SandGrainOne]

The current PDF rendering is based on the form layout and pages. Could it be an idea to let the rendering use a separate "confirm layout" as an option?

[ivarne]

I don't really see when that would be nice. Is it common to have so different configuration of pdf and form edit that it can't reasonably be handled by config on a common component and in edge cases duplicating a few components and only showing one in each view?

[SandGrainOne]

My idea came from issue Altinn/app-frontend-react#482 where an app developer would spend time to create a nice layout for the confirmation page.

An important part of the PDF is that it should parrot what the user saw when filling the form and confirming their submission. It isn't given that the form filling part is the best content for a PDF.

[ivarne]

Maybe? It just seems strange that the best approach would be to have 3 copies (form, summary, pdf) of essentially the same information (textResourceBindings, dataModelBindings) to get 3 views of the form data.

[altinnadmin]

At UDI we created a similar service where the PDF was generated by headless chrome just loading a special view of the react app. That way we only had to optimize for print once.

@ivarne This was indeed our "preferred solution" way back, but we did not find a feasable technical solution at the time that covered all the requirements. Do you have some more info about the UDI solution? Is the code available?

[ivarne]

It's not much code except from import puppeteer/selenium (I did both) load the custom URL with a custom auth token, call the pdf method and store the pdf. We used a separate azure function triggered by service bus, because we thought it might crash and we did not want that to block submission.

[TheTechArch]

Initial analysis in sprint 13 march

[SandGrainOne]

Work on this continue in 2 new issues:

• https://github.com/Altinn/altinn-pdf/issues/46 (Team Platform focus on converting HTML to PDF)
• https://github.com/Altinn/app-lib-dotnet/issues/63 (Team Apps focus on generating appropriate HTML)