Automatically build fonts in github-actions CI with FontCustom

[lucjaulmes]

Fixes #109. Fork-Awesome uses FontCustom to build their fonts. This PR allows doing the same with academicons.

• On every commit, the following files are built:

  academicons-preview.html
  css/academicons.css
  css/academicons.min.css
  fonts/academicons.eot
  fonts/academicons.svg
  fonts/academicons.ttf
  fonts/academicons.woff
  fonts/academicons.woff2
  

  That is, the same organization of files as the current repo, with an additional preview file.

  All these files are uploaded in a single academicons.zip archive downloadable from the “artifacts” drop-down menu of the github actions.
  

• Visual inspection of fonts is possible by extracting the archive and opening academicons-preview.html

• PRs only need to add an svg file to the svg/ directory with the desired basename. Fonts are automatically built, see for example the test PR lucjaulmes/academicons#1 which triggered the build: https://github.com/lucjaulmes/academicons/pull/1/checks?check_run_id=2527748877

  Adding erc.svg correctly adds a .ai-erc icon. Opening the preview file from the artifacts confirms my ERC icon from #105 looks terrible :)

  

I’m not sure whether keeping the css and fonts in the source code remains useful after this PR ?

[lucjaulmes]

I’ll look into getting the right encoding. Are the codepoints per icon defined somewhere ?

---

Not sure what the best way for jsdelivr though, I didn’t realize it just mirrored files from a github repo directly.

This script now builds all the files that need to be deployed (+ 1 preview file). Maybe a different branch could contain the sources, and pushing to master could become equivalent to publishing (with this workflow doing that) ?

Otherwise there’ll be double commits to the master branch: 1 updating sources + 1 auto-generated to update fonts and css. That would be pretty annoying, your remote refs would be invalid every time you push, the workflow should take care not to trigger on its own commits to master, etc etc.

[lucjaulmes]

Updated the codepoints. It’s not the most user-friendly system to modify the (hidden) json manifest manually, so I made a config/codepoints.json that defines the codepoints and that automatically generates the manifest correctly.

I think (under your control @nfrerebeau) that that handles generating the fonts correctly. Easiest way to test that would be to generate that table again, but I’m unsure how to do that. We can further tweak css generation with templates.

Before looking at how this could be deployed, I think the next question should be what tests to include ?

• It would make sense on PRs to check that added codepoints are in the correct range.
• Not sure how to test “visually” that the font generation went well ?

[lucjaulmes]

Here’s the jsdelivr-compatible way to do this. As jsdelivr always sends out the master branch even it is not the github default branch, I have setup 2 branches (on my repo):

• master, which contains the built fonts, css, docs, etc.
• sources, now the main branch, which contains the sources and svg files

On every push and PR to sources, fonts, css, and docs are re-built. The glyphs are svg files from the svg/ directory, whose codepoints are listed on config/codepoints.json. The CI checks codepoints and glyph names. There is some visual testing, done be generating a screenshot of a glyphs table.

• On pushes, the built elements are deployed, i.e. pushed to master. Currently visual testing does not cause the CI to fail. A maximum number of changed pixels could be decided. (There is already some fuzzing etc. done by ImageMagick to compare properly, each glyph takes up to 2025 pixels.)
• On PRs, the diff is automatically posted to the thread as with this example or this other one. This is done using a gist to store images. That way PRs can see if the modified changes are as planned, whether the changes break building fonts or not, etc.

The organization of files is the same than in master currently, so no changes for the docs and jsdelivr files. You can also test the github pages.

---

To import this structure, the sources branch should be added to the repo and made the main branch, with some env keys modified in the workflow file:

• personal access token that has repo/gist/workflow rights for the TOKEN keys
• a gist URL on which the token has rights for the GIST_URL key

[nfrerebeau]

I will look at all this in the next few days.

[lucjaulmes]

This last commit comes from the fact I added a final (I think) feature:

• automatic deployment is not done when there are too many pixels changed at once. This allows to prevent deploying breaking changes.
• If there is ever a need for a push where lots of pixels change and it is normal (lots of icons updated, different browser used to render the screenshot, something like that), there is now a way to manually trigger the workflow with a 'force' flag to force ignore the pixel diff count

[lucjaulmes]

Sorry, I fail to see how the generated fonts with audo_width=false are different from the current fonts.

I tested the differences between both fonts without using the generated css or svg files. I fetched the fonts from https://cdn.jsdelivr.net/gh/jpswalsh/academicons/fonts/ under the name academicons-legacy and the fonts from https://cdn.jsdelivr.net/gh/lucjaulmes/academicons/fonts/ under the name academicons-fontforge, and displayed them side-by-side by using the codepoints in HTML, and not the CSS classes (so definitely using fonts and not CSS images). I’ve also padded with underscores to visualize the baseline.

Both fonts look identical to me:

Some glyphs are wider than ohers, e.g. zenodo, but it’s the same in both fonts. You can see the ACM and all square fonts correctly dip below the baseline.

Here’s the file used to generate this image (gzipped to allow upload): diff.html.gz

[nfrerebeau]

My bad, I manually inspected the fonts with FontForge and it seems to be related to the import in FontForge.

[lucjaulmes]

So this works right? Is there anything else you’d like included/changed?