[why]
When font-patcher is on a read only filesystem the pacher can not run.
This is for example the case when fontforge is a AppImage.
[how]
Try if the logfile can be written, and if not disable logging into a
file.
Reported-by: Bliss X. Xu <blissLove8@gmail.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The scale glyph is not the biggest glyph; the bell-slash is a little bit
wider than the design cell...
[how]
Switch to modern ScaleGroups. These determine the virtual combined
bounding box of all glyphs in the group and scale them 'as one'.
Also add some more groups.
Also correct wrong code of one small stuff.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With the Octicons update some codepoint contents changed.
Also some symbols scale still wrong.
[how]
Check fonts and add / drop entries.
Use GlyphsToScale+ to correct position of Github text icon.
Fixes: #1198
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
On some fonts the patcher tries to raise a warning, but it can not.
[how]
The 'overlap' variable can hold a floating point number or be None (if
there shall be no overlap processing. Formerly we output that value
using the {} format, but the logging module does not have that. To
accomodate to different types use repr() instead.
[note]
Also improve some other logging related calls.
Reported-by: Jim Myhrberg <contact@jimeh.me>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some sourcefonts, even that are monospaced, have a `fi` and/or `fl`
ligature that maps into one cell. That looks very strange.
[how]
Partially revert commit
148b0c445 Sunset ligature removal
for the cases that have a one-cell `fi`, `fl`, etc ligature, or a `ldot`
related ligature - that is active by default. Discretionary ligatures or
Stylistic Sets are not changed.
Do the removal on all patched fonts for consistency, not just `Nerd Font Mono`.
[note]
On Noto different subtables are needed for Sans, Serif and Sans-Mono. We
can not set up different configs for each, so all are tried in all fonts
and might fail (this is normal).
Same holds for OpenDyslexic Alta, Regular, Mono, Bold...
Fixes: #1187
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
This reverts commit 621008773c,
and adapts the code to more recent changes (logging, enums).
[why]
Lekton has a too wide line spacing.
Lekton was the only font that selected TYPO but we forced it to WIN,
because not all glyphs fit into the values from TYPO.
But that seems to be wrong. Examining the glyphs that are really bigger
than the TYPO line spaces, these are only graphical glyphs that shall
span multiple lines. So I guess we should revert that change and render
Lekton with the TYPO values.
[note]
https://github.com/ryanoasis/nerd-fonts/issues/1056#issuecomment-1529141863
[why]
The intend was to drop 'Sans Mono' in the renaming process, because the
name is just too long.
ERROR: VeraMono-Italic.ttf ====-< Shortening too long PS family name: BitstromWeraSansM Nerd Font Mono -> BitstromWeraSansM Nerd Font Mon
ERROR: VeraMono-Italic.ttf ====-< Family (ID 1) too long (32 > 31): BitstromWeraSansM Nerd Font Mono
[how]
Include the whole name in the replacement pattern.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The license of Bitstream Vera requires patched fonts to contain neither
"Bitstream" nor "Vera" in the name. It explicitly requires that also
for fonts that (only) add some glyphs.
Yes, we are rather late to notice this :-( Sorry.
[how]
Rename Bitstream Vera to BitstromWera, and also drop the Sans Mono part
of the name. The new name looks and sounds similar enough to get the
reference, while being shorter and somewhat logical.
Fixes: #1173
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The old MDI are kept, just disabled. Maybe we need them or someone else,
for backward compatibility. Can be dropped sometime in the future.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The octicons got a lot updates.
But they do not have a font anymore.
[how]
Keep our old codepoints constant, but add the new icons thereafter.
This commit just moves all the mechanics in and moves the (old) font.
No actual update here.
The mapping file has been created with the analyze_octicons script.
Fixes: #490
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Because we do not know if a complete family of fonts has an italic face
we must always assume it does. To get clean RIBBI families in ID1/2 we
create a different family for the oblique slant.
But that is not needed if the font does not have an italic slant, but
just an oblique one (like Bitstream Vera and descendants).
[how]
Add new command line option for font-patcher that specifies if the
family of fonts should be patched under the assumption that there might
be an italic face (default), or if we are sure there is none (and we can
leave oblique in the RIBBI group).
This is then applied to the config.cfg files.
Note that this does not take into account any other of the known_slants.
But they are not encountered in any of our prepatched fonts.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some messages are not useful in all cases, and we want to hide them.
On the other hand there are messages that we want to only hide in
--shutup mode. Hmm.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
To check just the naming and other stuff it is good to not patch (and
not store) the resultant font.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we still process the arguments we do not have a real logger object.
[how]
Use the default (root) logger in these cases.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The fonts generated with --makegroups work on all platforms, so there is
no need for options --windows and --also-windows anymore.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
As we introduces a default --makegroups value of 1 the solution to a
problem can not be omitting the option but the user needs to
specifically call it with value 0 instead.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We want to keep "Nerd Font" in the font name if possible and instead
shorten the weight part with accepted abbreviations. But these abbrevs
are hard to read and sometimes a more mild abbreviating might be
sufficient to get the desired name length.
[how]
Introduce a new shortening method for the weight parts of a family name.
It takes a longer word (often un-shortened) when a weight stands on its
own, but when a modifier is used together with the weight the more
aggressive two-letter abbreviations are used.
That new shortening method becomes the default and all the functions get
a new parameter to enforce completely aggressive shortening, i.e. always
use the shortest possible form.
The new way to shorten is exposed all the way out to the font-patcher
user who can select the shortening method as parameter to the
--makegroups option. That option is undocumented because I expect some
changes later on, still.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The patched font is named 'OriginalName Nerd Font' and not
'OriginalName Nerd Fonts'. This is a bug.
[how]
Take the correct singular string form when assembling the names.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The outputs while patching are very ad-hoc and not grouped
systematically.
If run via gotta-patch-em the output is hard to process afterwards
automatically.
[how]
Use the logging module which outputs the messages and also writes a
run-log with all vital information.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The option --makegroups shortens the name suffix and the styles
rigorously. That is needed for fonts with long names and/or long style
descriptions.
But some simple font would not need that. With the option we can adjust
the amount of shortening to fit the specific font (family).
Unfortunately we can not automatically detect that, because the
font-patcher script can not assume anything about a complete family as
every font file is patched individually.
[how]
Add optional numeric parameter to option '--makegroups'.
The values can be:
0 - turned off, use old naming scheme
1 - turned on, shortening 'Bold' to 'Bd'
2 - turned on, shortening 'Nerd Font' to 'NF'
3 - turned on, shortening 'Nerd Font' to 'NF' and 'Bold' to 'Bd'
4 - turned on, no shortening
If --makegroups is not specified this is the same as '--makegroups 0'.
If --makegroups is specified without number that means '--makegroups 3'.
[note]
The argparser module takes the last specified parameter as the one to
use: If you specify --makegroups multiple times only the last one will
be used.
This can be used for gotta-patch-em-all. Per default it (will) specify
--makegroups 3. But via config.cfg we can specify a font centric other
number for individual fonts. The config.cfg values are added later in
the command line, so they take precedence.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
This just drops the 'windows compatibility' options in association with
the name parser (i.e. --makegroups') as we want to always create fonts
that work on any platform.
Note that the fonts prodused right now are NOT windows compat anymore
and you can not specify the flag. Violating 'git rules' this commit is
not working correctly. But it is easier to do this in smaller steps.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The filenames of the patched fonts are rather ... unique:
- they contain blanks to separate name parts
- they do not separate name and style/weight
This is in part due to history reasons, because the names were not
parsed at all and just some suffix added.
Example (contrived):
Victor Mono Nerd Font Propo Bold.ttf
Normally font file names would be:
VictorMonoNerdFontPropo-Bold.ttf
We ourselves relied in part on that naming scheme, but do not follow it.
There are a lot powerline fonts out there that all add blanks to the
filename.
Some filename recommendation can be found in [1].
[how]
The filename is now always constructed directly from name ID 16
and name ID 17. If one of them is empty ID 1 and ID 2 are used as
fallback, as customary.
ID 16 (ID 1) and ID 17 (ID 2) are separated by a hyphen.
The result is that in can differ from the fontname (ID 6) and uses
always the longest most readable name parts.
[1] https://forum.fontlab.com/fontlab-studio-tips-and-tricks/font-family-naming-in-fontlab-studio-5/
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we rename a font we should always also change the unique ID.
[how]
Take the fullname and the Nerd Font version number. In general we do not
have the version number in the NameParser object; but we have the
'Version' name and we loot the last word (which we have set to the Nerd
Font version already in the patcher) as version descriptor.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Nowadays the Complete font is the normal font. We already dropped the
partially patched fonts long ago. If someone is self patching they will
know if it is a basic font or a complete font.
And already now one can not see if the patched font is bare minimum
(i.e. Seti, Custom, and Devi) or includes Powerline and/or
PowerlineExtra.
[how]
Just drop "Complete" from the naming.
[note]
As the name changes and thus the file name a lot of the other scripts
will break. But they might break anyhow because other naming changes, so
fix that as last commit.
See also commit
557fc004c Attempt to fix duplicate fonts in fontbook on osx
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When patching the SymbolsOnly font via gotta-patch-em-all we create a
'Nerd Font Propo'. With the previous change that will be reflected by a
changed name.
The name change can come unexpected for users.
And in fact a 'Nerd Font' version would be ridiculous as there are no
preexsiting glyphs in the font.
So we should keep the previous naming:
* `Symbols Only Nerd Font` (which is in fact a Nerd Font Propo)
* `Symbols Only Nerd Font Mono` (for the monospaced version)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We have three ways to create a patched font
- 'normal' (i.e. monospaced oversized symbols): Nerd Font
- 'mono' (i.e. strictly monospaced small symbols): Nerd Font Mono
- 'proportional' (i.e. proportional symbols): Nerd Font Propo
The first two variants have a name, the third one has no name, it is
also called 'Nerd Font' (and it was THE font, for v2.1.0 (only)).
[how]
Invent and set new name, so that all variants have different names.
Makes refering to them explicit.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[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>
[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>
