[why]
Parsing the command line arguments has nothing to do with the actual
patching.
If we want to patch more than one font we need to separate the partching
from unrelated work.
[how]
Just do the argument processing in main() and hand the information over
to the patcher object.
[note]
No functional change. Lines copied over (almost *) 1:1.
(*) Exceptions:
self.sym_font_args is now only a local variable, as it is only used in
this one function.
The startup message is shown on ... startup (i.e. main()).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Only one tables is removed, even if we want to remove more.
With 0a480bb the indentation of the code has changed, and now the loop
is (apart from printing) empty. See also #934
[how]
Re-indent the lines to restore functionality as originally forseen with
commit 557fc00.
Reported-by: Rádler Ákos <akos.radler@gmail.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Sometimes the patched-in symbols are slightly too big, which shows up in
Nerd Font Mono fonts where the destination size is specified exactly.
That issues a warning like:
Warning: Scaled glyph U+F077 wider than one monospace width
[how]
For the scaleGlyph groups we need to combine the bounding boxes of
several symbol glyphs to determine the 'combined' scale we need.
Unfortunately when the concrete glyph is finally copied over its size
can change minimally.
So we need to measure the glyphs in the scaleGroup _after_ they have
been copied to the to-be-patched font. This is a bit complicated,
because we need to know some glyph slot we can use for that.
[note]
See also commit
e805b879 font-patcher: Resolve rounding error when rescaling
Fixes: #917
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>
[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]
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 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]
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]
We show only the Release version of the patcher script. Often it is
unclear which particular script people are using.
[how]
Also show the script version. This is a bit frickle, as it needs
developers to change the number manually (as with all other scripts in
the project that have a script version), but so be it.
This could be replaced by the 'current' git hash. But that has the
drawback that one needs to search for the commit to see how old the
script is.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
When pulling the subfamily out of the sfnt_names SubFamily property,
we will get a subfamily with possible spaces, e.g. 'Bold Italic'.
When constructing the final unique font name (PostScript name), we
need to remove those spaces, to make the font name valid, otherwise
the font will fail validation with a warning when installing.
Fixes#413
[why]
People might want to use the font-patcher with just the one script file.
The error message does not help them to understand the problem.
[how]
Require the modules only if the user wants to use it (i.e. --makegroups).
Give the expected path in the error message.
We could also download the missing files instead, similar to #741
But that PR did not get any feedback yet, so I do not know if this is
something we want.
Anyhow, the fetching of missing parts should then be unified for both
usecases (i.e. Fontname* and src/glyphs).
And then, there is font-patcher.zip (which needs to be adapted), maybe
that is the way to go.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The option `--parser` instructs `font-patcher` to come up with the font
naming by utilizing the FontnameParser object.
This sounds logical from a programmers perspective, but the option name
is not descriptive for end users of `font-patcher`
[how]
As usual naming is hard. A short but maybe more descriptive name for the
option can be `--makegroups`; as it describes what the option means for
the end user: functioning font grouping.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
This reverts commit df42c917128701e9be199fb12d77a3fecad52cb1.
[why]
Having all the code in one big file is probably a maintenance nightmare.
We should develop other solutions to make the usage for end-users easy.
Future commits might do that.
[why]
The fontname for Windows can be quite unusable, for example
`CaskaydiaCoveNerdFontCompleteM-`
for several different fonts, as this is the maximum allowed length of 31
characters that is enforced.
The style/weight is completely lost.
[how]
Split the name into base and style (at a dash `-`) and just shrink the
base name. Result for example:
`CaskaydiaCoveN-ExtraLightItalic`
Use equal approach for the PostScriptName (although it is less likely
that length limit is ever met).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
A lot people expect the font-patcher to be a stand alone script. They
even think that the source glyphs (symbols) to be added to be somehow
magically there and one PR makes sure that they are fetched if missing.
The same problem arises when we have a script distributed over multiple
files. For maintenance reasons and code quality this is what one wants.
But that might hinder easy use of the font-patcher.
[how]
Put all the code in the main script.
That has an additional drawback: For the nameparser_test* scripts to
work we need stand alone files for that classes. Now the code is
duplicated and will get out of sync.
I have no solution for that, and it all boils down what Nerd Font wants
to do.
One solution would be to have font-patcher properly set up / divided in
many .py files, and to create one monolithic font-patcher from all the
sources on demand (via github actions or manually when someone pushes
changes to any of the constituends). That approach is taken by a lot of
C++ 'header only libraries' that originally consist of a lot files but
create one big 'all in one' file automatically from all the small files.
For now I guess we can live with the duplication, but we need to think
about a solution, as this will bite us sooner or later.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some CJK fonts seem to have no Fullname.
[how]
But they have a Postscript name. Use that for parsing the names.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
DO NOT MERGE
[why]
A lot of the fonts have incorrect naming after patching. A completely
different approach can help to come up with a consistent naming scheme.
[how]
See bin/scripts/name-parser/README.md
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The symbol only fonts Symbols-1000-em Nerd Font Complete.ttf
and 2048-em in `NerdFontsSymbolsOnly/` are generated from
some 'almost' empty source fonts, that are assumable in turn generated
from the sfd font descriptions in `src/glyphs/`?
The process is not documented and we have issues in the generated font
(for example the glyph for capital `E` is defined (and empty) #581#765).
[how]
Use the existing font definitions from `src/glyphs/*.sfd` directly as
source font. That needs a change in font-patcher because the empty
fonts have no glyphs that can be used to orient the scaling upon. In
that case scale on the source font definitions EM.
Then we need patch-em-all to also patch *.sfd fonts.
And finally we need patch-em-all to take a font specific command line
switch for font-patcher (compare 9e2bc9a26 of #723) to instruct it to
create a ttf rather than a sfd font file.
In the sfd file we additionally set the Panose type.
And the UnderlinePosition is adjusted to match the current patched font.
[note]
Also fix wrong glob pattern in patch-em-all `*.[o,t]tf`. The comma is
for sure some leftover from a '{}' shell pattern, that is not used
anymore. (This comment is probably outdated, due to rebasing.)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the source font does not have a HEAD table (i.e. is not a ttf/otf
font but for example a sfd) we can not copy the PPEM and flag values.
The patcher crashes.
[how]
Just put the code into a try block. We could check the signature
instead, but this would add more and complex code.
Reported-by: Jakub Jirutka <jakub@jirutka.cz>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some fonts set specific lower resolutions and handle the small rendering
very nicely. But fontforge does not copy that information when it opens
a font; rather some default values are always written. That can destroy
the small font rendering.
The responsible settings are the 'ppem_to_int' flag and the
'lowestRecPPEM' setting, both in the HEAD table.
[how]
After successfully patching and generating the new font we copy that
settings over from the source font.
Instead of using fontTools (and thereby requiring all users to pull that
dependency) we handle the raw font file changes ourselves.
Fixes: 612
Reported-by: nojus297
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the patched font does not have a fullname (which can never happen)
the postprocess is called with a wrong filename.
[note]
Also output the file name of the patched font, for easier access by the user.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The 'monospace' width is determined by examining all the 'normal' glyphs
and taking the widest one.
'Normal' means 0x00-0x17f: the Latin Extended-A range.
Unfortunately Noto has the '1/2', '1/4', '3/4' that are all wider then the
normal (i.e. letter) glyphs.
[how]
Exclude a small sub-range from the 'find the widest glyph' that contain
no glyphs one would call 'letter'.
Fixes: #610
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Before Font Logos 1.0.0 there was no stable-codepoint guarantee, and the
later revisions (0.18) reassigned the codepoints. That makes updating
for us very hard, because we would have to resort the icons or follow
the codepoint changes.
With 1.0.0 this changed. That new major release introduced not only a
codepoint guarantee, but it also shifted the codepoints from the F100
region to the F300 region, where we put them anyhow (in most cases).
That is one subset less with 'dynamic base codepoint'.
The reassignment of codepoints in Font Logos kept the codepoints stable
for the icons we already have in release 2.1.0. But at the moment the
2.2.0 Release Candidate (which updated Font Logos with commit 557b8da)
have added glyphs, which are on different points as compared with the
Font Logos 1.0.0 release.
What I want to say, we need to get this straight, before our 2.2.0 RC
turns into a Release 2.2.0.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
In ligature-enabled environments the accent grave will be rendered as
zero width, thus overlapping with the next character (in some source
fonts).
The problem is, that the glyph type in the sourcefonts is set to 'auto',
and fontforge exports these as 'mark' - the patched font will be broken.
[how]
There is no way we can get that glyph to be 'auto', but we can force it
to be an ordinary 'baseglyph' instead, and that will be respected on
export.
Maybe I should raise an Issue at fontforge... maybe later.
Fixes: #858Fixes: #582
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When a True Type Collection file (.ttc) is used as font source this is
not handled and just the first file in the collection is processed and
saved. But the user is not informed.
When the target file format is True Type Collection, no file at all is
written.
These are two distinct cases, because you can in fact open a .ttc and
save the first font (patched) when specifying a different extension via
`-ext`. Or open a normal font and specify `ttc` as extension i.e. target
file format.
[how]
Check if a collection is to be opened. As we currently have no code to
loop through all fonts (and just the first font is processed) a message
is issued and we exit. Typically a user would want all the fonts and
would have to 'explode' the collection into multiple single font files
beforehand.
Prevent the target to be ttc, as that is not handled in fontforge at
all. To save TTCs a different API function is to be used. Unfortunately
fontforge does not care and just does nothing.
font.generateTtc() would have to be used with ttc extensions...
Anyhow. As the looping through all fonts is missing anyhow, and I feel
the usefulness is very slim, we just prevent silent failures with this
commit.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The symbol glyphs are rescaled (when --mono is specified) so that they
have a predefined width after insertion in the source font (to be
patched font, called 'target font' below).
Sometimes the width of the glyph after insertion is off a bit, like
0.2% or so. This seems strange, as we calculate the target width
exactly.
[how]
As expected this are rounding errors. In the old code we take the
original width of the glyph when it is in the symbol font and
rescale it when it is in the target font. The width of the glyph
should be the same in the source and the target font, right?
It fact it is not, because the coordinate systems of the two fonts can
(and usually are) different. fontforge's magic scales the glyph
into the new coordinate system on insertion, such that it is approx
the same as before. But when the coordinate system is integer based
we get some small rounding errors just from copy and paste.
To solve this, we
- first copy the glyph from the source into the target font
- then determine the glyphs width
- then rescale the glyph to the target width
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The ScaleGlyph just gives a lot of anonymous numbers.
[how]
Write down which glyphs are rescaled and group them to related
groups.
They are not changed to 'new' ScaleGlyph method.
[note]
Checked the current Devicons, and they are completely different to ours.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
While patching for --mono with Font Awesome we get glyphs that are
too wide, for example '_520' (0xF22B). In the symbol font original
it is about 1918 wide. According to ScaleGlyph FONTA_SCALE_LIST
it shall be scaled as 0xF17A - which is only 1664 wide.
[how]
Fill the ScaleGlyph of Font Awesome with groups of glyphs that shall be
kept same-sized after scaling.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
While patching for --mono with Font Awesome we get glyphs that are
too wide, for example '_520' (0xF22B). In the symbol font original
it is about 1918 wide. According to ScaleGlyph FONTA_SCALE_LIST
it shall be scaled as 0xF17A - which is only 1664 wide.
This results in too wide symbols in the patched font.
[how]
The ScaleGlyph dict works like this:
- 'ScaleGlyph' Lead glyph, which scaling factor is taken
- 'GlyphsToScale': List of (glyph code) or (list of two glyph codes
that form a closed range)) that shall be scaled
Note that this allows only one group for the whole symbol font, and
that the scaling factor is defined by a specific character, which
needs to be manually selected (on each symbol font update).
The redesign drops 'ScaleGlyph' and changes the glyph list to:
- 'GlyphsToScale': List of ((lists of glyph codes) or (ranges of glyph codes)) that shall be scaled
Each item in 'GlyphsToScale' (a range or an explicit list) forms a group of glyphs that shall be
as rescaled all with the same and maximum possible (for the included glyphs) factor.
The old data structure is automatically rewritten to new entries.
[note]
This commit just changes the algorithm. As the new ScaleGlyph is not
used for any font, there is no change in the patched fonts.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Sometimes fonts patched with --mono are not recognized as monospaced
fonts.
One reason can be that the inserted glyphs are too wide. This will show
in the end in the font's advanceWidthMax property which is not congruent
to the normal font width.
[how]
After all the scaling and jiggling we double check if the new glyph
already in the to-be-patched is not wider than our design goal for the
width. Normally one would expect that this always holds.
An exemption could be if we insert ligatures, that are two spaces wide.
But at the moment we can not anyhow (because there is no way to add
information to the ligature tables right now).
If a glyph is wider a warning is issued.
No warning is issued if the glyph shall have some overlap. That overlap
is taken into account of this check.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
