[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]
Pomicons changed their licence from CC BY-NC-ND 3.0 to SIL 1.1 here:
fedf571f29
[how]
Change text.
I'm not shure which one we would call our most restrictive source now,
so remove that paragraph.
[note]
Fix whitespace error en passant.
Fixes: #1143
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The font is not available on the Github Workflow VM.
[how]
But we have it in the repo anyhow...
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We had a bug that font-patcher crashes with fonts with references.
[how]
Just try such a font with all fontforge versions. Just tests if it
patches, the patch result is not checked.
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]
For some unknown reason some files have the execute right bit set in
git. That is neither needed nor recommended.
The *.cfg files are pulled in with `source`, so they do not need to be
executable.
[note]
Example command to check
find . -perm /111 -type f
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]
Somebody might want to have a file where all symbols we add are listed.
At the moment there are only the i_*.sh scripts and the CSS files. Both
are rather unwieldy.
[how]
Just create a json file with all symbol names, like the CSS file.
Fixes: #448
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]
The last missing powerline-extra glyphs should also be in this set.
The intermediate line's color is not visible in some terminals.
[note]
Also fix that E0CF is shown twice.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When testing 'Nerd Font' fonts (i.e. symbols may be 2 cells wide),
the output does not take that into account and does not insert
the needed blanks.
[how]
Because the actual width can not be easily determined add a
parameter (just add anything as parameter) to switch some glyphs
to two cell mode. These glyphs are in a list, i.e. hardcoded.
If the widths in non-Mono fonts is ever changed this script needs
to be adapted.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
On MacOS Ventura the unicode codepoints are shown instead of the actual
glyphs.
[how]
On that OS the bash is rather old and does not have the unicode escape
sequence \u. As it is rather hard to convert it to octal UTF8 we instead
embed simply the concrete characters, as done in the i_*.sh scripts.
Note: zsh on that OS does have it, though.
[note]
I'm no Mac expert, just trying to get this working.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The left side wave is also used on the right side.
The right side wave is never shown.
[how]
Well,...
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We have the same file in the repo, once with the ending 'TXT' and once
with the ending 'txt'.
This raises an issue on case-insensitive file systems.
[how]
The original in src/unpatched-fonts has the lower case ending.
So drop the capital letters one.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
In the CI we have only a shallow clone of the repo, so access to tags is
not possible. Instead of resulting in a nice message like '2.3.3-35' we
get an empty string.
[how]
As we have no tags we can only write the commit hash and other
information given in the only existing (i.e. last) commit:
date, author, title
It's a bit more cumbersome but one can still see from which point in the
repo the archive has been created.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If we create the zip file not only on releases we need some better
version information inside.
We can not use the same approach with real releases, because we add the
tag at a later stage in the workflow.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some changes to bring it in line with the other workflows.
[how]
Sorted from short to long:
* Name all steps
* Correct trigger
* Remove unused output
* Simplify zipcmp decision
* Use apt instead of apt-get
* Update upload-artifact action
* Remove some trailing whitespace
* Remove name from artifact to prevent strange double zip name
* Use ordinary checkout instead of sparse - we need it anyhow to commit
[note]
Ok, 'simplify zipcmd decision' that might be matter of taste.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
It is not really a release, it is just a convenience for people that
want to download the current master patcher with all accessories.
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 print two times the name of the output font, and never the name of
the input font...
[how]
*cough*
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]
Python 2 is long since EOL.
With the last commit we want to use Enums, which are not available in
Python 2.
I believe Python 2 broke some time before already, I stopped caring for
Python 2 some time ago.
This does not change any existing code. It just documents that there are
no efforts anymore to support Python 2.
This is PR #1121
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>
