[why]
Does not calculate the number of files:
find: ‘/home/runner/work/nerd-fonts/nerd-fonts/../../patched-fonts/*’: No such file or directory
[how]
Use $sd instead of $PWD
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
All error stream outputs of `font-patcher` are suppressed, because they
are very noisy and usually are ignored.
But when the patching fails for some reason we do not know why.
Especially if that happens during CI runs.
[how]
Instead of dropping the stderr we store it in an envvar; and output it
to stdout if patching failed.
`printf` is needed because `echo` is lousy with multiple lines.
Redirection magic:
https://stackoverflow.com/questions/962255/how-to-store-standard-error-in-a-variablehttps://stackoverflow.com/a/56577569
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Windows Compatible fonts have the same Family name, regardless if they
are "Nerd Font" or "Nerd Font Mono".
This creates problems for appliations that sort and select fonts by
Family name.
[how]
Just like "Nerd Font" is abbreviated as "NF" in the Windows Family names
(to keep it short because of the 31 character length limit), the
"Nerd Font Mono" are now called "NFM" instead of just (also) "NF".
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Another bugfix release to fix the regression introduced with 2.2.0
that is fixed by #764. Also note #900.
Some other smaller PRs also pulled.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some symbol fonts might come with glyphs that have multiple codepoints.
When we want to patch them with `'Exact': true` (i.e. at their 'original'
codepoints) we want to patch them into the codepoint that has been used
in the selection process. That means between SymStart and SymEnd.
But this is not the case. We patch them in into their 'main' codepoint,
which can be outside the expected range of points.
This came up when patching with FontAwesome V6. It has for example these
glyphs:
Glyph 'music' has a main codepoint 0x1F3B5, but it is present in the
font also on codepoint 0xF001.
Glyph 'heard' has a main codepoint 0x1F9E1, but it is present in the
font also on codepoints 0x2665, 0x2764, 0xF004, 0xF08A, 0x1F499, ...
When doing a `'Exact': true` patch (i.e. exactEncoding = true) the
glyphs is patched into the target font at its (the glyph's) main
codepoint, regardless of our patch-codepoint-range.
[how]
We examine all codepoints that a glyph occupies in the symbol font. From
all these codepoints we take the nearest to the last glyph be patched
in. Nearest means from the possible codepoints the lowest that come
after the previous used codepoint.
For example the 'heard':
Last patched in codepoint was 0xF003.
Main codepoint: 0x1F9E1
Alternate codepoints: 0x2665, 0x2764, 0xF004, 0xF08A, 0x1F499, ...
-=> 0xF004
Later in the patching process we might encounter the same glyph again,
but this time the previous codepoint was 0xF089, so we need to take
0xF08A.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When users just download the script (and not the source glyphs) the
script fails with an obscure error message.
[how]
Check if the glyphdir exists at all. If not give a hint to download the
glyphs.
Check if the individual glyph font exists and is readable. Bail out if
not.
[note]
Cherry picked, was part of #741
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When one wants to use a custom symbol font and specifies it with an
absolute path, the glyphdir is still prepended.
That means that the argument to `--custom` is always used as relative
path (to `--glyphdir`), even when it starts with `/`. That is somehow
unexpected or at least inconvenient.
Example:
fontforge font-patcher --custom ~/Downloads/fa6.otf Inconsolata-Regular.otf
fa6.otf is searched for in ./src/glyphs/home/username/Downloads
[how]
Use Python function that handles joining path fragments. If a component is
an absolute path, all previous components are thrown away.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
I'm not sure why, but maybe the CI's Python is another version where the
syntax is not supported.
This has been introduced with commit
4a61afc83 font-patcher: Do not overwrite glyphs that are needed for basic glyphs
[how]
Use less sophisticated syntax.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some glyphs that are tall and thin, are too big in the resulting patched
font, i.e. are higher than our 'line'.
At least for --mono fonts. The non-mono fonts do not rescale the
inserted glyphs at all, so there is no definition of 'too tall/wide'.
[how]
We want all glyphs to fit into the box defined by *_dim['height'] and
*_dim['widths'], as it also defines our powerline-glyph scaling and
horizontal and vertical advance widths.
So we need to take that value (instead of EM) for the scaling
calculation. The history of the use of EM here is a bit obscure, more
explanations in the PR.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Sometimes the basic glyphs ([a-zA-Z] etc) are constructed in the font
from other glyphs via references. To keep those basic glyphs intact we
must not touch the referenced glyphs.
[how]
Crate a list of all glyphs referenced by the basic glyphs.
When patching in some new symbol - if that codepoint is in the list do
not overwrite it. Overwriting would break a basic glyph.
The user does not get the glyph that we would have patched in, but that
can not be helped if we want to keep the basic glyphs intact and not
'redesign' the complete font.
Fixes: #400
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the fontforge python bindings are not installed we fail while
importing psMat. The message suggests that fontforge itself is not
installed - which is not the real reason. One can use the libfontforfge
with the python-fontforge without having the GUI program fontforge.
Furthermore we link to outdated installation instructions.
[how]
We already check and report correctly what needs to be done with the
fontforge module import. As both modules are often in the same package
we should probably report the same message. That message holds correct
hints for Debian/Ubuntu. It does not have a link to fontforge, though.
[note]
Also update Debian package name.
Fixes: #725
Reported-by: Aniket Teredesai <a@aniketteredesai.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
For some powerline symbols we add a certain amount of overlap into the
previous or next character to cover up a small gap between the symbols
that otherwise can show up as ugly thin (usually colored) line.
But after we carefully design that glyph with a bit overlap (over-sized
and having negative bearings) we remove all bearings. That breaks of
course the glyph and no actual overlap on the left side happens.
[how]
Just do not remove negative bearings on overlap-enabled glyphs. As they
are rescaled in both directions anyhow all bearings are wanted and must
be kept.
Reported-by: Mihail Ivanchev <@MIvanchev>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The params are half way handled as dict, but if unset it is an empty
string. That makes accessing it needlessly complicated.
[how]
With no functional change the params becomes now a dict, also when it
does not contain any particular information.
At the moment that seems not nessecary, as it can only contain one key:
'overlap'. We could also rename 'params' to 'overlap' and just store the
value.
But we keep the generic params dictionary as it might come in handy some
time in the far future when more parameters are added.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The commit
59c45ba4e Remove negative bearings on 2048-em glyphs
has been introduced to fix some problems with the symbols only font, at
least from the commit message.
That font is intended to be used in font-fallback situations, and so we
do not know the advance width of the current font anyhow. It does not
make sense to enforce an advance width with these.
[how]
Create the NerdFontsSymbolsOnly as if 59c45ba4e would be still in
effect, i.e. with variable advance width.
[note]
There have been a lot discussions about the reverted commit, some can be
found here:
* #900
* #764
* #731
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Theoretically we can produce 3 types on fonts:
* A: Strictly monospaced font
* B: Allow bigger symbols, but advance width still monospaced
* C: Allow bigger symbols, advance width will vary
All have their uses.
Historically Nerd Fonts produced A and B.
Then we had kind of a breaking change with 2.2.0 that it produces
now A and C.
The commit
b9b7a5080 Revert "Remove negative bearings on 2048-em glyphs"
restores the old (pre 2.2.0) behavior. But the type C fonts can be
useful, so maybe we can have them as option?
[how]
Add commandline option to be able to create all fonts types:
* A: specify -s or --mono or --use-single-width-glyphs
* B: specify nothing
* C: specify --variable-width-glyphs
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
This reverts commit 59c45ba4ef.
[why]
The commit breaks the non-mono Nerd Fonts for a lot of people.
The issue was not very good documented and investigation can not be
seen.
For the TITLE it should have affected only the 2048-em Symbols only
font, but in fact all patched fonts were changed. Maybe that was
intended, maybe not.
[how]
This will make the advance width again equal for all glyphs.
This enables the use of the non-mono variant in more terminals.
For wider symbols a space is now (again) needed after the symbol.
That is expected by a lot applications.
[note]
See Pull Request 764 for more details.
See next commits for alternative solution for original problem.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The CI runs takes hours... 4 to 5?
[how]
With the recent changes we can half the number of patcher runs, because
we can create a normal and a Windows Compatible font version from one
patching process.
The export is done twice still (just the actual patching is avoided),
so the reduction will be less. But still!
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The options in the translations are rather old for some.
[how]
Reorder stuff, and add new items with english description, because,
well, I can not translate. But better to have it in english there then
to miss it.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The normal and the Windows Compatible fonts differ just in the naming.
The patching is all the same.
For the CI we patch the original font for each output font. That is not
needed if we just want to create two differently named exports.
Skipping the patching where it is possible would save some time. Not
half the time, but the patching process itself is not too quick either.
[how]
Backup the original font names (as we need them again to deduce the new
Windows Compatible names).
Then do the patching once and the export twice, if parameter is given.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The patch() function also does the font generation. This makes it
impossible to generate two fonts from one patch run.
(Will be needed in next commit).
The name setup could be done later.
[note]
This is no functional change, just reordering.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
After generating the patched font only a shortened name is displayed.
[how]
Obviously the two output lines were swapped...
If the fullname is None, and then output the fullname? :-}
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The casks-artifact is empty.
[how]
Supply the correct path for the upload.
For this the generator script prints the output pathname(s),
which in turn are used in the CI.
Also drop unneeded '/' from path end.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With commit
821ac6817 Create symbols only font directly from sfd template
we have a default width for source fonts without a width (i.e. empty
fonts).
Unfortunately the detection for 'empty font' is wrong.
[how]
Reorder the commands such that we have a meaningful calculation.
Maybe this has been broken by too many (manual) rebases.
Fixes: #895
Reported-by: redactedscribe
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The AUR list has recently been updated with
889a74148 doc: Reorder AUR packages
f81b39fab List AUR packages for Jetbrains & Victor Mono
but the translation have not been updated.
[how]
Unfortunately ... translating is a bit over my head, so I just add the
English text everywhere and someone native might report it :-/
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We create the release packages one by one in a lot of jobs. Whenever a
job is ready it adds its package to the release.
This means that the release starts with one archive and grows over the
next 5 (!) hours. (Noto takes about 5h to patch.)
But people will be notified and find the new *unfinished* release, which
can raise questions or problems.
[how]
Mark the release 'draft'.
Unfortunately I can not find (quickly, now) a way to un-draft the
release so this has to be done manually. Maybe it is better anyhow, so
that one can edit the release message etc.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
I am sure I tested it and it worked. Well, it does not, it throws an
error message
Unrecognized named-value: 'secrets'
[how]
Secrets can not be used in the `if`, see
https://github.com/actions/runner/issues/520
But they can be used in `env`, ... so do it there.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
On forks for example they might have a docker repo associated or not.
The release process is run in any case and will fail in that cases.
[how]
Check that at least the secret is known.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The docker image should be rebuilt whenever a file that will end up in
the container has been changed. So this needs to be in line with the
.dockerignore file.
[how]
Add missing (new) `font-patcher` sub-scripts.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
`grep` and `awk` do not know json. This might break if some format
changes or whatever.
[note]
The font matrix setup is also with `jq`.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Usually release tags and versions start with a "v", and we also had that
up to 2.1.0:
$ git tag -l
2.2.0-RC
FontPatcher
v0.1.0
v0.1.1
v0.1.2
v0.2.0
v0.2.1
v0.3.0
v0.3.1
v0.4.0
v0.4.1
v0.5.0
v0.5.1
v0.6.0
v0.6.1
v0.7.0
v0.8.0
v1.0.0
v1.1.0
v1.2.0
v2.0.0
v2.1.0
[how]
In the files we keep the non-"v" version numbers, but the tags on github
shall be prepended with a "v" like "v2.2.0-RC".
The variable RELEASE_TAG_VERSION is renamed to RELEASE_VERSION to make
clear that this is not the name of the tag.
Where we reference a tag, "v$RELEASE_VERSION" is used.
[note]
One of the environment variable is not needed, we can use the output directly.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
