Autogenerate original-source glyph font #931
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[why] With commits ef8c12e Document and update cheat sheet data bcef53d Update cheat sheet the README has not been updated, and i_cod.sh is still listed as 'not existing'. Signed-off-by: Fini Jastrow <[email protected]>
Signed-off-by: Fini Jastrow <[email protected]>
|
This needs:
|
|
Ah, ...fixing up |
Finii
force-pushed
the
feature/autogenerate-original
branch
from
0de28e0 to
c970fc7
Compare
[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 <[email protected]>
Signed-off-by: Fini Jastrow <[email protected]>
Finii
force-pushed
the
feature/autogenerate-original
branch
from
c970fc7 to
972fdac
Compare
[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 <[email protected]>
Finii
force-pushed
the
feature/autogenerate-original
branch
from
ca599d7 to
86a372f
Compare
|
Ah yes! 🎉 How beautifully is that working? First it looks at all And as you can see, quite a number were not optimized :-> And then the font is spit out...: And both of these changes are automatically added to the PR. 😀 |
|
Here is what came out ... The font got smaller, all SVGs got bigger? Yes, they are not optimized with
And the actual font became even smaller. Without the optimization, created from the (un-simplified source svgs) the size was roughly 120k. And even the
Edit: Use better image for font |
[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 <[email protected]>
|
This should not have happened:
I just added some documentation, and a 'new' This is fixed by the following (force pushed) change: |
Finii
force-pushed
the
feature/autogenerate-original
branch
from
9c9fa3f to
fd0849f
Compare
|
Obviously the fix did not ... fix it. :-( |
Finii
force-pushed
the
feature/autogenerate-original
branch
from
6628e4e to
5fb3d01
Compare
|
That did work in my fork, why not here? :-( |
|
Found it:
It detects a difference, because we force 'both' timestamps to the previous font's creation time, but THAT font has different creation and modification time set. Creation time is the time when creation started, and mod time, when it finished, and when that hits a seconds boundary we have to different times. That is the reason why it does only happen sometimes. Fixing... |
[why] Despite commit cc2b547 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 <[email protected]>
[why] This is so big, it will shrink 2 times with a optimize-original-source.sh run, and we want to have 'optimal' glyphs after the next (automated) CI run [how] Use optimize-original-source.sh once and just commit the php.svg. Signed-off-by: Fini Jastrow <[email protected]>
Finii
force-pushed
the
feature/autogenerate-original
branch
4 times, most recently
from
9b71905 to
d6f6e5d
Compare
[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 <[email protected]>
Finii
force-pushed
the
feature/autogenerate-original
branch
from
d6f6e5d to
b255bc1
Compare
LNKLEO
pushed a commit
to LNKLEO/Nerd
that referenced
this pull request
Nov 24, 2023
…original Autogenerate original-source glyph font
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Add original-source.otf generator script
[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.shin 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 stablecodepoints 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.
Requirements / Checklist
What does this Pull Request (PR) do?
Possibility to generate
src/glyphs/original-source.otfandbin/scripts/lib/i_seti.shfrom a file that contains a list of codepoints and all the glyph files insrc/svgs/.How should this be manually tested?
Make backup of
original-source.otfandi_seti.sh.Run it (from the script dir). Check changed made to both aforementioned files.
Any background context you can provide?
First motivation:
#833 (comment)
Came up again and again, for example #929 (comment)
when we want to update complete Seti...
What are the relevant tickets (if any)?
Screenshots (if appropriate or helpful)