Inquiry: Contribution & Collaboration Details for openpdf-html / openpdf-render

[wang0331]

Background

I am currently diving deep into the openpdf-html and openpdf-render modules and planning to contribute code to the project.

To work more efficiently, avoid unnecessary conflicts, and make contributions aligned with the project’s long-term goals, I would like to ask for some key information from the maintainers.

Questions

1. Competitor Differences & Technical Blockers

I would like to understand the core differences between OpenPDF (especially the html/render modules) and mainstream PDF libraries such as iText, PDFBox, Aspose.PDF:

• Core advantages and disadvantages in functionality
• Known technical blockers (architectural limitations, performance bottlenecks, compatibility issues, etc.)
• Besides GitHub Issues, are there other resources (docs, roadmap, community discussions, etc.) I can use to gather this information for planning solutions?

2. Code Submission & Update Workflow

To avoid conflicts and contribute efficiently:

• What is the current code update process (branching strategy, PR review criteria, bug fix priority, etc.)?、
• Are there any special conventions I should follow? For example, are there restrictions on code auto-generated by Copilot, or best practices for submitting bug fixes to avoid conflicts?

3. Release Schedule & Versioning Rules

• What are the rules and typical timelines for version releases?
• Any other transparency-related information that would help me contribute more effectively?

Thank you very much for your time and guidance!

@asturio @andreasrosdal @andreasrosdalw

[asturio]

Hi there, you have many questions, Some are already answered in our wiki. But I'll try to reply for everything.

Overview

OpenPDF was created as fork from iText 2.0.7 which was open source and free. All versions of iText later than that were not free anymore (you could use it for free in open source projects, but not for commercial use). So here is the pro for OpenPDF: it's license is still open source and free software. PDFBox is another library for the same purpose as OpenPDF, but with another API. It is also free and open source. The other ones are commercial libraries, which one can use paying a license. Commercial products give you some kind of support, because people are paid for that, while using a free library you must care for the support asking the community or find some instructions on the internets by yourself.

GitHub is the main place to search, but there are some information people created out there, which I'm not aware of. GitHub is full of features which can be used to improve the development or the software.

Contributing

Just make your PRs (yours are really great), write some tests. I don't have much time but will try to review them. Other people are also helping reviewing PRs and merging them. If a PR is good but I didn't see it, some one will merge it, or contact me. There is no special branching strategy, PR is PR.

If contributing code, it would be nice to use the configuration for eclipse or intellij supplied in config. There is also a checkstyle.xml which can be used to check the code style.

If all checks are green, the PR is OK for review. If it is not, I expect the author to make changes so the PR become green.

Tests are always welcome, raising the poor coverage we have. Examples too.

If you want to be credited, please write yourself to the Contributors.md.

If you are inspired you may also introduce new workflows, so building and releasing the project is easier.

I'm not a fan of using AI for generating big code blocks. Some king of assistance is OK, for writing code fast. But AI may also create methods which are copy written. So there must always be an human in the loop. Or avoid that kind of AI-support.

Releases

I used to make a new release when there were lots of commits to publish. But got many problems because there where too many changes, or the release process didn't work anymore. Other people release much often, maybe multiple times in a week. I'll try to release often enough, after a couple PRs.

Note

Although I'm the maintainer of this project, I don't develop actively. I try to raise the code quality and review the PRs with that in mind. The main development here is community driven.

Other contributors may also write answers to your questions.