[why]
Fontforge 2020 March or 20th Anniversary have problems to generate fonts
with a lot of table entries. This is for example the massive entries for
ligatures in Iosevka. We can not generate valid font files with that
fontforge versions. We can not even detect (from Python side) if
fontforge had problems.
[how]
We fixed fontforge itself upstream with
https://github.com/fontforge/fontforge/pull/4883
That fix became available first with Fontforge March 2022 Release.
We could use the AppImage or build from scratch, because no package is
available on Ubuntu 20.04 or 22.04.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
The Alpine Linux package repository no longer contains the `fontforge` package for x86 and ARM architectures in the `edge/testing` branch.
This commit updates the Dockerfile to install the `fontforge` package from the `edge/community` branch to resolve the failing Docker builds.
[why]
The find predicate (e.g. -iname) and predicate parameter (the actual
pattern) are in one variable and will be handed over to find as one
parameter instead of two.
How could this ever work?
[how]
Pass predicate mode and predicate parameter as two shell variables.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The 'monospace' width is determined by examining all the 'normal' glyphs
and taking the widest one.
'Normal' means 0x00-0x17f: the Latin Extended-A range.
Unfortunately Noto has the '1/2', '1/4', '3/4' that are all wider then the
normal (i.e. letter) glyphs.
[how]
Exclude a small sub-range from the 'find the widest glyph' that contain
no glyphs one would call 'letter'.
Fixes: #610
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the file names of the source files change which happened for example
with these commits:
ac432eb20 Updated Inconsolata source to latest upstream version of 2.001 (WIP #289)
9c5ad2c78 Updated Inconsolata source to latest upstream version of 2.001 (WIP #289)
or the patched font files naming changes because of any other reason:
The patched-font directory will contain the new files along with the
unchanged old ones (because they where not overwritten).
Typically when manually updating the patched-fonts this is not a
problem, as the maintainer can clean this up by hand (if it is noticed).
But with a github action we might want to have that automatized.
To not deter the usability of the script for end-users or for patching
single fonts of a collection we do NOT want to purge 'all old files'
because we can not know if they are really old or not.
[how]
For each directory that we process from the source fonts we check if all
font files therein match our search criterion (pattern, $2). If we are
going to patch _all_ files that are in that source directory we delete all
font files in the destination directory; expecting that all files will
be recreated.
If we do _not_ patch _all_ files, we can do nothing, because we can not
decide if the existing files originate from one of the
not-to-be-processed source font files or are zombies.
Fixes: #786
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Before Font Logos 1.0.0 there was no stable-codepoint guarantee, and the
later revisions (0.18) reassigned the codepoints. That makes updating
for us very hard, because we would have to resort the icons or follow
the codepoint changes.
With 1.0.0 this changed. That new major release introduced not only a
codepoint guarantee, but it also shifted the codepoints from the F100
region to the F300 region, where we put them anyhow (in most cases).
That is one subset less with 'dynamic base codepoint'.
The reassignment of codepoints in Font Logos kept the codepoints stable
for the icons we already have in release 2.1.0. But at the moment the
2.2.0 Release Candidate (which updated Font Logos with commit 557b8da)
have added glyphs, which are on different points as compared with the
Font Logos 1.0.0 release.
What I want to say, we need to get this straight, before our 2.2.0 RC
turns into a Release 2.2.0.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The font matix contains the directory names of the font files. The
directory names are taken from
bin/scripts/lib/fonts.json
and specifically extracted with
bin/scripts/get-font-names-from-json.sho
That script returns the .folderNames
Later in the release script we use the folder name to limit the fonts
that patch-em-all shall process. Unfortunately patch-em-all could (until
the previous commit) just work with font-filenames and not with
directory names. But the matrix gives us just directory names.
This is for example a problem with this fonts:
$ ll src/unpatched-fonts/BigBlueTerminal
-rw-rw-r-- 1 fini fini 25632 Jan 1 14:03 BigBlue_Terminal_437TT.TTF
-rw-rw-r-- 1 fini fini 69964 Jan 1 14:03 BigBlue_TerminalPlus.TTF
The *directory* of that fonts is correctly noted in fonts.json as
"BigBlueTerminal" but the font files do not begin with that!
[how]
Now, that patch-em-all can also filter on the directory name, we just
need to utilized that in the workflow run. If the filter shall work on
directory names the first character needs to be a slash, so we just
prepend it to name we got from the matix.
Fixes: #824
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We can limit the font files to patch with the gotta-patch-em-all script
to some specific file names; the case insensitive beginning of the
basename of the font file, to be specific.
Sometimes we do not know how the actual font files are named, we just
know the directory name.
[how]
The old filter checked for the beginning of a file name, so we keep this
behavior and allow to check for the beginning of a directory name.
As differentiator the first character of the passed filter is used. As a
slash is not allowed in the file name filters: If the first char is a
slash, we search for font files in a directory that begins with that
name. The file name is not considered in this case.
Examples:
gotta-patch-em-all-font-patcher!.sh Fira
Patches all font files that begin (case insensitive) with 'fira'.
It must be the basename of the font file, the path to the file is not
considered. (Old behavior.)
Translated to a glob this is roughly **/Fira*.[ot]tf
gotta-patch-em-all-font-patcher!.sh /Fira
Patches all font files that are in directories that begin (case
insensitive) with 'fira'. It can not be the beginning of the font
file basename.
Translated to a glob this is roughly **/Fira*/**/*.[ot]tf
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we do CI we probably want to raise an error if no font file could
be found.
[how]
Check how many font files have been generated and return with exit
code 1 if the number is zero.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
In ligature-enabled environments the accent grave will be rendered as
zero width, thus overlapping with the next character (in some source
fonts).
The problem is, that the glyph type in the sourcefonts is set to 'auto',
and fontforge exports these as 'mark' - the patched font will be broken.
[how]
There is no way we can get that glyph to be 'auto', but we can force it
to be an ordinary 'baseglyph' instead, and that will be respected on
export.
Maybe I should raise an Issue at fontforge... maybe later.
Fixes: #858Fixes: #582
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
The script assumes that it's run from inside bin/scripts, by setting source and target directories according to the output of pwd. It doesn't perform any checks whether it's run from the right directory, so it just doesn't find the fonts if the working directory is different.
Now it sets the directories relative to the script directory.
[why]
The readme states that one should call `fontforge` with `./fortforge`.
That means that no PATH is used, and will usually fail, because the user
is in our repo and not in the directory where the fontforge binary
resides in. And even if ... then the `font-patcher` script would be
somewhere else. That makes no sense.
[how]
Drop the `./` prefix of the `fontforge` call.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
A lot of issues do not have screenshots and which glyphs are the problem has to be asked and or guessed.
Also change to newer github issue template method.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When a True Type Collection file (.ttc) is used as font source this is
not handled and just the first file in the collection is processed and
saved. But the user is not informed.
When the target file format is True Type Collection, no file at all is
written.
These are two distinct cases, because you can in fact open a .ttc and
save the first font (patched) when specifying a different extension via
`-ext`. Or open a normal font and specify `ttc` as extension i.e. target
file format.
[how]
Check if a collection is to be opened. As we currently have no code to
loop through all fonts (and just the first font is processed) a message
is issued and we exit. Typically a user would want all the fonts and
would have to 'explode' the collection into multiple single font files
beforehand.
Prevent the target to be ttc, as that is not handled in fontforge at
all. To save TTCs a different API function is to be used. Unfortunately
fontforge does not care and just does nothing.
font.generateTtc() would have to be used with ttc extensions...
Anyhow. As the looping through all fonts is missing anyhow, and I feel
the usefulness is very slim, we just prevent silent failures with this
commit.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The symbol glyphs are rescaled (when --mono is specified) so that they
have a predefined width after insertion in the source font (to be
patched font, called 'target font' below).
Sometimes the width of the glyph after insertion is off a bit, like
0.2% or so. This seems strange, as we calculate the target width
exactly.
[how]
As expected this are rounding errors. In the old code we take the
original width of the glyph when it is in the symbol font and
rescale it when it is in the target font. The width of the glyph
should be the same in the source and the target font, right?
It fact it is not, because the coordinate systems of the two fonts can
(and usually are) different. fontforge's magic scales the glyph
into the new coordinate system on insertion, such that it is approx
the same as before. But when the coordinate system is integer based
we get some small rounding errors just from copy and paste.
To solve this, we
- first copy the glyph from the source into the target font
- then determine the glyphs width
- then rescale the glyph to the target width
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The ScaleGlyph just gives a lot of anonymous numbers.
[how]
Write down which glyphs are rescaled and group them to related
groups.
They are not changed to 'new' ScaleGlyph method.
[note]
Checked the current Devicons, and they are completely different to ours.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
While patching for --mono with Font Awesome we get glyphs that are
too wide, for example '_520' (0xF22B). In the symbol font original
it is about 1918 wide. According to ScaleGlyph FONTA_SCALE_LIST
it shall be scaled as 0xF17A - which is only 1664 wide.
[how]
Fill the ScaleGlyph of Font Awesome with groups of glyphs that shall be
kept same-sized after scaling.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
