Migrate registration lists pdf from latex to Weasyprint

[abhinavohri]

Created a self-contained HTML template and refactored the Python logic, creating a dedicated helper function to prepare the participant data into simple headers and rows. The main controller now just renders this template and uses WeasyPrint to convert the resulting HTML into the final PDF.

This PR is the first step towards solving issue https://github.com/indico/indico/issues/6957. I would open another PR for the actual issue, once this PR is merged.

I also had some queries:

1. What is the ideal place to store the template and css?
2. What would be the correct way to test this?
3. Are there any plans to migrate the rest of the legacy report generation code to Weasyprint? If yes, I would love to do that.

[ThiefMaster]

What is the ideal place to store the template and css?

indico/modules/events/registration/templates/pdf/participants_table.html

Note that there's also a different layout ("book") that would most likely needs its own template (or at least css). CSS should ideally be in a separate file, we did the same for the PDF timetable. It can be in the same directory, just with .css instead of .html.

What would be the correct way to test this?

Manually... Create some events / registration forms with different fields (all of them) and check if it looks decent. Also compare the old/new looks to make sure nothing gets worse. Some things to consider:

• too many fields and/or too long field titles so it no longer fits on one page - iirc in the old one it failed, so the new one should also fail unless there is a better solution for it
• freetext fields with very long content to ensure it gets wrapped and does not completely blow up the layout. ideally test with "normal" content (lorem ipsum text for example) but also with nonsense (aaaaaaaaaaa.... etc.) that cannot be cleanly wrapped.
• multiple registrations so they do not fit on a single page - not sure if the old one repeated the headings and if not, whether we should add it (probably not necessary), but in any case see how it looks like

Are there any plans to migrate the rest of the legacy report generation code to Weasyprint? If yes, I would love to do that.

Yeah, I think getting rid of reportlab altogether would be great! But let's first get this PR finished.

[abhinavohri]

What is the ideal place to store the template and css?

indico/modules/events/registration/templates/pdf/participants_table.html

Note that there's also a different layout ("book") that would most likely needs its own template (or at least css). CSS should ideally be in a separate file, we did the same for the PDF timetable. It can be in the same directory, just with .css instead of .html.

I have shifted the template to the path you suggested and have also created a dedicated css file.

What would be the correct way to test this?

Manually... Create some events / registration forms with different fields (all of them) and check if it looks decent. Also compare the old/new looks to make sure nothing gets worse. Some things to consider:

• too many fields and/or too long field titles so it no longer fits on one page - iirc in the old one it failed, so the new one should also fail unless there is a better solution for it
• freetext fields with very long content to ensure it gets wrapped and does not completely blow up the layout. ideally test with "normal" content (lorem ipsum text for example) but also with nonsense (aaaaaaaaaaa.... etc.) that cannot be cleanly wrapped.
• multiple registrations so they do not fit on a single page - not sure if the old one repeated the headings and if not, whether we should add it (probably not necessary), but in any case see how it looks like

My apologies for not being clear, I actually meant automated testing. I already did some of these checks manually before opening the PR.

Are there any plans to migrate the rest of the legacy report generation code to Weasyprint? If yes, I would love to do that.

Yeah, I think getting rid of reportlab altogether would be great! But let's first get this PR finished.

Sounds good!!

[ThiefMaster]

I actually meant automated testing.

Not really possible here since while you could test that there are no errors, or even assert a snapshot of the generated HTML (not very useful IMHO), it would not help with ensuring that the PDF looks decent

[ThiefMaster]

It looks like #7077 contains all but the last commit from this branch. I recommend cherry-picking it into the other branch and then this PR can probably be closed in favor of the other one...

[abhinavohri]

It looks like #7077 contains all but the last commit from this branch. I recommend cherry-picking it into the other branch and then this PR can probably be closed in favor of the other one...

The changes in the last commit are there in the other PR just in a different commit. I might have duplicated that change by mistake here.