[why]
It does probably not make too much sense to add the box drawing glyphs
to proportional fonts. The boxes that are drawn need to be filled with
some text, and if that does not have monospaced property the box will
always look ugly and not fit and change when the font is changed.
[how]
Make the fact if we detect a source font as monospaced or not a property
of the patcher object.
Always determine that property (before we just determined it when the
target font should have monospaced behavior).
Use that new property to enable/disable the box drawing glyphs.
In a way it is now also prepared to add that as command line parameter
should the need for that arise.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Normally the 'cell' size should not change on patching. If the 'cell'
size does not change we do not need to rescale the box glyphs. They
probably worked before, they work the same afterwards.
Another reason to disable this is Cascadia Code. It has box drawing
glyphs that extend for more up then the normal cell. If we rescale that
to fit a probably new cell size we get a 'midline' that is too low
(because the upper stems are longer).
[how]
Leave the code in, but disable 'just scale do not copy' mode.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We have 2 different types of metrics warnings. When one warning has been
issued the other is not displayed (if it would trigger). The reason was
that I thought normally there would be no warnings and if someone would
have to inventigate the sourcefont anyhow.
[how]
But the warnings are quite common, so differentiate a bit more when
generating.
Also improve one warning message to make clear what the warning is
about.
And fix the assignment of advance width to width; which has no
consequence because it is never used (at the moment). But it was
obviously wrong.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The greys seem to be too small.
[how]
Separate the blocks into real block, greys and quads. They all have
different scales in Hack which we use to patch in.
If we do not patch in and just scale existing glyphs these three groups
should always be sufficient.
Note that in Hack the quad block 2597 is too small; we could have scaled
it together with the blocks group, but that would raise issues with well
behaved fonts that we just scale and not patch in.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some few glyphs get a wrong left side bearing in `Nerd Font`:
E0C2: -1230
E0C5: -857
E0C7: -667
E0CA: -1230
These are the powerline glyphs which are right aligned and have overlap
and a target width of 2 cells wide.
[how]
To simplify the code add a new function that decides if a symbol shall
be one or two cells wide.
That function is then used where we had explicit tests already.
Use the function also in the overlap correction code, such that the
overlap is corrected for the right cell occupancy of the concrete glyph.
[note]
I guess that the overlap correction for 'c' alignment for 2 cell wide
glyphs is also broken. But we do not have such glyphs, so we ignore it
for now :-}
This fixes the previous commit 'font-patcher: Fix overlap for align c and r'.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The box drawing glyphs (center aligned) and some Powerline glyphs (that
are right aligned and have a limited xy-ratio) are positioned wrong.
Affected are all box drawing glyphs (e.g. 2548) and some Powerline
glyphs (i.e. E0B2, E0B6, E0C5, E0C7, and E0D4).
[how]
The box drawing glyphs are center aligned and have overlap. The code
does not correct the overlap (left bearing) but uses the default case of
'make the left bearing zero'. The code does just check left aligned
glyphs and not center aligned ones.
Add the correct overlap for center aligned glyphs (i.e. half the
overlap).
The Powerline glyphs are right aligned. Usually that works, because the
glyphs are created with the right size, so that no additional
manipulation is needed.
But if the glyph has a ratio limit the resulting size will be different.
We could in fact fix the size code, somehow, but that is rather
complicated, formula-wise. Instead we just scale these glyphs (which are
the 5 listed above) and shift them to the right position such that the
correct overlap results.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
This is more an academic fix. If we calculate widths from with bounding
boxes we always need to take xmin and xmax into account. Usually xmin is
zero and so it does not make any difference.
But maybe one can see better what is calculated, especially as we use
xmin in other cases.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The unicode 2630 (Trigraph Heaven) is often used in vim powerlines (at
least).
[how]
Draw nice 3 rectangles.
Insert 'pa1', always scaling also in non mono fonts. That needs a new
attribute: '!'.
The scaling is in fact an issue. Using 'pa' is the way of least
resistance.
Without the new attribute the glyph would look different in mono and
nonmono, which is not nice.
Fixes: #589
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If the to-be-patched font already has all box drawing glyphs we could
use them instead of our extra set from Hack.
But we need to scale them in case the 'cell' size has changed.
[how]
All the mechanics have been already added, we just need to enable it now
in the right cases.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the destination font has box drawing glyphs and we change the
'cell' size, we need to rescale the existing glyphs (so that they fill
the new 'cell'.
[how]
Add a new parameter attribute that skips the copying und just works on
the scaling of glyphs that have this.
For a correct message only the default attribute is checked.
[note]
This just add the possibility, it is not yet used.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The whole patching process addresses the glyphs via their unicode
number / codepoint. We ensure the adressability for the to be patched
font, but the symbol fonts can differ.
[how]
Just set the way we want to address the symbol font glyphs.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
All the box drawing glyphs should be scaled and shifted as one (i.e.
equally). For such glyph sets we have the ScaleGroups that handle it
nicely, determining a combined bounding box and calculation scale and
shift from that bounding box instead of the actual glyph's bounding box.
But unfortunately it is hard-wired to do just 'pa' scaling. For the box
drawing glyphs we need 'xy' scaling.
[how]
The preparatory stage calculates the 'pa' factor for ScaleGroups for us.
That is mainly so because the old system worked that way and has no
notion of combinded-bounding-box. The data needed to be stored in one
number, the scale. Later came the correct shifting, which needed the
bounding box. But the scaling still relied on the one scale factor that
is used for x and y.
Instead, if we have a combinded bounding box, we ignore the
precalculated scale factor and calculate a new set of x- and y-scales
based on the requested scaling algorithm. In this way we can get 'xy' or
'pa' or even 'xy2' scaling, or whatever we like, based on the combined
bounding box.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
For some reason we determine the bounding box xmax value of the 'normal'
extended glyphs. For the cell size we use the advance width of those
glyphs - the xmax values is not utilized at all.
But if we would ever use it, it might be good to see that something
unexpected(?) happened.
This commit is not really necessary. Maybe it is good, maybe it just
adds noise. We can always remove it later.
No functional change.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If a font has references in glyphs that we want to add to the essential
set of glyphs, and fontforge is old (i.e. 2020*) the patcher crashes.
[how]
The fontforge function glyph.references returns a three element tuple in
current fontforge (i.e. 20230101). But older versions skip the selection
bit and return only tuples of two.
As we use only the first tuple element we do not care about the 2nd and
possible 3rd element(s) and just thrash them.
Fixes: #1142
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
All glyphs of the codicons set are individually maximised in size.
That leads to the curious condition that 'circle small' looks bigger
than 'cicrle' (because the line width is scaled up more -> looks bold).
Also some other 'subsets' look ugly and can not be used together.
[how]
Add appropriate ScaleGroups.
For the circles we also include one full-size circle as reference. To
get less than maximal scale for the small circles.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The Material Design Icons have for sure pairs of glyphs that people
would like to have scaled identically. Because the sheer number of
glyphs and because they are already very nicely and uniformly scaled
within their design space the MDI at the new codepoints where all scaled
the same with taking the theoretical design space as ScaleGlyph.
But that means all icons get scaled a bit smaller than before, where we
individually scaled each Material Design Icon to fill the cell.
This lead to numerous complaints.
[how]
We take a different approach now, more conventional maybe. Especially in
the light that the older bigger icons will get dropped; and people love
them.
So the uniform scaling is ditched and the individual scaling is used.
Fixes: #1061
Note: https://github.com/greshake/i3status-rust/pull/1728
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the font has no name the patching fails.
When there is no name we fall back to filename parsing, so it should not
fail.
[how]
Check if we have a name. If not do not try to set it.
[note]
Also change type checks to isinstance() calls.
Fixes: #514
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When a ScaleGroup's combinded bounding box is wider than the target font
cell the actual X position of a glyph in the group depends on it's own
bonding box and not of the combinded bounding box. When doing center
or right alignment.
[how]
'Overwide' ScaleGroup glyphs are correctly placed and shifted in
position, but that would mean a negative left side bearing (i.e. glyph
extends to the left into previous 'cell').
We do not want that and it is later corrected for all glyphs. But that
is done on an individual glyph level and it is just left aligned for its
concrete bounding box (i.e. left side bearing is set to zero).
The dilemma here is that you can not really center a (combinded) glyph
within a cell, when
* the cell is smaller than the glyph
* a left bearing is not allowd
So we change the algorithm here that 'center' and 'right' alignment
mean:
* Center the glyph in the target font cell
* But if that would create a left side 'overhang' (bearing) just left
align (move it as far left as possible without creating a negative
bearing)
The only glyphs affected by this change are the very wide weather icons,
and here escpecially the moon phases F096 and following (target
codepoints E38E ..).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The scaling of the clouds is not identical but depends on the actual
glyph bounding box. But the clouds should all have the same scaling to
be 'interchangeable'
[how]
Put all clouds in a ScaleGroup.
Also add missing Celsius degrees glyph to other degree glyphs group.
Fixes: #1107
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The Powerline extra glyph sizing is not really clear.
[how]
Make the triangulars 1 cell wide, as for example Iosevka also does.
Make the Legos 2 cell wide with pa scaling to make them look nicer.
Make the Hexagons 2 cells wide and keep their aspect ratio if possible.
Make small and big Squares also 2 cell wide and keep their aspect ratio
of possible.
For the small and big Squares add a tiny bit of border (negative
overlap), because they have no smooth border line over their open and
closed squares, and that might look strange if some touch and some dont.
Fixes: #1106
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When patching the Symbols Only font we derive the baseline to baseline
distance through abnormal means, so the check fails.
[how]
Set expected baseline to baseline value explicitely for the Symbols Only
font.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We have an automation for adding glyphs to the original set.
If someone throws in the svg file and adds the glyph to the icons.tsv a
new original-source font is generated.
But the added glyphs are not patched in, because that would need a
change at font-patcher (adjust the end codepoint).
This can be forgotten easily.
[how]
The maximum codepoint of our own (original + seti) set is 0xE6FF. At
0xE700 the Devicons start.
The original-source generation script now checks the offset, they may
not be negative and on the positive end we may not leave our set-range.
If that happens the script fails thus the workflow fails.
Also increate the patch range in font-patcher. If there are no icons to
patch in the symbol font the codepoints are just ignored.
[note]
See also PR #1119
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
There is a bit of code that is not needed anymore (or was never needed).
This makes things look more complicated than they are.
[how]
1. It is plain wrong to write that we add one (1) glyph if we do not add
any glyph.
2. One (1) is added to index later anyhow, so we do not need to distort
the counting in the beginning (the code will run with index=1 for
both the first and the second patched in glyph).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With commit
621008773 font-patcher: Use WIN metrics in all conflicting cases
we intended to use the WIN metrics for the baseline to baseline
calculations for fonts that have contradicting (i.e. broken) metrices.
But we use the TYPO metrics instead.
[how]
This is obviously a typo in the code. To prevent such errors and improve
the readability we use Enums now. I believe we silently dropped support
for Python 2 some time back. And if not we drop it today :-}
[note]
Many thanks to Nathaniel Evan for again finding this bug!
Mentioned in: #1116
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With commit
e69a025a8 font-patcher: Fix line gap redistribution
we fixed the wrong adding instead of subtraction of the bottom gap part
from the descenders.
At least this was done for HHEA and TYPO values.
With WIN values the descenders have positive (!) numbers, so the sign
was not changed for the WIN case.
But that is wrong, as we are already in the ymin xmax coordinate system
(and took the negative of the WIN descenders). So of course here also we
need to subtract and not add.
Mentioned in: #1116
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Instead of redistributing the line gap we remove it.
At least when HHEA or TYPO metrics are used.
It's ok with WIN metrics.
[how]
If we have negative numbers for a gap and want to add more to it, where
'add' means 'make it more', we must of course _subtract_ the value.
But baseline-to-baseline code into function so we can check it after all
our gymnastics for correctness. It means the metrics.
[note]
Also correct out-of-sync comment.
Fixes: #1116
Reported-by: Nathaniel Evan <nathanielevan>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The heavy angle brackets (276E and 276F) are used for a lot of prompts,
but we do not yet patch them in and a lot of fonts do not bring them
themselves.
[how]
One time rip the glyphs out from Hack and patch them in always, but
careful (do not replace existing glyph).
We take the whole set 276C - 2771.
[note]
Usually we should never again need to run the generate-extraglyphs
script, we rip them out now and they look good. Whatever Hack does with
new versions we can follow but that is optional.
Related: #1110
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When changes are made to the font-patcher and fonts are patched with
that version we can not see which patcher has been used in the fonts
afterwards.
Would be good to have the usual version-patchversion number in the fonts
in these cases (i.e. `v2.3.3-7` for 7 commits after `2.3.3`).
I did this manually before, but it is always a hassle.
[how]
If the font-patcher is run directly from a git repo and git is installed
we try to get the latest tag version including patch number.
If and only if that is successful and that version is 'newer' than the
version encoded in the font-patcher script the git version is trusted
more.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some fonts have invalid (or unset) Panose flags. When we create a "Nerd
Font Mono" font the Panose proportion is set to 'monospace'. This
make the font selectable in certain applications that need monospaced
fonts.
After #764 the "Nerd Font" variant shall (again) be detected as
monospaced font, but the glyphs have a big right side bearing (hang into
the next 'cell'). So we need to set the Panose bits there also.
[how]
We already have a check if the font is propably monospaced, independent
from Panose. This is used to prevent --mono patching on originally
proportional fonts.
If we find out with that check that the font is (most probably)
monospaced we also set the appropriate bits in Panose; unless Panose has
valid values that contradict that change.
Fixes: #1098
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When --quiet and --no-progressbar is given we get a lot of empty lines
in the output.
[how]
Just output the carriage return when we have output som eunterminated
stuff before.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When a certain 'higher codepoint' glyph is needed for a substitution or
ligature rule of a basic glyph and we replace the 'higher codepoint'
glyph with a symbol that stylistic set or ligature will be broken.
[how]
We can not determine if a certain glyph is the _target_ of a pos-sub
rule (at least I could not find a way). What we do is remove all pos-sub
entries that _start_ at a symbol-patched glyph [1], but that is not the
same.
Instead of walking through all substitution tables we just examine the
'basic glyphs' and also protect all glyphs that they reference through
most of the possub tables.
In fact I encountered only "Substitution" entries and never "Ligature"
entries, but we handle both alike. "Pair", "AltSub", and "MultSub" are
not handled, but could be added if need be.
[1] #711Fixes: #901
Reported-by: Xiangyu Zhu <frefreak.zxy@gmail.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
List comprehension helps with readability. Also add comments that
describe expected data structures of altuni and references. Also bump up
the patcher version number.
[how]
Use list comprehension. Add comments. Change the version number.
[why]
Using `continue` feels inelegant when there's a way to write the if
conditions in add_glyphrefs_to_essential() without necessitating the use
of `continue` while ensuring that the function still works as intended.
[how]
Change the `if` conditions and remove any usage of the `continue`
keyword in add_glyphrefs_to_essential().
[why]
Issue #400 recently reoccurred with the latest build of Input font, and
it turns out the dotless-j part of the small `j` now points to U+0237,
which in turn has an alternate unicode encoding to U+F6BE; overwriting
U+F6BE effectively overwrites U+0237, and in turn, alters the small `j`.
This patch aims to fix that.
[how]
In addition to references, the patcher also checks for alternate unicode
encodings which are returned by the glyph.altuni attribute, adds those
to the essential set of glyphs, and in turn recursively searches for
their references/alternate unicode encodings, making sure to handle
circular references (for example: U+2010 and U+2011 in Input Mono)
[why]
When HHEA and (depending on USE-TYPO-METRIC) TYPO or WIN are not
consistent it is unclear which metric we should trust.
In #1056 the complete font bounding box (i.e. yMin and yMax) has been
compared to the baseline to baseline distances, and in all these cases
the WIN values seem to be best (preserve the glyph bounding box).
font-line report fontname.ttf | grep metrics:
ttfdump -t head fontname.ttf | grep "yM(in|ax)"
[note]
Roboto will still be clipped?! There seem to be ridiculously high glyphs
in there. Did not check which.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The initial font-patcher used the WIN font metrics to determine the cell
height. What has been found was forced into HHEA metrics but without
observing the USE_TYPO_METRICS flag.
That has been changed to use the TYPO metric instead of the WIN metric
when the font wants that. For that the gap value becomes important.
This is the current code. It still has problems to detect the correct
cell height. A more rigorous approach seem to be needed.
[how]
The baseline to baseline distance is what we need as 'cell height', to
fill it completely with the powerline glyphs. This is a little bit
complicated and not really specified, each font rendering application or
engine can handle the font metrics differently. But there are some
common approaches.
So we try to come up with the correct and congruent height, comparing
different metrics and issuing a warning on problematic fonts.
Afterwards we make all metrics equal (even if they were not before),
because our goal is clear now and we impose it onto all platforms.
[note]
Useful resources:
* https://glyphsapp.com/learn/vertical-metrics
* https://github.com/source-foundry/font-lineFixes: #1056
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The -l option tries to improve (especially) the powerline glyphs by
making the baseline to baseline height (cell height) an even number.
But it does so only for 2 of the three possible metrics.
[how]
Assuming the hight is identical for all metrics we just need to add '1'
to all ascender values.
[note]
I'm not sure this does anything. After rounding an odd height might
create a 'sharper' triangle tip, not an even height?
Do not understand the real reason for the -l option.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Although Monofur is monospaced it has one glyph (hyphen) that is
slightly wider than all others. This results in a Monospaced font that
is slightly too wide.
[how]
Ignore the hyphen width.
[note]
Additionally improve (commented out) debug code (shows now hex
codepoint).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If a `Nerd Font Mono` font is to be created we need to make sure the
original font is indeed monospaced. If it is not and we enforce the same
adavnce width on all glyphs they will look very ugly. Fonts need to be
designed to be monospaced.
We spot check only some characteristic glyphs for that.
Hermit Bold has a problem. Although it looks more or less monospaced it
has some glyphs wider than all the others, for example the small letter
`m`.
Creating a `Nerd Font Mono` (a font where all glyphs have the same
width) will either: Add too much space to the right of all the other
(smaller) glyphs, or will have the wider glyphs cut off on the right.
[how]
Add small letter 'm' to the spot check list. Now the patcher will by
default refuse to --mono patch that font.
Also add output of first char that fails the monospace check. This makes
debugging easier.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If a font is problematic to patch as monospaced font, that is detected
but the reporting is maybe not strong enough and gets overlooked.
[how]
Pull font property reporting into dedicated functions.
Use that function additionally in other warning.
[note]
The monospace check uses all glyphs to determine the advance width, but
the actual advance width later ignores some glyphs (that are problematic
in some fonts and are thus ignored, although that glyphs will 'break'
after patching).
This might or might not be useful, I just leave it as it was before.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With commit
99c260831 font-patcher: Fix more 'Nerd Font Mono' too wide
the glyphs 'ij' and 'IJ' are exempted from the advance width
calculation, because some fonts (i.e. Overpass Mono) defines them as two
cell wide glyphs (Hello? 'Mono'?)
For some obscure reason it was 'IJ' and 'J circumflex' that were
exempt, not 'ij'.
[how]
Exempt correct code.
Fixes: #703
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With commit
f240e073f font-patcher: Fix windows Mono family names with --makegroups
the script version did not change, which makes it impossible to say if a
user uses a bugfixed patcher or not.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Without --makegroups the font family is "Name NFM", but with it enabled
we get "Name NF Mono".
[how]
Mimic the old short-naming also for the groups.
This feels a bit strange, why do we need to specify the names three
times for `inject_suffix()`, slightly different. At some point this
should probably be unified.
def inject_suffix(self, fullname, fontname, family):
"""Add a custom additonal string that shows up in the resulting names"""
In principle Family + Subfamily -> Fullname -> Fontname
Somehow we rename not according to the default rules.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Scaling the glyphs individually breaks a lot of glyph pairs or groups,
for example F0718-F071E.
[how]
Use one ScaleGlyph for the complete set. The set itself is already very
well scaled, i.e. all glyphs are maximized in a given design space and
that they look good next to pairing glyphs.
There is no need to use ScaleRules which is quite costly for such a big
range of glyphs (they all are copied twice in the process).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
ScaleGlyph always did scaling only (no translation) based on one
reference glyph.
ScaleGroups does scaling and translation but can not work with one
reference glyph but constructs always a combined bounding box.
Missing is a way to scale AND translate, but with only one reference
glyph.
[how]
Invent GlyphsToScale+ keyword, that supports just that.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The files sizes of otf files are (especially with the addition of the
current Material Design Icons) big enough already. The autohints are not
really useful for symbols, so we can drop them and save some space.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Material Design Icons has grown quite a bit.
[how]
Add the icons at their original position which is in PUA1.
Use the desktop font instead of the webfont.
Add cheat cheat file.
Fixes: #365
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We want to differentiate between the old, problematic Material Design
Icons (problematic because we map them to unicode blocks that we should
not), and a future new and updated set of Material Design Icons.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Sometimes we set an empty string as SubFamily name. That ends up as
'Book' which is unexpected.
[how]
The translation from empty to "Book" is done by Fontforge, at least
with version 20220308.
Make sure we always have a SubFamily, and if we don't that must be a
'Regular'.
[note]
This was only a problem with the old naming engine. --makegroups got
this right always.
Fixes: #1046
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The vertical overlap is still not 'pixel perfect', it is off by a small
amount that differs by font.
[how]
The reason is the wrong formula. We take the relative widths of the
glyph to calculate the factor needed to add an overlap in height.
Of course we need to take the relative heights *duh*.
Sometimes I think how dumb can a single person be? :-}
I would say this is copy-and-paste laziness.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The change introduced with commit
Default some Powerline glyphs to '2 cells wide'
scales some Powerline glyphs to fit exactly into a 2 cell width. That
looks good on 'normal' fonts, but when the font becomes wider and less
tall at some point that is just too wide.
This is especially the case with the SymbolsOnly font which has a 1:1
aspect ratio. Two cell Powerline glyphs would have an aspect ratio of
2:1 which is unusable.
[how]
Check the destination font cell aspect ratio.
When a two-cell glyph would be wider than 1.6 times its height the
two-cell-mode is forbitten and all Powerline glyphs are scaled into one
cell width.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The hexagons touch the left edge with a full body, so most likely people
do not want to have any visible gap there.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The vertical overlap has never been a problem (as far as I know). It is
maybe good to have some overlap for the terminal emulators that support
vertical overlap.
On terminals that truncate at the nominal cell border too much overlap
looks bad, i.e. the glyphs 'distorted'.
If we ever increase the overlap it is most likely be meant to be the
left-right overlap.
Note that the glyphs are usually valign='c' and the overlap is
distributed half top and half bottom. There are no other valign values
implemented (just 'not align' which is ... most likely bad).
[note]
Originally this has been part of commit fecda6a of #780.
[note2]
Originally this has been part of PR #967.
Although that had a bug 😬
It used max() instead of min() (T_T)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
f
[why]
We have two variables that hold the same data (sym_dim and dim), which
is confusing ('why do we have it?').
There is also the big 'if' on 'do we want to scale', which contains too
much. In the unlikely event that we have a glyph that needs to be scaled
by 1.0 AND have an overlap the code produces the wrong results.
[how]
Shuffle lines but no functional change (except that now we obey
'overlap' always (not that it has been a problem)).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we scale all Powerline glyphs also horizontally (in X direction) to
'one cell' some might look a bit too small; especially because they were
very big previoulsy (before commit 'font-patcher: Do x-scale powerline
glyphs').
[how]
To get them to a reasonable and always equal width a new scale code is
introduced: '2'. It is evaluated in 'x' or 'y' scaling contexts and
doubles the target cell width (unless a "Nerd Font Mono" is generated
where all glyphs must be one cell wide).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Most Powerline glyphs have a little bit over overlap to the previous or
next glyph to prevent a 'break' in a colored prompt.
It does not make sense to have overlap with glyphs that can never
produce any of that issues, i.e. glyphs that are not filled to the
border. Like all the line-ish glyphs.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
For the non-Mono variants ('Nerd Font' and 'Nerd Font Propo') the
Powerline symbols are scaled in Y but the width is just kept from the
symbol font, whatever that might be (and if it makes any sense).
If you have for example the triangular thing (`E0B0`) it is bigger than
'one cell' and extrudes into the following cell (on 'Nerd Font'). For
the other side (`E0B2`) it is even worse; it is right aligned in the
current cell and so (because it is wider than one cell) it protrudes
into the previous cell.
[how]
Just allow not only Y scaling but also X scaling for non-Mono fonts.
[note]
This is of relevance just for 'xy' scaling, and only the Powerline
symbols do that.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The overlap formula seems to be off sometimes. Although the shift is
correct (and thus the number of 'pixels' that overlap), but the non
overlapping part of the glyph is often not as wide as expected, off by
up to some percent.
[how]
The formula is too simple. It just calculates an additional scale factor
on top of the already existing factor. To get it 'pixel perfect' we need
to calculate first how much the glyph fills the cell - because we want
the overlap to be in 'cell percent' and not 'glyph percent'. That might
be sometimes the same (if the cell is filled completely), but usually it
is not completely full, and that means the overlap will be smaller than
intended.
[note]
To get the current glyph bounding box we pull some lines up in the code
that get the 'dim' variable.
Also use float constants to calculate with float variables.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
While the left-side-waveform gets 'xy' scaled the right-side gets 'pa'
scaled. This has been obviously forgotten.
[how]
Add specific scale rule for right-side-waveform.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
On very small source fonts the patched-in symbol-glyphs can become very
big and create overlay problems. It might be desirable to scale them
down to 'two advance widths'.
[how]
It could be that the glyphs in question are in a ScaleGlyph range. So we
need to activate that code also for non-single fonts.
Further we allow two slots wide symbols in get_scale_factors() for those
fonts.
Now we take the computed scale factors for non-single fonts - only if we
scale down and not up. It will confuse/upset people if the known symbols
in their fonts suddenly become bigger - and it also does not look right.
Fixes: #718Fixes: #747
Reported-by: Rui Ming (Max) Xiong <xsrvmy>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The glyph rescaling is scattered about two functions and several
branches. It becomes hard to follow what is done when and why.
[how]
Use one function that determines any glyph scaling, that includes all
handling except ScaleGlyph related stuff.
This simplifies the code in copy_glyphs() a lot, and keeps all the scaling
in get_scale_factors().
[note]
No behavioral change introduced with this.
[note]
Well, it fixes the possible problem (it will never happen, but lurks)
that a glyph is in the ScaleGlyph range AND has Y scaling set.
The old code first uses the ScaleGlyph scaling and afterwards violates
it by mindlessly doing the Y stretch. This would not happen anymore with
the new code. If a ScaleGlyph is specified for a certain glyph, that
ScaleGlyph is followed and nothing else.
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 some fonts that claim to be monospaced still have some
glyphs that are wider than the others.
[how]
Exclude a small group of glyphs from the 'find the widest glyph'.
The list is specifically targetted at the fonts we patch, see PR #1045.
Most of these glyphs are either visually small and it is unclear why
they are too wide (like double-quotes), or they are from the real
extended set, notably all the Eth (D with a slash) and other added-slash
or added-caron glyphs.
In ignoring them we might 'break' these specific glyphs for the people
who use them (like: they extend out of the cell into the next), but that
is the only way to keep the 'monospaced promise' without redesigning the
actual font.
But without these exceptions we have Nerd Font Mono fonts that increase
the cell width so that 'normal text' is rendered almost unreadable.
So this is an improvement for most users; and I see no way so solve
these font issues for all users (without redesigning the font itself ;).
Also add a 'warning' if a (still) problematic font is to be patched.
As reminder for self-patcher or when we add fonts here.
[note]
Related commit
fbe07b8ab Fix Noto too wide
2945cecd1 Fix Overpass Mono too wide
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 Overpass (Mono) has wide-as-two-letters IJ and ij ligatures.
[how]
Exclude a small sub-range from the 'find the widest glyph' that contain
these ligatures. Yes they will kind of break, but what can we do if we
want to create a strictly monospaced font?
[note]
Related commit
fbe07b8ab Fix Noto too wide
Related: #1043
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Forgot to increase the script version with previous commit.
But especially after a bugfix we need a new version to identify
if people use the version before or after
the fix (e.g. docker image).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
In some cases only some ScaleRule glyphs are used.
[how]
Store mixture of integers and ranges for ScaleGlyph (as is done for
ScaleGroups).
Correctly evaluate mixture of integers and ranges.
[note]
Came up with PR #773
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
fontforge is not really able to work with OpenType variable fonts, at
least not with all. Some support is available as MM, for older formats.
But anyhow we do not really create a patched variable font but a fixed
font.
People might ignore all the errors Fontforge throws on opening, so an
explicit message might be in order.
[how]
It is not possible to detect a VF input font with current fontforge
reliably. Instead we search for the existence of one of the tables that
are needed for a variable font. We can not rely on STAT, because that
might be also used in fixed fonts.
Some fontforges might crash on VFs, so we give a warning before we even
open the font and one after the patched font has been created.
Fixes: #512
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]
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]
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]
When a custom set is to be patched and that set contains the .notdef
glyph the script crashes.
[how]
The glyphs has an unicode codepoint of -1, a code that we explicitely
not patch. That leads to confusion when we try to determine the
codepoint to be used for that glyph, because it has none.
Exclude negative codepoint glyphs when we determine the selection of
to-be-patched glyphs.
As last resort for broken custom sets skip over glyphs that come out of
order (which should be impossible).
Fixes: #1005
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Keeping the ligature removal tables up to date with source font updates
is quite a maintenance burden.
Usually if a terminal supports ligatures at all it has an option to
disable them.
Present ligatures do not prevent monospaced fonts and monospaced
detection.
It was only present in v2.0.0, and the code has been broken with v2.1.0.
[note]
Updated example ligature removal table to the one for Iosevka.
Left stubs in relevant code passages to facilitate finding this commit.
Fixes: #976Fixes: #975Fixes: #973
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If we ever switch the default branch the links would break. So just say
'default branch' directly, whichever that may be.
[note]
CI workflows not changed, I do not know if there is an alias for the
default branch available.
Fixes: #971 (partially)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If we have an empty input font (i.e. for Symbols Only font) and that
font has a gap.. That gap will be redistributed to a gapless font where
the ascenders and descenders are expanded to fill/keep the gap.
If the font has no height (i.e. == ) and a gap, the height will
afterwards be > 0 and the empty font detection breaks.
[how]
Detect empty fonts before gaps.
Fixes: #965
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Use of abs() looks like we do not know if the descenders are expected
to be positive or negative. But it is well defined.
Furthermore on abnormal fonts (where the descenders are nonexisting)
we can use the wrong value. Well, that is academic I guess.
[how]
In our own `ymin` value we store a value like os2_descender, which means
that it is on the same axis as the ascender (ymax). Typical values where
the baseline is on y-coordinate 0 ymax will be positive and ymin (being
below the baseline) will be negative.
The total height has to be calculated from adding ascender + -descender
(when the descenders are lower than the ascenders, which is guaranteed).
The older descender values have positive values; are on an opposite y
axis... The height with them would be ascender + descender.
Well, WE have in the font_dim os2-like values...
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
For some fonts the calculated checksum(s) was wrong.
[how]
Misplaced the multiplier ... the LSB shall not be shifted of course, but
the current code shifts as last action: Also the LSB is shifted.
First shift (old) accumulated content, then add new data.
In that way the last added data (LSB) is not shifted.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We just ignore specified gaps in the source fonts (i.e. set them to
zero). This reduces the line spacing in the patched font (because the
gap is missing).
[how]
Distribute the gap INTO the cell, so that we can work with zero gap (we
need that for the powerline glyphs), and still keeping the powerline
glyphs centered about the regular glyphs AND keeping the total line
spacing.
Idea-by: Tushar Singh <tusharvickey1999@gmail.com>
Fixes: #850
Reported-by: Joe Bolts
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the source font is proportional we can not really create a
monospaced (patched) font from it. The glyph width is for example very
small for 'i' but wide for 'W'.
The glyphs are all left aligned, leaving very strange separation between
smallish glyphs.
Even if we would center the glyphs, the look would be strange and
completely differenmt from the source font's look.
[how]
For proportional fonts do not allow to patch with `--mono`.
The fact if a source font is monospaced is determined by examining some
(very few) glyphs. But testing all our source fonts in the repo shows
that it is sufficient.
Furthermore the Panose flag is checked and differences between the flag
and what the glyph examination found are reported.
The user can enforce `Nerd Font Mono` generation with double specifying
the command line option `--mono --mono`. Still a warning will be issued.
[note]
Because `gotta-patch-em-all-font-patcher!.sh` does not really count the
variations but calculates them in a separate loop it does not know
anymore how many variations are created per family. The numbers are
wrong.
But probably we should count the result font files in the end anyhow.
Because the information is not needed (in an automated manner) this is
not corrected here.
It seems wrong anyhow:
total_variation_count=$((total_variation_count+combination_count))
total_count=$((total_count+complete_variations_per_family+combination_count))
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The patch set table has 'contradicting' or 'complicated' entries.
[how]
When we use exact patching a SrcStart will be ignored and shall be None
to make that clear.
The other two cases patch in only one glyph, make the entries more easy
we could either make them 'exact' (reuse source codepoint) or specify a
SrcStart. At the moment they rely on the (hidden?) rule that non-exact
entries without SrcStart still reuse the SymStart...
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The Font Logos and Octicons codepoints depend on the parallel existence
of FontAwesome. I.e. Font Logos is shifted of Octicons or FontAwesome is
also present in the patched font; Octicons is shifted if FontAwesome is
present.
This means that people, although using a Nerd Font, can expect the
symbols in different locations. The reason is clear; people that just
want one or some symbols and use a specifically patched font will be
able to use the original symbol font codepoints.
But I guess that these uses are nonexisting. Almost all will use
'complete' patched fonts and that is what we deliver and document.
To make the documentation less complicated we should fix the code point
ranges that a specific symbol set will be patched in at.
[how]
Just drop the associated functions and use a False constant instead.
[note]
The two possible places where Octicons / Font Logos ends up are there
since they have been added back in 2015/6 (commits 9620d47ae, f933b5a2).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
In patch set definitions we have for the source ranges SymStart and SymEnd
and for the destination we can specify SrcStart and SrcEnd
The SrcEnd can be automatically generated. For SrcEnd values that differ
from the autogenerated value (are lower) the script would crash, or (are
higher) ignore them anyhow.
There are two modes: 'exact = True' and 'exact = False'.
The SrcStart and SrcEnd values are ignored if exact is True, because the
glyphs are patched into the same codepoint where they originate. This
also means that gaps in the symbols are preserved - all patched in
glyphs have the same codepoint as they have in the source (symbol) font.
When exact is False on the other hand, all (non empty) glyphs are filled
into the codepoints that start at SrcStart. Gaps (empty glyphs) are
ignored and thus are not present as gap in the patched font anymore (*).
The to-be-filled-next codepoint in the patched font just increases by 1
on every filled symbol.
See note for the reason.
This also makes maintining the patch set easier as noone needs to
'calculate' a SrcEnd value anymore.
[how]
Use directly the start value and the counter instead of filling an array
with a range, that is then indexed by the counter.
Before this commit:
list_of_patched_font_codepoints = list(range(SrcStart, SrcEnd + 1))
current_codepoint = list_of_patched_font_codepoints[loop_counter]
After this commit:
current_codepoint = SrcStart + loop_counter
[note]
Maybe related to code removed with c728079b6.
I guess the code uses the list, because it has been believed that glyphs
can only be indexed by strings containing a hex number. The array
supposedly contained that strings.
But in fact the fontforge python module docu is like this:
font.__getitem__(key)
If key is an integer, then returns the glyph at that encoding.
If a string then returns the glyph with that name.
May not be assigned to.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The font flags and PPEM fix does not work with font collection files,
because it does not know how to handle them. It assumes a ttf or otf
font with the specified table structure.
The fix (for single font files) has been introduced with commit
40138bee9 font-patcher: Handle lowestRecPPEM
[how]
Check if the file is of type 'ttcf', and if so fast forward to the given
single font index into the collection.
This can be rather slow...
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With the new TTC feature we might increase the minor number ;-)
This is not just a bugfix.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Someone might want to patch a whole lot of fonts that come in a ttc.
[how]
Just open all fonts that the input file contains (1 or more) and create
a single font or collection font file.
The automatic layer detection does not work in all cases for me, so we
need to manually search for the foreground layer (usually '1').
Code inspiration taken from
https://github.com/powerline/fontpatcher/pull/6
[note]
Changed output in the end to the filename (before it was the font name),
so that one can easily copy&paste or open that file.
Reported-by: Lily Ballard <lily@ballards.net>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
These operations are also not strictly patching.
When we want to handle more than one font we need to have this outside
the patch() function.
[how]
Put opening and exporting (previously in __init__() and patch() into
main() outside the patcher object.
No functional change (except the sourceFont is now closed :->)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The extension handling is a bit out-of-place and could be handled by the
arguments handling, which simplifies the code.
Somes goes for other argument validity checks.
[how]
Put argument checks into setup_arguments().
Dropping self.extensions in favour of self.args.extensions.
No functional change.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[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>
