[why]
When the CI triggers a rebuild of the original-source and the font
contents is unchanged we do not want to commit the new version back to
the repo.
But because fontforge puts the creation date into the font file it will
always differ on every run, and we would needlessly create commits.
[how]
We could use the SOURCE_DATE_EPOCH approach and set the dates to the
relevant change (commit) times like so:
cd src/svgs
export SOURCE_DATE_EPOCH="$(git log -1 --format=%ct -- *.svg)"
and only afterwards call the generator script / fontforge.
But that would need a complete git repo checkout and not just a shallow
one (which is faster and thus is used by github action/checkout).
Instead we can instruct fontforge to not put any timestamp into the
file. The timestamps are anyhow a fontforge proprietary extension.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we add a custom glyph (or want to update Seti) the process is
rather laborious and we are needed to change the font and the
accompanying `i_seti.sh` in sync.
[how]
We use a data file to map icon (svg) filenames to codepoints and
readable names.
That file is parsed and the font and info file is created (overwritten
in the repo); and could then be easily committed. This can be a CI
workflow.
Having a dedicated mapping file (`icons.tsv`) enables us to have stable
codepoints for the same symbol over time. Changes in codepoint
allocation can be checked in git.
Having the font autogenerated help guarantee that the icons are all
likely scaled. We rescale them all to the same size and mid-position.
That is not needed for font-patcher, because it rescales and shifts
again based on to-be-patched font metrics. But it certainly is better
for a view into the original-source font.
Sizes and position are still roughly equivalent to the hand positioned
glyphs.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
