[why]
After changing something in the patch process it is unclear if all the
prepatched fonts will look ok later. It would be nice to produce one
font from each input font (and not the complete set of each of the faces
of that font) to have some hopefully representative example how symbols will
blend into the font.
[how]
Add a script with explicit list of representative fonts.
Evaluate the config.cfg and execute one patcher run.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The variation lists are very long and noone will ever look at them.
Instead we have a font-info.md file, for what reasons?
[how]
Replace the function the font-info.md file had with README.md.
Drop all the variation lists.
Automatically call the readme creation in the gotta-patch-em instead of
just hinting that one should call that (standardize-and-complete-readmes.sh).
[why]
The heavy angle brackets (276E and 276F) are used for a lot of prompts,
but we do not yet patch them in and a lot of fonts do not bring them
themselves.
[how]
One time rip the glyphs out from Hack and patch them in always, but
careful (do not replace existing glyph).
We take the whole set 276C - 2771.
[note]
Usually we should never again need to run the generate-extraglyphs
script, we rip them out now and they look good. Whatever Hack does with
new versions we can follow but that is optional.
Related: #1110
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
It's a pain to have the addition of contributors automated via
all-contributors bot, but then it does not end up on the webpage.
[how]
I'm not sure it will automatically be triggered (pretty sure it will
not), but at least one can clickstart manually the workflow.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The webfonts are needed for the cheat sheet. When we update the sheet
code we probably need also new fonts.
The fonts might contain fixes also if there is no need for a new sheet,
so they have to be updated on every release.
[how]
Add mini-script that generates the woff's from the latest 'ttf'.
This makes it easier to check the woffs manually.
Let the workflow create the woffs, and push them to the gh-pages.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Now we can create the casks of some specific release ('latest' in this
case) at will, based purely on the artifact files and on nothing in the
repo. We do not even need to fetch the repo.
This is still some kind of WIP, because we do not have the secrets and
not even a proper homebrew fork in our organization.
THIS WILL NOT WORK out of the box. Refer to PR #1008 to get instruction
on additional steps needed to make this run.
[note]
Remove cask generation from normal release workflow.
Later on the release workflow has to trigger the cask workflow.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
It does not really make sense to couple the casks, which checksums are
based on the zip files in the archive directory to files currently
existing in the repo. They could be different from the archived ones.
[how]
Use solely the archives. For this they must be unpacked temporarely so
that the fonts can be examined for family names.
We do not try to automatically determine the release tag of the archive
files. They could in principle we different for each. Instead it usually
has to be specified on the command line.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
