[why]
When we crate a font we take the OriginalName, add "Nerd Font" and which
patches we applied, and add "Mono" if --mono has been specified:
OriginalName Nerd Font Complete Mono
OriginalName Nerd Font plus Weather Mono
But the 'Mono' part is quite important, but this scheme will put it in a
place where it is easily out of view or has been removed (to keep the
name short).
This truncation is especially bad on Windows Compatiple and when the
user installs both the 'Nerd Font' and the 'Nerd Font Mono':
SomeVeryLongFontName Nerd Font Complete
SomeVeryLongFontName Nerd Font Complete Mono
become after truncation
SomeVeryLongFontName Nerd Font Comp.ttf
SomeVeryLongFontName Nerd Font Comp.ttf
[how]
Always put the "Mono" directly after "Nerd Font" and all the other name
components come later.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Any non-monospaced font will not be be patched, the patcher crashes.
[how]
This must have happened when the box drawing characters rescaling
feature has been disabled. The default value (False) is not always set.
The box drawing patch has the ability to rescale existing box glyphs.
That used to be done when all box glyphs are already existing in the
source font. We do not patch in a new glyph set then, but we rescale the
existing glyphs to match the possibly new cell size.
But that feature is disabled and the attribute 'dont-copy' is never
utilized. It is disabled because some existing box sets are rather ...
sspecial in their overlap and can not be scaled as we would scale them.
Fixes: #1170
Reported-by: Henrique Monteiro <hrqmonteiro@protonmail.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some old applications seem to depend on obsolete xAvgCharWidth values to
show two-cell glyphs correctly. Fontforge can only generate OS/2 tables
version 4, but these applications need 2 or less. In fact they seem to
not look up the version number, but rely on the value being like it
always has been ;-)
One example is Windows notepad, that takes the xAvgCharWidth as base for
the cell size and draws the two-cell chars in a cell twice that size -
without any regard to glyph width.
[how]
These issue seems to be encountered rather seldom and only with some
obscure (grin) applications. There is also no good way to handle this
automatically. So we add a command line option that allows the user to
tweak the value after patched-font generation.
The option is called `--xavgcharwidth`:
* If not specified the behavior of the patcher does not change
* If just given the xAvgCharWidth is copied over from the source
* If a number is added that number is used as xAvgCharWidth
* If the number added is zero we will calculate the old style xAvgCharWidth
Fixes: #522
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we have a ttc and tweak the contained fonts we recalculate the
total checksum after each tweak while we only need to tweak it after all
changes (included fonts) have been tweaked.
[how]
Pull the total checksum recalculation out of the subfonts loop.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[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>
