[why]
The messages from parallel font-patcher runs can be very confusing, so
it has been disabled some time ago (without a comment in that commit?!).
However, if someone wants to repatch multiple fonts on a local machine
it might be beneficial to run more than one process to have work on all
cores.
[how]
Add option to select multiple processes in parallel.
Limit the amout to 8, which might be a good value for typical end-user
machines with 4 cores and 8 threads.
Patching Cascadia Code (12 fonts) took these times on my machine:
1 job: 21m 55s
4 jobs: 6m 24s
8 jobs: 5m 14s (this runs 8 and then the remaining 4)
16 jobs: 4m 48s (this runs 12 in parallel)
Adding a proper `-j` that takes a numeric argument is rather too much
work for my taste, so we stick with 8 for now.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Running gotta-patch-em-all creates a lot of output that is most likely
not wanted.
[how]
Add --verbose option to gotta-patch-em-all.
Hide debugging information unless it is wanted by specifying this option.
Also change font-patcher to produce less verbose output and respect
--quite in more places.
This includes a change that we try to tweak the font flags only if
source and destination font are ttf or otf, because we can not read the
other raw font files anyhow.
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>
[why]
All the fonts will have different timestamps, and within each font the
creation and modification date might also differ. That is quite
confusing and makes automated testing very complicated.
[how]
Use one date-time for ALL fonts and for creation and modification date
in the font file.
But do not change the date-time if we already set that somewhere before :-}
Also remove the 'special' properitary fontforge timestamp tables FFTM from
the patched fonts. This is only possible since FontForge 20th Anniversary
Edition.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Oh boy do I hate the boilerplate code needed with optargs, but without
it every parameter becomes a burden.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we want to patch all fonts by calling the script without any
options it fails.
[how]
Give the correct regex to find all directories.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The powerline glyphs (and only them) undergo a xy scaling, where both
dimensions are maximized into the 'cell'.
Normally cells are taller than wide, and everyting looks fine. But we
have square cells (e.g. 2048 * 2048) with the SymbolsOnly font, and
there might be some self patched font that has similar very-wide (in
comparison to hight) cells.
In these fonts some powerline glyphs look rather ugly. For example the
'half cicles' become very wide and un-round, the triangulars become very
pointy.
[how]
Add a new patch-set attribute 'xy-ratio'. When that is set the vertical
(y) scaling is done as usual but the horizontal (x) scaling is limited
such that the width/height ratio is maximally the attributes value.
For example setting it to 0.75 the height is maximized (as usual) but
the width is maximized to be less then 0.75 times the hight (or as wide
as the cell is, whatever is smaller).
It will work with both, 'xy' and 'pa' scaling, at least theoretically.
It has been only checked where it is used now, i.e. with 'xy'.
A possible overlap is not taken into account.
[note]
The values are taken for this reasons:
- 0.59: This is the original half-circle ratio, higher values make them
loose the (half) circular appearance
- 0.5: The half circle lines are more shallow
- 0.7: The triangulars should not be too pointy (random number)
Fixes: #658
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The old doc was a bit unclear and I always had to read the code when
changes / additions to ScaleRules were needed.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If a ScaleGlyph is defined that ScaleRules will just be that one rule,
even if in parallel the user specified some ScaleGroups.
So it is either ScaleGroups or ScaleGlyph but not both.
If someone specifies both there is no warning or check.
[how]
Just allow both. Rewrite the ScaleGlyph to an additional (last) entry in
the ScaleGroups.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Assume a set of monospaced icons in a ScaleGroup that scatter all about
(like Braille).
With --variable-width-glyphs we forcefully remove all left side
bearings and set the width to the width of the combined bounding box.
This is not correct, usually with monospaced ScaleGroup icons we should
preserve the original advance width.
[how]
Do not remove left side bearings on ScaleGroup glyphs in
--variable-width-glyphs mode.
Set the width of any glyph in --variable-width-glyphs to the 'monoscaped
advance width' if that particular glyph has one (from a ScaleGroup).
The effect is that all positive bearings will be 'added' and put on the
right hand side of the glyph, while the glyph itself, or rather the
combined bounding box, is still strictly left aligned.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We have still a confusing naming. There are two different things that
are called 'ScaleGlyph':
- The setting in the patch set
- The reference glyph for old style scaling
[how]
Rename the patch set member to ScaleRules, as this is what in contained.
Also rename variable names accordingly.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We now have the 'old' and the 'new' GlyphsToScale things, which behave
differently, but they have the same name. That can lead to confusion. At
least I am always confused when I look at the code after a month or so.
[how]
Call the 'new' method 'ScaleGroup' instead.
The 'new' feature (which includes creating a combined bounding box and
synchronized shifting) 'ScaleGroup'.
The 'old' feature (which scales all glyphs as if they would have the
size of one reference glyph; shifting is individual) still consists of
'ScaleGlyph' and 'GlyphsToScale'.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The code looks so compliacted while in fact it is not (so much).
Rounding sometimes and sometimes not is hard to reaon about. The
un-rounded values should in principle be better, but there is some
rounding hidden in the font that we can not really simulate, so simulate
what we can.
[how]
Always scale (even if factor is one) and round to integer the BB.
[note]
Also use 'is not None' ideom.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The advance width in the bounding box data is sometimes wrong (usually
to small). Turned out only AFTER the glyph scaling.
[how]
The wrong scaling factor has been used *duh*.
Advance width is of course X axis.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When only one symbol glyph is examined we conclude that it comes from a
monospaced glyph set.
This might be correct or not, but when we can not positively say it is
monospaced we should not handle it as monospaced.
[how]
We require at least TWO glyphs with the same width (and no glyph
with a different width) until we set the 'advance' bounding box
property. Which says that this particular glyph subset is monospaced.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The scale-glyph-data is used only for 'pa' scales, but thereafter used
for all shifts, even if the scaling has been 'x' or 'y' or both.
As we do not use GlyphToScale for anything but 'pa' scaled glyphs that
should not make any difference right now. But it will be an obscure bug
if we ever want to handle the Powerline symbols with a scale group.
I do not know if that will ever happen, but I tried it whilst
experimenting spending hours on finding this bug.
[how]
Access the GlyphToScale data and use it even for 'x' and 'y' scaling, if
we have it for the particular glyph.
[note]
Also change 'invalid' flag from False to None.
Also use 'is None' or 'is not None' for comparisons with None.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The previous commit is somewhat incomplete in some cases and plain wrong
in others (with proportional fonts). Examples:
The Heard 0x2665 gets a positive right side bearing, which is
unexpected. The commits prevents negative right side bearings but not
positive ones.
The glyphs with overlap (which are the Powerline ones) like 0xE0B0 and
0xE0B2 end up in wrong sizes.
This can especially be seen with the Symbols-Only (non-Mono) font,
because that is (secretly) a 'Nerd Font Propo' (--variable-width-glyphs)
font.
[how]
This is kind of a design choice: As with the other patched font variants
we ignore existing borders (positive bearings) around the glyph. The
previous commit tried to keep them, which seems to be impossible and
is inconsistent). Also negative bearings would be ignored (but there are
none).
The only place where bearings come into play is now when we have
overlap. All non-overlap glyphs render without any bearing.
If we have overlap we need to
a) reduce the width by the overlap
b) introduce a negative bearing on the appropriate side
First we remove any left side bearing by transforming the glyph to the
side, such that the bearing becomes zero.
For left-side overlap we additionally transform the glyph by the overlap
amount to the left (as usual). This creates the neg. left bearing.
For right-side overlap we keep the left bearing to be zero.
After correcting the left-side bearing (by transforming) we set the
corrected width. That is the width subtracted by the overlap.
In the left-aligned case this makes the right-side bearing zero.
In the right-aligned case this results in a negative right-side bearing.
Note how fontforge handles size and bearing changes:
Fontforge handles the width change like this:
- Keep existing left_side_bearing
- Set width
- Calculate and set new right_side_bearing
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Very slender symbols added to a proportional patch end up being at least
one mono-width wide, which mixes proportional and monospaces metrics.
[how]
When we create a proportional font we should
a) not try to align them in a (non existing) monocpace cell
b) insert the symbols with their own (advance) width
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When creating a non-Mono font the vertical alignment does not observe a
possible ScaleGlyph group. Icons that should be far up (like the
degree-icon, which is ScaleGlyph-grouped together with a full height
symbol) end up centered vertically.
[how]
When the glyph is not scaled we just do not use the ScaleGlyph.
But that data is also needed for just shifting the glyph.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The weather icons have a glyph for degress, a small cirle for up.
That gets completely destroyed on scaling to fit.
[how]
Just add a scaleGlyph set.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The weather icons have some symbols that have a different bounding box
but should nevertheless be scaled alike, because for example one is the
outer line of a thermometer and one is the matching stem.
[how]
Just add a scaleGlyph set.
Fixes: #915
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
This is obviously a complete mess.
Firstly it seems the author (me) used the array elements as ranges,
which is of course not possible. And them the end has a typo.
Sigh.
[how]
Not consecutive codes must all be given one by one (unfortunately).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Man do I hate these indented tables in code. Specifically because they
break conciseness of commits if one needs to re-indent unrelated
entries.
[how]
Do it in this separate commit that does not change functionality.
[note]
Smuggled in unrelated code shift by some lines.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If we define glyph groups in ScaleGlyph we want them to be scaled alike,
but they are aligned individually, which makes previously matching pairs
looking odd.
[how]
If we have a combined bounding box stored in a ScaleGlyph range, that
box is used to align all symbols in the range identically.
If the symbol font is proportinal only the v alignment is synced.
If the symbol font is monospaced v and h alignemnts are synced.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We might want to handle monospaced symbol fonts differently then
proportional symbol fonts. Proportional symbol fonts usually have
no uniform symbol scaling, while monospaced symbol fonts usually have a
well designed placement of the symbols within the cell.
[how]
Add new member to the dimensions dict.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If we use a ScaleGlyph range (i.e. use the same scaling on a range of
glyphs; the scaling is determined by the combined bounding box of all
that glyphs), we probably want to shift the glyphs identically as well
to preserve relative positions not only sizes of the glyphs within the
range.
But the data is stored nowhere.
[how]
Store the 'virtual' bounding box along with the scale.
[note]
With combined (virtual) bounding box we mean the bounding box that a
glyph would have where all the individual glyphs would be stamped over
each other without shifting/scaling beforehand.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the combinded bounding box of a range of glyphs is to be determined
and the range contains an empty glyph the resulting bounding box will
always include the [0, 0] point (that is the point-ish bounding box of
the empty glyph).
[how]
If more than one codepoint is to be considered empty glyphs are ignored.
But if only one (concrete) codepoint is queried do return the empty
(i.e. [0, 0, 0, 0]) bounding box.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
First the new ScaleGlyph has been introduced with commit
e5768e925 font-patcher: Redesign ScaleGlyph parameter
and afterwards it has been enhanced to avoid rounding errors
with commit
983226a70 font-patcher: Fix scaleGlyph related rounding error
The later commit uses a function that explicitely says it will destroy
the glyph at a specific location, AFTER we already patched in one glyph
(namely F000).
It does not look too bad, bad that glyph is not correctly rescaled or
translated. Only that glyph is affected because only Font Awesome uses
the new ScaleGlyph capabilities, and only the first glyph of a set is
affected.
[how]
The ScaleGlyph calculations need to be done before the final glyph is
patched in. It is shifted some lines up. Usually that glyph is not
existing in the to-be-patched font, so we create a dummy first.
Also need to correct distinction between 'unicode in symbol font' and
'unicode in to-be-patched font', as this would bite us in cases where we
move the symbol's codepoint.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The filename is determined by the font (family) name. The font name
might include characters that are forbidden to use in filenames.
[how]
Filter output filesnames and prevent any character that is likely
forbidden under Windows.
Also prevent control characters.
Translate Windows path separators to posix.
Fixes: #632
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The Iosevka font has a lot of different families. A lot users install
just all "Iosevka Nerd Font" families, and this can break in a lot
different ways.
I will try to collect Issues possibly caused by this in PR #1019.
[how]
Just turn the feature on in font-patcher (via patch-em-all's config).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The generated svg's canvas is far too big.
I remember shadowy that one had to resize the canvas manually...
[how]
Switch back from Actions to Verbs, because only there we can resize the
canvas automatically.
Note commit
3444b5755 generate-font-image-previews: Fix and Refactor [skip-ci]
Verbs seem to be still possible. There is currently no Action for the
same thing.
So we revert 3444b5755 to Ryan's original code (in principle) with the
same verbs.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We do not have a preview for the Symbols Only font.
The Symbols Only font appears two times (with 1000 and with 2048 EM).
[how]
Remove one of the occurences of NerdFontSymbolsOnly in the fonts.json.
The font matrix (for CI) still works, and we get only one entry in the
fonts list on the gh-pages.
Change the entry details accordingly.
Create special svg template that includes lots of symbols.
Change the destination filename to be imagePreviewFont instead of the
patchedName + "Nerd Font". The website (gh-pages) expects the former
file names.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
There are two svg tempates, one with and one without Inkscape metadata.
[how]
The metadataless files is fine and opens ok in Inkscape.
There are no real differences between the two templates.
Drop the Inkscape one.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
From the name we used the non-Mono Symbols font for the webfonts. But in
the Cheat Sheet we want to display the icons all in nice boxes, all with
the same size. That is not the case for the non-Mono font, here all
glyphs are unscaled and thus do not match each other.
[how]
Use the Nerd Font Mono variant for the webfont, as the icons here all
have the same size and are surrounded by their bounding box, making
working with them a lot easier.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The webfonts are needed for the cheat sheet. When we update the sheet
code we probably need also new fonts.
The fonts might contain fixes also if there is no need for a new sheet,
so they have to be updated on every release.
[how]
Add mini-script that generates the woff's from the latest 'ttf'.
This makes it easier to check the woffs manually.
Let the workflow create the woffs, and push them to the gh-pages.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
This must have been somehow forgotten. I did try if the autogenerated
file works, and it did.
See commit
bcef53da Update cheat sheet
September 2022? I have no recollection at all :-(
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Although we automatically create a new up to date i_seti.sh on all
original-source.otf updates, we do not push it to the repo together with
the font.
[note]
Also include up-to-date i_seti.sh because the workflow will not trigger
until we have new icons and the font does actually change.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Normally the release zip files have a flat directory structure, i.e. all
files are in the base directory and there are no subdirs. The existing
subdirectory structure is removed on zip creation via `archive-fonts.sh`.
If the patch results have two fonts with identical name these flat
archives can not be generated. The `archive-fonts.sh` reports:
Could not create archive with the path junked (-j option) - likely
same font names for different paths, zip status: $zipStatus
Retrying with full path
But now the problem is only delayed. When the font file has the name
name the Family and SubFamily are most likely also the same for both
font files. If we install both the user (and the system) can not really
distinguish the font files anymore.
This turned up with [1] when doing a `brew style *nerd-font*` that
complains in fact about duplicate fonts to install. At that point we had
the additional problem that the subdir-path had been missing in the cask
files. So I'm not sure if it would work from a Cask standpoint (i.e.
font files are installed in subdirs).
Anyhow, this will fail when the user wants to select the font files,
because normally this is done on a Family-name basis. And identical file
name usually means identical Family-SubFamily.
Note that this ONLY happens with GohuFont, which has these subdirs:
11/complete
14/complete
uni-11/complete
uni-14/complete
The font has embedded bitmaps, but only one size. The "11" ones have
11px bitmap fonts and the "14" ones 14px bitmaps.
The "uni-" variant has much more glyphs.
Otherwise the differences are slim. From the font creation date the
"uni-" ones are newer.
[how]
Each font filename added to a cask is memorized. When the next fontfile
is to be added to the cask it is checked if we already have that
filename installed. Duplicates are then skipped.
If we have a deep archive, the fonts are added to the cask with full
relative path.
In case of Gohu that means the 11/complete variant is added (because all
files are alphabetically sorted before adding). By chance this is the
same variant that has historically been in the Cask, so no change here.
Fixes:
https://github.com/ryanoasis/nerd-fonts/pull/1008#issuecomment-1351170552https://github.com/Homebrew/homebrew-cask-fonts/pull/6758#issuecomment-1350791208
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Now we can create the casks of some specific release ('latest' in this
case) at will, based purely on the artifact files and on nothing in the
repo. We do not even need to fetch the repo.
This is still some kind of WIP, because we do not have the secrets and
not even a proper homebrew fork in our organization.
THIS WILL NOT WORK out of the box. Refer to PR #1008 to get instruction
on additional steps needed to make this run.
[note]
Remove cask generation from normal release workflow.
Later on the release workflow has to trigger the cask workflow.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
It does not really make sense to couple the casks, which checksums are
based on the zip files in the archive directory to files currently
existing in the repo. They could be different from the archived ones.
[how]
Use solely the archives. For this they must be unpacked temporarely so
that the fonts can be examined for family names.
We do not try to automatically determine the release tag of the archive
files. They could in principle we different for each. Instead it usually
has to be specified on the command line.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The json file is transported to jq via pipe AND as file.
That is not needed of course.
[how]
Just use the filename.
[note]
Also some whitespace changes.
Also remove debug output.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
