I am thinking about a plugin to supply an alternative template system for badges etc. ( based on pdfjinja).
At the places where a badge/ticket is printed, the
signals.event.designer.print_badge_template signal is send.
Currently there are no in-core uses of this signal, but I have some questions about the intended use:
The signal receives just the template and the reform (no data) and does not return anything. So was this intended just for
logging/accounting of printed badges?
Wouldn’t it be more useful if there was a signal that can return an alternative rendered version of a badge/ticket, so that the templating can be tuned via plugins?
We currently use it to disallow printing badges using a certain template in a custom plugin.
I don’t see any reason against passing the list of registration IDs to the signal.
Allowing a return value with PDF content would not be hard either, but unless the custom code takes the used badge template into account it feels a bit like a somewhat hack to me…
That sounds like something that would be interesting to have in Indico more than a plugin, depending on what you’re planning to do. Are you thinking of a particular use case?
Well, one idea is to supply an externally created template (InDesign + Adobe Acrobat Pro) and render it with the registration data. The template to use would be handled by the plugin, this way a fallback to the classical indico template
would be easy.
The creation of the ‘external’ templates require quite a bit of tooling and knowledge, so I don’t think it a good idea to have it in core.
I’ll think about the best way to do the template selection…