Update action status badge layout

[bytedream]

The current action status badge are looking different from most other badges renders, which is especially noticeable when using them along with other badges. This PR updates the action badges to match the commonly used badges from other providers.

Old (first 3 are gitea badges, the others are from shields.io):

New:

A tricky part is the calculation of the text width, which is required to set the correct width of the label and message part of the badge. The used font is DejaVu Sans, which isn't monospaced, so different badge texts with the same letter count may be rendered with different lengths in the browser.
To get the correct width, dynamic text width calculations must be done server side. All widths of printable characters from 0x00 to 0xFF are "prerendered". The comments in badge_glyph_width.go describe how the width generation was done. I've added a build script that downloads the font, renders the width of each supported character (at font size 11) and generates a table/map with all widths that is then used to get the approximate text width. This results in a rather big codegen file, as the font has ~5500 supported characters.

[wxiaoguang]

Sorry but I do not think it is a proper approach to embed font widths at the moment. You can see that font-family="Geneva,DejaVu Sans,sans-serif" there are more fonts and the render might use none of them if there is a fallback.

[wxiaoguang]

Some more thoughts:

1. Do we really need that many "font widths"? I guess no. That badge only renders ASCII letters and numbers.
2. Do we really need to handle various fonts? I guess no, we could use some "preferred" fonts and use the guessed width. The "preferred" fonts could be carefully chosen to make sure they have similar character widths.

[bytedream]

Sorry but I do not think it is a proper approach to embed font widths at the moment. You can see that font-family="Geneva,DejaVu Sans,sans-serif" there are more fonts and the render might use none of them if there is a fallback.

I looked at the implementation of shields.io and they are using the same approach to get the font width.
GitHub uses 'DejaVu Sans',Verdana,Geneva,sans-serif for their action shields, shields.io Verdana,Geneva,DejaVu Sans,sans-serif. From what I've read they have mostly the same widths with some small differences for some letters. Verdana is the biggest, Geneva the smallest and DejaVu Sans is in between them. The "spec" also recommends using DejaVu Sans.

1. Do we really need that many "font widths"? I guess no. That badge only renders ASCII letters and numbers.

The label of the badge is the workflow name, non-ascii letters could be used there. But true, I also think this isn't the case so often. For this cases a fallback width could be used.

2. Do we really need to handle various fonts? I guess no, we could use some "preferred" fonts and use the guessed width. The "preferred" fonts could be carefully chosen to make sure they have similar character widths.

GitHub and shields.io are both using DejaVu Sans, Verdana and Geneva as fonts, so using them as preferred fonts is relatively safe.

[wxiaoguang]

1. Do we really need that many "font widths"? I guess no. That badge only renders ASCII letters and numbers.

The label of the badge is the workflow name, non-ascii letters could be used there. But true, I also think this isn't the case so often. For this cases a fallback width could be used.

If non-ascii letters would be used, what would happen if there are CJK characters?

[bytedream]

The last commit added a fallback. So any glyph that isn't in the generated width map (like CJK) will use the width of m. m is also used as fallback for shields.io which is why I chose this char to be the fallback

[bytedream]

Do we really need that many "font widths"? I guess no.

With the fallback implemented, reducing the amount of font/glyph width is a good idea.
Storing only ascii characters is pretty valid. This would result in a map with 95 width entries. I'd extend the supported char range to unicode.MaxLatin1 (\u00FF) which supports some more specials characters and thus may handle more edgecases. This would will result in 188 map entries. I don't know if including said extended char range is really necessary in practice, so I'm also fine if you say ascii only is enough.

[wxiaoguang]

Hmm yes, if we could only store the widths for characters before 0x80 or 0xFF, it would be better.

[bytedream]

Done with 0xFF (+ renamed font width to glyph width)

dismiss

[wxiaoguang]

The rendered images seem strange. Am I wrong?

Hmm ..... I guess I know the problem now .... the id conflicts

[wxiaoguang]

Tested with different texts and fonts, seem good.

The last questions:

1. Do we need to keep build/generate-glyph-width.go? IMO the font widths are fixed and won't change.
2. (After 1): Maybe we could use once.Value to lazy-init the rune map to avoid consuming CPU&memory for other sub-commands.

[bytedream]

Hmm ..... I guess I know the problem now .... the id conflicts

Oh you also solved this. I did a fix that only changes the devtests (subrequests for each svg).

1. Do we need to keep build/generate-glyph-width.go? IMO the font widths are fixed and won't change.

My intention with the build script was to have a transparent source how the widths are calculated. But yea I also don't think that they'll ever change

[wxiaoguang]

I made a change in ffc8c1d to use "sync.OnceValue".

Maybe we could either:

• update the "generate" program
• add some comments like these widths are generated by `ttfFont.GlyphAdvance(nil, glyphIndex, 11, font.HintingNone)` with https://github.com/dejavu-fonts/dejavu-fonts/releases/download/version_2_37/dejavu-sans-ttf-2.37.zip and then no need to include the "generate" program?

[bytedream]

• add some comments like these widths are generated by `ttfFont.GlyphAdvance(nil, glyphIndex, 11, font.HintingNone)` with https://github.com/dejavu-fonts/dejavu-fonts/releases/download/version_2_37/dejavu-sans-ttf-2.37.zip and then no need to include the "generate" program?

Comments sounds good