badge-maker: replace anafanafo with pretext for measurement

[LitoMore]

Resolves #9728

I've generated compare.html and performance.html files in the project root that introduce its comparison and performance. I will remove these temporary files before merging.

There is a new workflow step for downloading fonts because pretext needs it for calculating, but the Verdana font license does not allow us to commit the font file to the repository. Here are some of my thoughts:

• We need to find a better workflow to download font files since it's not only needed from the CI, but developers need them as well.
• Or changing the Verdana font to an open-source-friendly font? So that we can commit the file directly to the repository. But it will be a huge visual change for users.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​chenglou/​pretext@​0.0.3
	@​actions/​github@​9.0.0
	@​actions/​core@​3.0.0
	@​napi-rs/​canvas@​0.1.97

View full report

[github-actions]

	Messages
📖	✨ Thanks for your contribution to Shields, @LitoMore!
📖	Thanks for contributing to our documentation. We ❤️ our documentarians!

Generated by 🚫 dangerJS against 2d6b981

[jNullj]

I took a first look, and since this touches a core component, we want to be really intentional with how we proceed.

How I see this trade-off

• pretext: Offers great benefits in accuracy (subpixel rendering/edge cases) and is actively maintained, which is a big plus for long-term health, allow in-browser usage & multiple fonts.
• anafanafo: While it hasn't been updated in a while, its simplicity makes it incredibly efficient.

Performance Considerations
My main concern is the performance overhead. In the context of Shields.io, where we handle millions of requests, even a 100–300ms increase is significant, this part of the code will run almost every time.
Since we often wait on external APIs, and some will take long to reply (but that's not in our control), we try to keep our internal processing as lean as possible to avoid hitting response timeouts.
I’m going to dig into Grafana to see our current latency baselines so we can make a data-driven decision here. But my guts tell me that 300~500ms is not probable to go without moving some badges outside our timeouts.

Potential Paths Forward

• Optimize anafanafo: Since it was built by one of our maintainers and is quite small, could we port some of pretext benefits like browser side support & multiple fonts?
• Performance Tuning: Are there ways to mitigate the pretext overhead, or perhaps a third alternative that bridges the gap between speed and features?

I’m less of an expert on the design/UI side so I may have some bias here into the performance side, that's why i would like to see if you think that this change is a good trade-off.

@PyvesB @LitoMore — would love to get your perspectives on the performance vs. accuracy balance here.

[jNullj]

regarding grafana data, we are a bit quicker then i was thinking
https://metrics.shields.io/d/aESRBSjmz/services?orgId=1&from=2026-04-08T17:23:30.409Z&to=2026-04-11T13:19:34.344Z&timezone=utc&var-env=shields-production&actionView=breakdown&var-groupby=$__all&viewPanel=panel-11
sadly this data is not sort-able by service, we may be able to add this as a future change for metrics.

let me know your thoughts.

[PyvesB]

Thanks for the detailed analysis, LitoMore!

The performance hit is unfortunate, but it's pretty negligeable considering the total rendering time of a badge, and could be offset by the other benefits.

I'm a little more worried about maintainability. anafanafo is simple, it never requires updating, and if ever we needed to change stuff we'd arguably be in control, assuming we can reach out to Paul to get the ball rolling quickly. On the other hand, pretext and transitive canvas are more complex. In particular, the native canvas stuff underneath the hood feels like the kind of stuff that could be brittle and block upgrades on our side; I'm seeing many issues along the lines of "segfault, regression, crash on Node xx" in the repo. Perhaps only a benign part of that transitive dependency would be leveraged, I don't know how much we'd be exposed.