[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>
With v3.0.0 we removed some icons and some codepoints have been reused
for a different (expanding) set. We want to show the old (removed) icons
correctly and the new ones also, so we need the old and the new font for
the webpage and reference it accordingly.
For the a new style .nfold (read: nd-olf) is introduced and utilized.
See pairing commit in the gh-pages branch:
Date: Thu May 4 06:01:33 2023 +0200
Update cheat sheet WITH removed icons
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When working on the font-patcher the developer needs to test the changes
on a number of fonts. This is usually a manual call of `font-patcher`
and afterwards a 'diff' of the newly created font with the 'old' font in
the patched-fonts/ directory with fontforge (which has a font-compare
option).
If you run gotta-patch-em-all normally the newly generated font will
replace the existing font and git will ALWAYS show it as different. The
reason is that at least the timestamp in the generated font has changed.
Far more easy would be if the new gotta-patch-em-all run could keep the
previous timestamps, in that way one can immediately see that the old
and new fonts are bitwise equal (via git).
Furthermore if you expect a change and want to show the differences of
old and new font in fontforge you need both fonts in the filesystem.
But a normal gotta-patch-em-all run replaces the font. A different
destination folder would help here.
[how]
Introduce two new (independent) options to
a) keep the timestamp equal to previous patch run
b) generate the fonts in a different directory
While b) is straight forward, a) is a bit more complicated, esp because
filenames can change and so on. So the script examines just one (1)
random font in the specific font directory and uses its timestamp. In
most cases this is correct enough if the developer uses gotta-patch-em-all
consequently.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
