Experience with OpenHTMLtoPDF

1. Introduction

During the project, a feature was needed for users to download estimate and document data in PDF format.

Initially, it was thought that simply generating a PDF file would be sufficient, but there were several considerations during the actual review process.

• Korean output support

• Ease of layout modification

• License issues

• Development productivity

• Maintainability

In particular, given the nature of the work where document format change requests often occur, the ability to easily modify the layout is a critical requirement, more so than the actual creation of the PDF itself.

Accordingly, a review of various PDF libraries was conducted to select a suitable technology for the project.

2. Library Review

iText

iText is the most well-known PDF library in the Java ecosystem.

It is feature-rich and has many references, making the implementation difficulty relatively low.

However, there are licensing constraints for commercial use, which necessitated a separate review for project application.

OpenPDF

OpenPDF is an open-source library based on iText that can be used for free.

However, it required writing styles directly at the object level.

As the document structure became more complex, I judged that the amount of code would increase and the maintenance burden would grow.

Apache PDFBox

PDFBox had excellent performance and stability.

However, because most of the layouts had to be created based on coordinates, the development effort was high.

Even simple position changes required coordinate adjustments, making it difficult to respond flexibly to screen design changes.

OpenHTMLtoPDF

OpenHTMLtoPDF is a library that converts HTML to PDF.

The biggest advantage was that it could fully utilize HTML and CSS.

In particular, it was judged that existing publishing assets could be reused and layout modifications could be made at the HTML level, thus enhancing maintainability.

However, since it does not support all browser-level CSS, there are limitations for some advanced layouts.

3. Final Selection

Ultimately, a comparison was made focusing on OpenPDF and OpenHTMLtoPDF.

Considering that the PDF format may change frequently due to the nature of the project, we prioritized development productivity and maintainability.

Accordingly, we finalized the adoption of OpenHTMLtoPDF.

4. Implementation Process

The implementation was divided into three main stages.

1. Retrieve business data.

2. Generate HTML templates based on the data.

3. Convert to PDF files using OpenHTMLtoPDF.

By applying this structure, we were able to separate the PDF generation logic from the screen rendering logic, allowing us to reuse the same generation logic simply by adding new HTML templates in the future.

5. Issues and Security Considerations

 OpenHTMLtoPDF does not support Korean fonts by default.

Therefore, there may be issues with broken Korean characters, and to resolve this, we added fonts that support Korean characters to the resources, and builder.useFont()By explicitly mapping the font at the time of builder creation through the method, we can solve that problem.

OpenHTMLtoPDF is a library that generates PDFs by rendering HTML.

Therefore, if user input values are inserted directly into the HTML, unintended HTML tags may be included, altering the document structure.

To prevent this, during HTML generation, we applied HtmlUtils.htmlEscape() to all user input values, so that HTML tags are converted to strings, preventing user input from affecting the HTML structure.

Additionally, the HTML template is managed on the server, and user input is designed to be inserted only at specified locations within the template.

In particular, areas that can reference external resources during the HTML rendering process, such as images (img), styles (style), and external resource URLs, are not allowed to reflect user input to prevent unintended resource access.

This minimizes the possibility of changes to the HTML structure due to user input and reduces security risks during the PDF generation process.

6. Results

After the adoption of OpenHTMLtoPDF, we were able to achieve the following effects:

• Quick development based on HTML/CSS

• Reduced layout modification costs

• Reusability of publishing assets

• Reduced licensing burden due to free open-source usage

The biggest advantage from a maintenance perspective was that when a change request occurred, only the HTML template needed to be modified without altering the Java code.

7. Conclusion

The PDF generation feature may seem like a relatively simple requirement.

However, in reality, various factors such as licensing, maintainability, security, and support for Korean language had to be considered together.

This work made me realize once again that it is important to consider not only the functionality when selecting technology, but also the long-term maintenance costs and operational convenience.

References
1. https://github.com/danfickle/openhtmltopdf

2. https://itextpdf.com/

3. https://pdfbox.apache.org/

4. https://openpdf.com/

Novin