[why]
The naming has bizarre blanks strewn in sometimes,
or is all caps. For example
`C a s k a y d i a C o v e` or
`CASKAYDIACOVE-Regular`
[how]
When run under Python2 all strings are unicode strings because
`unicode_literals` is imported by `font-patcher`.
Unfortunately the code checks for type str; but that will all become
type unicode with the import.
One check is suboptimal anyhow and can be dropped, while the other is
turned around.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
People might want to use the font-patcher with just the one script file.
The error message does not help them to understand the problem.
[how]
Require the modules only if the user wants to use it (i.e. --makegroups).
Give the expected path in the error message.
We could also download the missing files instead, similar to #741
But that PR did not get any feedback yet, so I do not know if this is
something we want.
Anyhow, the fetching of missing parts should then be unified for both
usecases (i.e. Fontname* and src/glyphs).
And then, there is font-patcher.zip (which needs to be adapted), maybe
that is the way to go.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Sometimes scripts can not be run.
[how]
Depending on installed python versions and 'alternatives' setup the
script's shebang needs to point to python3 of course.
Also the files need the executable bit set.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The option `--parser` instructs `font-patcher` to come up with the font
naming by utilizing the FontnameParser object.
This sounds logical from a programmers perspective, but the option name
is not descriptive for end users of `font-patcher`
[how]
As usual naming is hard. A short but maybe more descriptive name for the
option can be `--makegroups`; as it describes what the option means for
the end user: functioning font grouping.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
This reverts commit df42c917128701e9be199fb12d77a3fecad52cb1.
[why]
Having all the code in one big file is probably a maintenance nightmare.
We should develop other solutions to make the usage for end-users easy.
Future commits might do that.
[why]
The fontname for Windows can be quite unusable, for example
`CaskaydiaCoveNerdFontCompleteM-`
for several different fonts, as this is the maximum allowed length of 31
characters that is enforced.
The style/weight is completely lost.
[how]
Split the name into base and style (at a dash `-`) and just shrink the
base name. Result for example:
`CaskaydiaCoveN-ExtraLightItalic`
Use equal approach for the PostScriptName (although it is less likely
that length limit is ever met).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We want to patch Cascadia with `--parser` while all other fonts shall be
patched as before.
[how]
Use the config.cfg file that each source font can have to specify one
arbitrary option to the font-patcher calls.
This is just set in Cascadia's config.cfg, but can be extended to other
fonts gradually.
In this way the stand alone `font-patcher` works as before, unless
someone adds the `--parser` option. Which probably will become the
recommended way to use it over time.
The patch-em-all script on the other hand can be instructed to use or
not to use --parser on a font by font basis via their cfg file.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Also including the italic variants.
We do not use the PL versions but patch in the PL glyphs ourselves.
If this is smart can be discussed (I believe: no).
This does not add 'Cascadia Mono'.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
A lot people expect the font-patcher to be a stand alone script. They
even think that the source glyphs (symbols) to be added to be somehow
magically there and one PR makes sure that they are fetched if missing.
The same problem arises when we have a script distributed over multiple
files. For maintenance reasons and code quality this is what one wants.
But that might hinder easy use of the font-patcher.
[how]
Put all the code in the main script.
That has an additional drawback: For the nameparser_test* scripts to
work we need stand alone files for that classes. Now the code is
duplicated and will get out of sync.
I have no solution for that, and it all boils down what Nerd Font wants
to do.
One solution would be to have font-patcher properly set up / divided in
many .py files, and to create one monolithic font-patcher from all the
sources on demand (via github actions or manually when someone pushes
changes to any of the constituends). That approach is taken by a lot of
C++ 'header only libraries' that originally consist of a lot files but
create one big 'all in one' file automatically from all the small files.
For now I guess we can live with the duplication, but we need to think
about a solution, as this will bite us sooner or later.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
fontforge has an undocumented call to set the fsSelection bits.
Never rely on documentation :-(
Found this here:
https://github.com/fontforge/fontforge/issues/3174
And the readback values are actually not read from the source font, so
we do not use them.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Under certain circumstances the WWS names (Family and Subfamily) are
used to identify a font. We do not touch these SFNT table entries, so
when the font is renamed these are wrong (have the original name).
Font-grouping will go wrong then.
[how]
The typographic ('Preferred') Family and Styles are set correctly
already and they follow the WWS pattern, so the WWS fields can be (and
should) be empty. They exist to allow font grouping in the case where
the typographic names do not follow that pattern.
Remove preexisting WWS entries (because they are not needed anymore,
otherwise we would need to write the corrected new names there).
We already set the WWS bit in fsSelection that is needed:
def fs_selection(self, fs):
"""Modify a given fsSelection value for current name, bits 0, 5, 6, 8, 9 touched"""
[...]
b |= WWS # We assert this by our naming process
return b
Unfortunately we have no way (jet) to set fsSelection.
This is only the case for Iosevka for all fonts in src/unpatched-fonts.
Reported-by: Rui Ming (Max) Xiong <xsrvmy>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some CJK fonts seem to have no Fullname.
[how]
But they have a Postscript name. Use that for parsing the names.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
DO NOT MERGE
[why]
A lot of the fonts have incorrect naming after patching. A completely
different approach can help to come up with a consistent naming scheme.
[how]
See bin/scripts/name-parser/README.md
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Code Climate configuration for Python is per default rather restrictive
and would force us to split all stuff into too many files.
[how]
Have some faith in the cognitive capabilities of people.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The detection if all fonts of a given directory are to be processed is
broken if the font files contain blanks
(like 'Symbols-1000-em Nerd Font Complete Mono Windows Compatible.ttf')
[how]
Need to put name argument in quotes...
Also fix counting for sfd files (but we never generate them anyhow)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Not sure why they are here, all patched fonts reside now in the
`patched-fonts/` folder.
So we have two times two different symbols only font sets?
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The symbol only fonts Symbols-1000-em Nerd Font Complete.ttf
and 2048-em in `NerdFontsSymbolsOnly/` are generated from
some 'almost' empty source fonts, that are assumable in turn generated
from the sfd font descriptions in `src/glyphs/`?
The process is not documented and we have issues in the generated font
(for example the glyph for capital `E` is defined (and empty) #581#765).
[how]
Use the existing font definitions from `src/glyphs/*.sfd` directly as
source font. That needs a change in font-patcher because the empty
fonts have no glyphs that can be used to orient the scaling upon. In
that case scale on the source font definitions EM.
Then we need patch-em-all to also patch *.sfd fonts.
And finally we need patch-em-all to take a font specific command line
switch for font-patcher (compare 9e2bc9a26 of #723) to instruct it to
create a ttf rather than a sfd font file.
In the sfd file we additionally set the Panose type.
And the UnderlinePosition is adjusted to match the current patched font.
[note]
Also fix wrong glob pattern in patch-em-all `*.[o,t]tf`. The comma is
for sure some leftover from a '{}' shell pattern, that is not used
anymore. (This comment is probably outdated, due to rebasing.)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We want to patch some fonts with different font-patcher options.
[how]
Use the config.cfg file that each source font can have to specify one
arbitrary option to the font-patcher calls.
[note]
This is partially commit 9e2bc9a26 from #723.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the source font does not have a HEAD table (i.e. is not a ttf/otf
font but for example a sfd) we can not copy the PPEM and flag values.
The patcher crashes.
[how]
Just put the code into a try block. We could check the signature
instead, but this would add more and complex code.
Reported-by: Jakub Jirutka <jakub@jirutka.cz>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We 'manually' patch the font file after `fontforge` created it. This can
go wrong, for example we fail to create a correct new checksum.
Or we fail to patch the correct font property.
[how]
Also build `showttf` from the `fontforge` package and use it to extract
some font properties:
* Check the example patched font file checksum
* Compare the `lowestRecPPEM` of source to patched font file
[note]
`fontforge` set `lowestRecPPEM` always to 8 in generated fonts.
Hack has a value of 6.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some fonts set specific lower resolutions and handle the small rendering
very nicely. But fontforge does not copy that information when it opens
a font; rather some default values are always written. That can destroy
the small font rendering.
The responsible settings are the 'ppem_to_int' flag and the
'lowestRecPPEM' setting, both in the HEAD table.
[how]
After successfully patching and generating the new font we copy that
settings over from the source font.
Instead of using fontTools (and thereby requiring all users to pull that
dependency) we handle the raw font file changes ourselves.
Fixes: 612
Reported-by: nojus297
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the patched font does not have a fullname (which can never happen)
the postprocess is called with a wrong filename.
[note]
Also output the file name of the patched font, for easier access by the user.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Lilex is missing from the 2.2.0 RC and is not automagically patched.
[how]
Add Lilex to the font metadata database :->
[note]
Lilex's licence has no RFN given.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The new 'pathname' pattern always added a '*' glob to the end.
So when we wanted to (just) recreate "Inconsolata" (by specifying
"/Inconsolata") that means "/Inconsolata*/*.[to]tf".
But that includes also "IncolsolataGo" and "InconsolataLCG" :-(
[how]
Just remove the globbing after the pathname. If a pathname is specified
it must be the correct pathname and no star is added per default.
Users could still specify "/Incon*" to get all Inconsolatas in the
pathname based filter mode.
[why]
It might be easier to use the precompiled application than to build it
ourselves.
[how]
The AppImage has the typical problem with relative paths, so we need to
change some small calls.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The purged (obsolete) files are still existing after release.
[how]
We restore the deleted files before it adds the new ones.
Just delete all font files and then download all the release files (all
newly created fonts).
`git add` on a directory will remove all missing files.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[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>
