One PR per change is best.
Ideally it shouldn't even be HTML generation, but XML with a possible transformation afterwards.
The hardcoded links are likely an issue too - separate PR for that one too if possible.
XML generation looks nice on paper, but the problem is that HTML reports are all linked in a hierarchy.
How easy would it be to extend that hierarchy with an XML schema?
The default transformation should be a transformation that would output the current HTML. Step 1 is to separate the data and the output representation. Then both can be improved independantly.
Showing my ignorance: just learned about XLink ... could that be a possible way to XMLisation?
Anyway, going back to the original topic: refactoring of HTML generation can help, IMHO.
How many PRs do you need: one for a specific refactoring, like writeHtmlHead(), writeHtmlBodyHeaders(), join(), etc?
In the end, I even used an override of toString() in ArchiveType enum which in turn affects Main, core and profiles
Keep the PRs small - focusing on one specific area - you can do multiple refactoring in one PR, but they have to be related. When in doubt it is better to split.
My time is limited, so it is easier for me to merge small PRs with a clear and precise JIRA than larger ones which has multiple unrelated changes.