[why]
When so svg files could be optimized we still try to commit the
'changes'. There are no changes - so nothing is committed (empty commits
are avoided).
But the workflow run still shows the 'commit back to repo' step,
although we know beforehand that it will not commit anything.
[how]
Technically that is no problem and the behavior is unchanged, but we can
just skip the commit step if we know there can not be anything to
commit...
It just looks nicer :-}
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Despite commit
cc2b54770 generate-original-source: Remove FFTM table
we still get unneeded font rebuilds.
The reason is that the font creation time is not only encoded in FFTM but
also in HEAD.
[how]
We could simply diable timestamps also in HEAD, but that would leave us
with a strange font; strange because no one knows when it has been
created.
Instead we take the more laberous route here: Do detect changes and not
rely on the git history:
* Find out current font's creation date
* Create the font anew with that date as creation date
* If the 'real' font content is unchanged we would now have a 100%
identical new font file; we can detect that with `git diff`
* If it is not identical, something apart from the timestamp has
changed and we create the font again, this time with the real current
time as timestamp and commit that file back to the repo
This only works if creation and modification time are always the same on
all font creations; we need to ensure this by always using the
SOURCE_DATE_EPOCH method, even for 'normal' font creation.
This is a bit more involved than what I would have hoped for, but there
seems to be no easy solution.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Often the SVGs are rather detailed and result in a big
original-source.otf, which then again results in bigger than needed
patched fonts.
[how]
Typically people suggest using svgo to make SVGs smaller, but that just
tackles the representation of the icon, i.e. the actual svg file. That
does not help us at all. We do not need small svg files, we need simple
icons with few points and lines. svgo does not have that capability.
Instead Inkscape's 'Simplify' is used. Repeated use can destroy a glyph,
so we need a scale down margin to stop 'over-simplification'.
The values given for the margin at the moment are purely empirical, the
current glyphs survive repeated use of the new simplification script and
still look good.
The resultant original-source.otf file size is approximately similar to
the previously achieved by Ryan's manual work.
[note]
We need a newer Inkscape, thus update to Ubuntu 22.04
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
