[why]
With addition of the version the lines are too long to be rendered
without wrap in the default gitlab width.
The EM size is not really relevant for most, while the version is.
And we want a concise table, so something has to leave.
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]
This makes it easier to check if we are up to date.
[note]
Just checked the versions where a source links has been given.
Updated a few links and sorted stuff.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[how]
./gotta-patch-em-all-font-patcher\!.sh /NerdFontsSymbolsOnly
Just add `Mono` variants to commit.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We do not want fonts with gap. Gaps are explicitely removed on patching
anyhow. Why should the templates have gaps?
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]
There is code that shall read the config file and act on
config_has_powerline.
Usually it is set to "1", but Ubuntu has this "0".
Regardless the content, if the variable has content the code assumes the
value is true. That is probably not wanted.
[how]
Use a numeric comparison.
[note]
```
git blame UbuntuMono/config.cfg
4abe6c77b0 Ubuntu/Bold-Italic/config.cfg (Ryan L McIntyre 2017-07-23 17:17:21 -0400 1) config_has_powerline=0
```
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We do not want to rebuild all fonts, just the affected ones.
Without a proper release timestamp this is impossible (i.e. harder) to
do via CI, so do it manually 😬
[how]
./gotta-patch-em-all-font-patcher\!.sh /JetBrainsMono/Ligatures/ExtraLight
./gotta-patch-em-all-font-patcher\!.sh /JetBrainsMono/Ligatures/Light
Hmm, the patched fonts got slightly smaller. These font file sizes are a
mystery for me.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
In JetBrainsMono v2.242 the exclam-equal ligature is broken.
It has been fixed in v3.000.
[how]
The JetBrains Mono v3 has not been released yet. So we just transplant
the one broken glyph from v3.000 into our v2.242.
[note]
https://github.com/JetBrains/JetBrainsMono/issues/494Fixes: #963
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]
We have only a rather old 3270font: v1.2.23
This new font can be processed with current FontForge without problems.
And we have the benefit of an update.
[how]
Because the paths change (Medium->Regular etc) we need to purge the
patched-fonts/ directories manually. The automatic purging does work
only if at least the paths are kept.
[note]
https://github.com/rbanffy/3270fontFixes: #947
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
https://github.com/googlefonts/Inconsolata
Only small changes visually, but of course completely different from the
paths (because now the source is a 2D variable font).
Small letter t changed a bit.
Under the letter dot and block-building glyphs changed.
Subscript numerals.
Closes: #774
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]
For some fonts with long names the fields are not long enough and for
example a 'Mono' can not be seen.
[how]
Use same field widths as `name_parser_test2`.
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>
