A more conceise version of the Powerline test, designed to show
the dreaded 'faint vertical lines' phenomenon from LCD antialiasing
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Usage is a bit ... hard, because we need to do this before the release
is published.
Download the complete artifact zip archive from the release-drafting
run.
Unpack it into the repository (will end up in patched-fonts/)
Pack all archives with archive-fonts.sh
Then use this tool to extract the names and sizes of the artifacts.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We struggle with the pack-committing of patched fonts to the repository
on release. This makes our repo grow extremely big. It would be better
to just use release artifacts for the releases and not commit any
patched font back.
There were different approaches discussed, but the problem remains that
I personally have no rights to implement anything of that - neither can
I force push to the default branch, nor can I create new repos in the
organization.
[how]
To make it still possible to add new fonts without a repo size
explosion we do not release NEW fonts back to the repository as commits,
but old fonts are handled as before.
NEW fonts:
* have a new property set in the fonts.yaml 'database'
* are released as release artifact via release workflow (but not
committed back)
* get a readme in the patched_fonts/ directory that points to the
release artifact page
The solution is not ideal, but for sure better than not adding any fonts
anymore or having the repo grow in size faster and faster.
At some point in time I would like to phase out all in-repo releases,
also for OLD fonts.
This scheme has been (manually) used / introduced for Intel One.
With this change the .gitignore file is automatically adapted to any new
font that is added with the repoRelease flag set to false (which should
be the default for any added font from now on).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[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>
