[why]
Sometimes we set an empty string as SubFamily name. That ends up as
'Book' which is unexpected.
[how]
The translation from empty to "Book" is done by Fontforge, at least
with version 20220308.
Make sure we always have a SubFamily, and if we don't that must be a
'Regular'.
[note]
This was only a problem with the old naming engine. --makegroups got
this right always.
Fixes: #1046
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The vertical overlap is still not 'pixel perfect', it is off by a small
amount that differs by font.
[how]
The reason is the wrong formula. We take the relative widths of the
glyph to calculate the factor needed to add an overlap in height.
Of course we need to take the relative heights *duh*.
Sometimes I think how dumb can a single person be? :-}
I would say this is copy-and-paste laziness.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The change introduced with commit
Default some Powerline glyphs to '2 cells wide'
scales some Powerline glyphs to fit exactly into a 2 cell width. That
looks good on 'normal' fonts, but when the font becomes wider and less
tall at some point that is just too wide.
This is especially the case with the SymbolsOnly font which has a 1:1
aspect ratio. Two cell Powerline glyphs would have an aspect ratio of
2:1 which is unusable.
[how]
Check the destination font cell aspect ratio.
When a two-cell glyph would be wider than 1.6 times its height the
two-cell-mode is forbitten and all Powerline glyphs are scaled into one
cell width.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The hexagons touch the left edge with a full body, so most likely people
do not want to have any visible gap there.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The vertical overlap has never been a problem (as far as I know). It is
maybe good to have some overlap for the terminal emulators that support
vertical overlap.
On terminals that truncate at the nominal cell border too much overlap
looks bad, i.e. the glyphs 'distorted'.
If we ever increase the overlap it is most likely be meant to be the
left-right overlap.
Note that the glyphs are usually valign='c' and the overlap is
distributed half top and half bottom. There are no other valign values
implemented (just 'not align' which is ... most likely bad).
[note]
Originally this has been part of commit fecda6a of #780.
[note2]
Originally this has been part of PR #967.
Although that had a bug 😬
It used max() instead of min() (T_T)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
f
[why]
We have two variables that hold the same data (sym_dim and dim), which
is confusing ('why do we have it?').
There is also the big 'if' on 'do we want to scale', which contains too
much. In the unlikely event that we have a glyph that needs to be scaled
by 1.0 AND have an overlap the code produces the wrong results.
[how]
Shuffle lines but no functional change (except that now we obey
'overlap' always (not that it has been a problem)).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we scale all Powerline glyphs also horizontally (in X direction) to
'one cell' some might look a bit too small; especially because they were
very big previoulsy (before commit 'font-patcher: Do x-scale powerline
glyphs').
[how]
To get them to a reasonable and always equal width a new scale code is
introduced: '2'. It is evaluated in 'x' or 'y' scaling contexts and
doubles the target cell width (unless a "Nerd Font Mono" is generated
where all glyphs must be one cell wide).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Most Powerline glyphs have a little bit over overlap to the previous or
next glyph to prevent a 'break' in a colored prompt.
It does not make sense to have overlap with glyphs that can never
produce any of that issues, i.e. glyphs that are not filled to the
border. Like all the line-ish glyphs.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
For the non-Mono variants ('Nerd Font' and 'Nerd Font Propo') the
Powerline symbols are scaled in Y but the width is just kept from the
symbol font, whatever that might be (and if it makes any sense).
If you have for example the triangular thing (`E0B0`) it is bigger than
'one cell' and extrudes into the following cell (on 'Nerd Font'). For
the other side (`E0B2`) it is even worse; it is right aligned in the
current cell and so (because it is wider than one cell) it protrudes
into the previous cell.
[how]
Just allow not only Y scaling but also X scaling for non-Mono fonts.
[note]
This is of relevance just for 'xy' scaling, and only the Powerline
symbols do that.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The overlap formula seems to be off sometimes. Although the shift is
correct (and thus the number of 'pixels' that overlap), but the non
overlapping part of the glyph is often not as wide as expected, off by
up to some percent.
[how]
The formula is too simple. It just calculates an additional scale factor
on top of the already existing factor. To get it 'pixel perfect' we need
to calculate first how much the glyph fills the cell - because we want
the overlap to be in 'cell percent' and not 'glyph percent'. That might
be sometimes the same (if the cell is filled completely), but usually it
is not completely full, and that means the overlap will be smaller than
intended.
[note]
To get the current glyph bounding box we pull some lines up in the code
that get the 'dim' variable.
Also use float constants to calculate with float variables.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
While the left-side-waveform gets 'xy' scaled the right-side gets 'pa'
scaled. This has been obviously forgotten.
[how]
Add specific scale rule for right-side-waveform.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
On very small source fonts the patched-in symbol-glyphs can become very
big and create overlay problems. It might be desirable to scale them
down to 'two advance widths'.
[how]
It could be that the glyphs in question are in a ScaleGlyph range. So we
need to activate that code also for non-single fonts.
Further we allow two slots wide symbols in get_scale_factors() for those
fonts.
Now we take the computed scale factors for non-single fonts - only if we
scale down and not up. It will confuse/upset people if the known symbols
in their fonts suddenly become bigger - and it also does not look right.
Fixes: #718Fixes: #747
Reported-by: Rui Ming (Max) Xiong <xsrvmy>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The glyph rescaling is scattered about two functions and several
branches. It becomes hard to follow what is done when and why.
[how]
Use one function that determines any glyph scaling, that includes all
handling except ScaleGlyph related stuff.
This simplifies the code in copy_glyphs() a lot, and keeps all the scaling
in get_scale_factors().
[note]
No behavioral change introduced with this.
[note]
Well, it fixes the possible problem (it will never happen, but lurks)
that a glyph is in the ScaleGlyph range AND has Y scaling set.
The old code first uses the ScaleGlyph scaling and afterwards violates
it by mindlessly doing the Y stretch. This would not happen anymore with
the new code. If a ScaleGlyph is specified for a certain glyph, that
ScaleGlyph is followed and nothing else.
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 some fonts that claim to be monospaced still have some
glyphs that are wider than the others.
[how]
Exclude a small group of glyphs from the 'find the widest glyph'.
The list is specifically targetted at the fonts we patch, see PR #1045.
Most of these glyphs are either visually small and it is unclear why
they are too wide (like double-quotes), or they are from the real
extended set, notably all the Eth (D with a slash) and other added-slash
or added-caron glyphs.
In ignoring them we might 'break' these specific glyphs for the people
who use them (like: they extend out of the cell into the next), but that
is the only way to keep the 'monospaced promise' without redesigning the
actual font.
But without these exceptions we have Nerd Font Mono fonts that increase
the cell width so that 'normal text' is rendered almost unreadable.
So this is an improvement for most users; and I see no way so solve
these font issues for all users (without redesigning the font itself ;).
Also add a 'warning' if a (still) problematic font is to be patched.
As reminder for self-patcher or when we add fonts here.
[note]
Related commit
fbe07b8ab Fix Noto too wide
2945cecd1 Fix Overpass Mono too wide
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 Overpass (Mono) has wide-as-two-letters IJ and ij ligatures.
[how]
Exclude a small sub-range from the 'find the widest glyph' that contain
these ligatures. Yes they will kind of break, but what can we do if we
want to create a strictly monospaced font?
[note]
Related commit
fbe07b8ab Fix Noto too wide
Related: #1043
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The docker image can not start fontforge:
Error relocating /usr/bin/fontforge: FindProgRoot: symbol not found
[how]
The problem might be that we base on the 'latest' Alpine container, but
install a edge fontforge.
If I see this correct:
https://hub.docker.com/_/alpine/tags
'latest' is the same as latest-stable. Probably we should use a matching
apk repo.
Fixes: #1042 (maybe, need to push to test)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Forgot to increase the script version with previous commit.
But especially after a bugfix we need a new version to identify
if people use the version before or after
the fix (e.g. docker image).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
In some cases only some ScaleRule glyphs are used.
[how]
Store mixture of integers and ranges for ScaleGlyph (as is done for
ScaleGroups).
Correctly evaluate mixture of integers and ranges.
[note]
Came up with PR #773
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
fontforge is not really able to work with OpenType variable fonts, at
least not with all. Some support is available as MM, for older formats.
But anyhow we do not really create a patched variable font but a fixed
font.
People might ignore all the errors Fontforge throws on opening, so an
explicit message might be in order.
[how]
It is not possible to detect a VF input font with current fontforge
reliably. Instead we search for the existence of one of the tables that
are needed for a variable font. We can not rely on STAT, because that
might be also used in fixed fonts.
Some fontforges might crash on VFs, so we give a warning before we even
open the font and one after the patched font has been created.
Fixes: #512
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Fontforge had a new release. There is no particular error it fixes that
we suffer on, but keeping up to date?
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The actions have several warnings.
[how]
Update them all.
For example action-gh-release 0.1.14 runs on node12 which is deprecated.
upload-artifacts 3 also switches to node16 and 3.1.1 removes obsolete
set-output.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
For some reason setting of some variables broke.
[how]
Did not spent any time to find the reason, just rewrote it in a more
readable and debuggable manner and now it works (??!)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The release run does not work with the fontforge AppImage anymore.
Obviously Github's 'ubuntu-latest' changed :-}
[how]
Install missing fuse.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Although all font files of one font (directory) have the same timestamp
the different fonts (e.g. Agave vs Roboto) have still slightly different
timestamps.
[how]
Note the time when the release workflow has started.
Use that as timestamp for all fonts.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The messages from parallel font-patcher runs can be very confusing, so
it has been disabled some time ago (without a comment in that commit?!).
However, if someone wants to repatch multiple fonts on a local machine
it might be beneficial to run more than one process to have work on all
cores.
[how]
Add option to select multiple processes in parallel.
Limit the amout to 8, which might be a good value for typical end-user
machines with 4 cores and 8 threads.
Patching Cascadia Code (12 fonts) took these times on my machine:
1 job: 21m 55s
4 jobs: 6m 24s
8 jobs: 5m 14s (this runs 8 and then the remaining 4)
16 jobs: 4m 48s (this runs 12 in parallel)
Adding a proper `-j` that takes a numeric argument is rather too much
work for my taste, so we stick with 8 for now.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Running gotta-patch-em-all creates a lot of output that is most likely
not wanted.
[how]
Add --verbose option to gotta-patch-em-all.
Hide debugging information unless it is wanted by specifying this option.
Also change font-patcher to produce less verbose output and respect
--quite in more places.
This includes a change that we try to tweak the font flags only if
source and destination font are ttf or otf, because we can not read the
other raw font files anyhow.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When working on the font-patcher the developer needs to test the changes
on a number of fonts. This is usually a manual call of `font-patcher`
and afterwards a 'diff' of the newly created font with the 'old' font in
the patched-fonts/ directory with fontforge (which has a font-compare
option).
If you run gotta-patch-em-all normally the newly generated font will
replace the existing font and git will ALWAYS show it as different. The
reason is that at least the timestamp in the generated font has changed.
Far more easy would be if the new gotta-patch-em-all run could keep the
previous timestamps, in that way one can immediately see that the old
and new fonts are bitwise equal (via git).
Furthermore if you expect a change and want to show the differences of
old and new font in fontforge you need both fonts in the filesystem.
But a normal gotta-patch-em-all run replaces the font. A different
destination folder would help here.
[how]
Introduce two new (independent) options to
a) keep the timestamp equal to previous patch run
b) generate the fonts in a different directory
While b) is straight forward, a) is a bit more complicated, esp because
filenames can change and so on. So the script examines just one (1)
random font in the specific font directory and uses its timestamp. In
most cases this is correct enough if the developer uses gotta-patch-em-all
consequently.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
All the fonts will have different timestamps, and within each font the
creation and modification date might also differ. That is quite
confusing and makes automated testing very complicated.
[how]
Use one date-time for ALL fonts and for creation and modification date
in the font file.
But do not change the date-time if we already set that somewhere before :-}
Also remove the 'special' properitary fontforge timestamp tables FFTM from
the patched fonts. This is only possible since FontForge 20th Anniversary
Edition.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Oh boy do I hate the boilerplate code needed with optargs, but without
it every parameter becomes a burden.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we want to patch all fonts by calling the script without any
options it fails.
[how]
Give the correct regex to find all directories.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The powerline glyphs (and only them) undergo a xy scaling, where both
dimensions are maximized into the 'cell'.
Normally cells are taller than wide, and everyting looks fine. But we
have square cells (e.g. 2048 * 2048) with the SymbolsOnly font, and
there might be some self patched font that has similar very-wide (in
comparison to hight) cells.
In these fonts some powerline glyphs look rather ugly. For example the
'half cicles' become very wide and un-round, the triangulars become very
pointy.
[how]
Add a new patch-set attribute 'xy-ratio'. When that is set the vertical
(y) scaling is done as usual but the horizontal (x) scaling is limited
such that the width/height ratio is maximally the attributes value.
For example setting it to 0.75 the height is maximized (as usual) but
the width is maximized to be less then 0.75 times the hight (or as wide
as the cell is, whatever is smaller).
It will work with both, 'xy' and 'pa' scaling, at least theoretically.
It has been only checked where it is used now, i.e. with 'xy'.
A possible overlap is not taken into account.
[note]
The values are taken for this reasons:
- 0.59: This is the original half-circle ratio, higher values make them
loose the (half) circular appearance
- 0.5: The half circle lines are more shallow
- 0.7: The triangulars should not be too pointy (random number)
Fixes: #658
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The old doc was a bit unclear and I always had to read the code when
changes / additions to ScaleRules were needed.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
If a ScaleGlyph is defined that ScaleRules will just be that one rule,
even if in parallel the user specified some ScaleGroups.
So it is either ScaleGroups or ScaleGlyph but not both.
If someone specifies both there is no warning or check.
[how]
Just allow both. Rewrite the ScaleGlyph to an additional (last) entry in
the ScaleGroups.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Assume a set of monospaced icons in a ScaleGroup that scatter all about
(like Braille).
With --variable-width-glyphs we forcefully remove all left side
bearings and set the width to the width of the combined bounding box.
This is not correct, usually with monospaced ScaleGroup icons we should
preserve the original advance width.
[how]
Do not remove left side bearings on ScaleGroup glyphs in
--variable-width-glyphs mode.
Set the width of any glyph in --variable-width-glyphs to the 'monoscaped
advance width' if that particular glyph has one (from a ScaleGroup).
The effect is that all positive bearings will be 'added' and put on the
right hand side of the glyph, while the glyph itself, or rather the
combined bounding box, is still strictly left aligned.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We have still a confusing naming. There are two different things that
are called 'ScaleGlyph':
- The setting in the patch set
- The reference glyph for old style scaling
[how]
Rename the patch set member to ScaleRules, as this is what in contained.
Also rename variable names accordingly.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We now have the 'old' and the 'new' GlyphsToScale things, which behave
differently, but they have the same name. That can lead to confusion. At
least I am always confused when I look at the code after a month or so.
[how]
Call the 'new' method 'ScaleGroup' instead.
The 'new' feature (which includes creating a combined bounding box and
synchronized shifting) 'ScaleGroup'.
The 'old' feature (which scales all glyphs as if they would have the
size of one reference glyph; shifting is individual) still consists of
'ScaleGlyph' and 'GlyphsToScale'.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The code looks so compliacted while in fact it is not (so much).
Rounding sometimes and sometimes not is hard to reaon about. The
un-rounded values should in principle be better, but there is some
rounding hidden in the font that we can not really simulate, so simulate
what we can.
[how]
Always scale (even if factor is one) and round to integer the BB.
[note]
Also use 'is not None' ideom.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The advance width in the bounding box data is sometimes wrong (usually
to small). Turned out only AFTER the glyph scaling.
[how]
The wrong scaling factor has been used *duh*.
Advance width is of course X axis.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When only one symbol glyph is examined we conclude that it comes from a
monospaced glyph set.
This might be correct or not, but when we can not positively say it is
monospaced we should not handle it as monospaced.
[how]
We require at least TWO glyphs with the same width (and no glyph
with a different width) until we set the 'advance' bounding box
property. Which says that this particular glyph subset is monospaced.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The scale-glyph-data is used only for 'pa' scales, but thereafter used
for all shifts, even if the scaling has been 'x' or 'y' or both.
As we do not use GlyphToScale for anything but 'pa' scaled glyphs that
should not make any difference right now. But it will be an obscure bug
if we ever want to handle the Powerline symbols with a scale group.
I do not know if that will ever happen, but I tried it whilst
experimenting spending hours on finding this bug.
[how]
Access the GlyphToScale data and use it even for 'x' and 'y' scaling, if
we have it for the particular glyph.
[note]
Also change 'invalid' flag from False to None.
Also use 'is None' or 'is not None' for comparisons with None.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
