[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>
[why]
These operations are also not strictly patching.
When we want to handle more than one font we need to have this outside
the patch() function.
[how]
Put opening and exporting (previously in __init__() and patch() into
main() outside the patcher object.
No functional change (except the sourceFont is now closed :->)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The extension handling is a bit out-of-place and could be handled by the
arguments handling, which simplifies the code.
Somes goes for other argument validity checks.
[how]
Put argument checks into setup_arguments().
Dropping self.extensions in favour of self.args.extensions.
No functional change.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Parsing the command line arguments has nothing to do with the actual
patching.
If we want to patch more than one font we need to separate the partching
from unrelated work.
[how]
Just do the argument processing in main() and hand the information over
to the patcher object.
[note]
No functional change. Lines copied over (almost *) 1:1.
(*) Exceptions:
self.sym_font_args is now only a local variable, as it is only used in
this one function.
The startup message is shown on ... startup (i.e. main()).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The glyph is needlessly detailed (for a font).
There is another, more simple glyph, which is also used by fileicons.
More details see PR #833.
Reported-by: tecosaur <contact@tecosaur.net>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Entering two consecutive vertical-bars (i.e. `||`) results in the
display of just one - the right - bar glyph.
[how]
The ligature removal is only partially implemented. The rule at work
here is not removed. There are two parts at work:
One rule to replace the first bar with nothing.
One rule to replace the second bar with a ligarture glyph with negative
left bearing, that shows two bars.
The second rule has been removed, but the first is still there.
This commit also removes the first rule.
[note]
The whole design here is broken. We remove only some rules and leave
others intact, for reasons unknown to me. Other ligartures will also be
only partially removed and leave the user with unreadable output.
We should either remove all (!) tables and not just some, or leave the
ligatures in the font.
As the ligature removal has been broken at large anyhow (see previous
commit), I would suggest to not remove any ligatures (anymore).
Fixes: #934
Reported-by: Rádler Ákos <akos.radler@gmail.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Only one tables is removed, even if we want to remove more.
With 0a480bb the indentation of the code has changed, and now the loop
is (apart from printing) empty. See also #934
[how]
Re-indent the lines to restore functionality as originally forseen with
commit 557fc00.
Reported-by: Rádler Ákos <akos.radler@gmail.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When so svg files could be optimized we still try to commit the
'changes'. There are no changes - so nothing is committed (empty commits
are avoided).
But the workflow run still shows the 'commit back to repo' step,
although we know beforehand that it will not commit anything.
[how]
Technically that is no problem and the behavior is unchanged, but we can
just skip the commit step if we know there can not be anything to
commit...
It just looks nicer :-}
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
This is so big, it will shrink 2 times with a
optimize-original-source.sh run, and we want to have 'optimal' glyphs
after the next (automated) CI run
[how]
Use optimize-original-source.sh once and just commit the php.svg.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Despite commit
cc2b54770 generate-original-source: Remove FFTM table
we still get unneeded font rebuilds.
The reason is that the font creation time is not only encoded in FFTM but
also in HEAD.
[how]
We could simply diable timestamps also in HEAD, but that would leave us
with a strange font; strange because no one knows when it has been
created.
Instead we take the more laberous route here: Do detect changes and not
rely on the git history:
* Find out current font's creation date
* Create the font anew with that date as creation date
* If the 'real' font content is unchanged we would now have a 100%
identical new font file; we can detect that with `git diff`
* If it is not identical, something apart from the timestamp has
changed and we create the font again, this time with the real current
time as timestamp and commit that file back to the repo
This only works if creation and modification time are always the same on
all font creations; we need to ensure this by always using the
SOURCE_DATE_EPOCH method, even for 'normal' font creation.
This is a bit more involved than what I would have hoped for, but there
seems to be no easy solution.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the CI triggers a rebuild of the original-source and the font
contents is unchanged we do not want to commit the new version back to
the repo.
But because fontforge puts the creation date into the font file it will
always differ on every run, and we would needlessly create commits.
[how]
We could use the SOURCE_DATE_EPOCH approach and set the dates to the
relevant change (commit) times like so:
cd src/svgs
export SOURCE_DATE_EPOCH="$(git log -1 --format=%ct -- *.svg)"
and only afterwards call the generator script / fontforge.
But that would need a complete git repo checkout and not just a shallow
one (which is faster and thus is used by github action/checkout).
Instead we can instruct fontforge to not put any timestamp into the
file. The timestamps are anyhow a fontforge proprietary extension.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Often the SVGs are rather detailed and result in a big
original-source.otf, which then again results in bigger than needed
patched fonts.
[how]
Typically people suggest using svgo to make SVGs smaller, but that just
tackles the representation of the icon, i.e. the actual svg file. That
does not help us at all. We do not need small svg files, we need simple
icons with few points and lines. svgo does not have that capability.
Instead Inkscape's 'Simplify' is used. Repeated use can destroy a glyph,
so we need a scale down margin to stop 'over-simplification'.
The values given for the margin at the moment are purely empirical, the
current glyphs survive repeated use of the new simplification script and
still look good.
The resultant original-source.otf file size is approximately similar to
the previously achieved by Ryan's manual work.
[note]
We need a newer Inkscape, thus update to Ubuntu 22.04
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we add a custom glyph (or want to update Seti) the process is
rather laborious and we are needed to change the font and the
accompanying `i_seti.sh` in sync.
[how]
We use a data file to map icon (svg) filenames to codepoints and
readable names.
That file is parsed and the font and info file is created (overwritten
in the repo); and could then be easily committed. This can be a CI
workflow.
Having a dedicated mapping file (`icons.tsv`) enables us to have stable
codepoints for the same symbol over time. Changes in codepoint
allocation can be checked in git.
Having the font autogenerated help guarantee that the icons are all
likely scaled. We rescale them all to the same size and mid-position.
That is not needed for font-patcher, because it rescales and shifts
again based on to-be-patched font metrics. But it certainly is better
for a view into the original-source font.
Sizes and position are still roughly equivalent to the hand positioned
glyphs.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With commits
ef8c12e28 Document and update cheat sheet data
bcef53dad Update cheat sheet
the README has not been updated, and i_cod.sh is still
listed as 'not existing'.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Maybe people would like to uninstall the fonts installed with the
script.
In fact the uninstall could already be acieved by giving the --clean
option and installing no new font. Well, apart from the fact that the
scripts prevents runs with no installed font. And then the user must
specify the same installpath that has been used for the install, which
is a bit tedious.
[how]
Add new command '--remove' (with no short option).
Make -L / --list option a dry-run option for --remove.
Uninstall both possible installpaths.
Fixes: #407
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We have only 'Complete' in the repo anymore, so it does not make sense
to provide commands to select un-complete patched fonts.
[how]
Leave stub/comment in so that - if there ever is a need to resurrect the
feature - one can find this commit and the deleted code.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The script is not running with current (i.e. year 2022) release versions
of Inkscape.
The script does not warn if a font is not installed (and creates a
garbage preview instead).
[how]
Rewrite the script that is uses Inkscape actions instead of verbs. Verbs
are already removed in Inkscape HEAD.
Check if needed font is indeed installed.
Do not generate useless Symbols Only font preview (it needs a specific
different one, I suppose).
Disable `svgo`. Maybe we should generate PNGs instead?
Change path for created images, so that it is already correct for the
gh-pages and we could use the github-pages-deploy-action to publish them.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Some icons where added to Seti (number change).
Some numbers numbers where wrong.
Add new Codicons section.
Also add new instructions how to create.
Fixes: #846
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The script just creates the 'database' or the cheat sheet, but the
surrounding elements have to be added manually.
We do not like 'manually'.
[how]
Take the current cheat sheet code and rip top and bottom off, to glue it
to the generated 'database'.
Also change the filename like the final file would be named.
Well this is still not automated, but at least this is the first step in
that direction.
On the GH pages, there release and everyting is manual at the moment.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We already have 2 data files to assemble the css file, and that clutters
the scripts/ directory; and there will come more for the cheat sheet.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The add-and-commit steps are so unbelievable slow.
[how]
We do not need the other tags, so we do not need a fetch before adding.
See comments on the action's homepage.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The generated file `nerd-fonts-generated.css` is made smaller with an
external service as manual step...
# [Nerd Fonts] The following is generated from the build script, then through https://www.minifier.org/
We do not want any manual steps.
[how]
Luckily the difference is just to remove whitespaces and unneeded
semicoli. We can do the same while generating.
[note]
At first I tried to postprocess the generated file with sed, but of
course the strings that have blanks in them made that rather
complicated.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The file that would be created in temp/ is probably not needed
There is a lot out noise
[how]
Create the txt file only if we already have a temp/ dir.
Make that clear in the final output message.
Remove debugging outputs.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
