[why]
Any non-monospaced font will not be be patched, the patcher crashes.
[how]
This must have happened when the box drawing characters rescaling
feature has been disabled. The default value (False) is not always set.
The box drawing patch has the ability to rescale existing box glyphs.
That used to be done when all box glyphs are already existing in the
source font. We do not patch in a new glyph set then, but we rescale the
existing glyphs to match the possibly new cell size.
But that feature is disabled and the attribute 'dont-copy' is never
utilized. It is disabled because some existing box sets are rather ...
sspecial in their overlap and can not be scaled as we would scale them.
Fixes: #1170
Reported-by: Henrique Monteiro <hrqmonteiro@protonmail.com>
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some old applications seem to depend on obsolete xAvgCharWidth values to
show two-cell glyphs correctly. Fontforge can only generate OS/2 tables
version 4, but these applications need 2 or less. In fact they seem to
not look up the version number, but rely on the value being like it
always has been ;-)
One example is Windows notepad, that takes the xAvgCharWidth as base for
the cell size and draws the two-cell chars in a cell twice that size -
without any regard to glyph width.
[how]
These issue seems to be encountered rather seldom and only with some
obscure (grin) applications. There is also no good way to handle this
automatically. So we add a command line option that allows the user to
tweak the value after patched-font generation.
The option is called `--xavgcharwidth`:
* If not specified the behavior of the patcher does not change
* If just given the xAvgCharWidth is copied over from the source
* If a number is added that number is used as xAvgCharWidth
* If the number added is zero we will calculate the old style xAvgCharWidth
Fixes: #522
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we have a ttc and tweak the contained fonts we recalculate the
total checksum after each tweak while we only need to tweak it after all
changes (included fonts) have been tweaked.
[how]
Pull the total checksum recalculation out of the subfonts loop.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Both are full fledged families, one specifically for terminal, the other
not. Although it might be that people want both there is a likelyhood
that some just need one set.
Splitting these makes the individual release packages smaller and more
handable, and improves release workflow run time.
[note]
Also fix RFN of mononoki en passant :-}
See comment on mononoki's RFN with the mononoki 1.6 update commit.
See also #803
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Also drop all the bitmap fonts that we have in src/unpatched-fonts/ but
we do not do anything with them.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
They started with new version numbering and have different version on
each subset.
The complete naming set changed. See their website to find the font you
used before.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Forgot to include this in the previous commits and accidentially pushed
them directly to master.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
After the initial locking of many issues (where we called the workflow
once every hour, it can only process 50 items in one run), this high
frequency is not needed anymore.
[how]
Just search for old closed issues once a week on monday morning.
Also remove manual trigger.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Sometimes people comment on (long) closed issues because they have
similar problems. But that is often just a me-too, and all the details
to reproduce the issue are missing.
[how]
Lock old closed issues and add some comment that a new issue should be
opened instead.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some glyph names in the CSS/cheat-sheet/json database are wrong.
[how]
For the wheather icons: Check against the glyph names in the original
repo's CSS.
For the Octicons: Check against glyph name in the symbolfont.
Did not check all glyphs, just the two reported ones.
Fixes: #1146
Reported-by: page-down
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
It does probably not make too much sense to add the box drawing glyphs
to proportional fonts. The boxes that are drawn need to be filled with
some text, and if that does not have monospaced property the box will
always look ugly and not fit and change when the font is changed.
[how]
Make the fact if we detect a source font as monospaced or not a property
of the patcher object.
Always determine that property (before we just determined it when the
target font should have monospaced behavior).
Use that new property to enable/disable the box drawing glyphs.
In a way it is now also prepared to add that as command line parameter
should the need for that arise.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Normally the 'cell' size should not change on patching. If the 'cell'
size does not change we do not need to rescale the box glyphs. They
probably worked before, they work the same afterwards.
Another reason to disable this is Cascadia Code. It has box drawing
glyphs that extend for more up then the normal cell. If we rescale that
to fit a probably new cell size we get a 'midline' that is too low
(because the upper stems are longer).
[how]
Leave the code in, but disable 'just scale do not copy' mode.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We have 2 different types of metrics warnings. When one warning has been
issued the other is not displayed (if it would trigger). The reason was
that I thought normally there would be no warnings and if someone would
have to inventigate the sourcefont anyhow.
[how]
But the warnings are quite common, so differentiate a bit more when
generating.
Also improve one warning message to make clear what the warning is
about.
And fix the assignment of advance width to width; which has no
consequence because it is never used (at the moment). But it was
obviously wrong.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The greys seem to be too small.
[how]
Separate the blocks into real block, greys and quads. They all have
different scales in Hack which we use to patch in.
If we do not patch in and just scale existing glyphs these three groups
should always be sufficient.
Note that in Hack the quad block 2597 is too small; we could have scaled
it together with the blocks group, but that would raise issues with well
behaved fonts that we just scale and not patch in.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some few glyphs get a wrong left side bearing in `Nerd Font`:
E0C2: -1230
E0C5: -857
E0C7: -667
E0CA: -1230
These are the powerline glyphs which are right aligned and have overlap
and a target width of 2 cells wide.
[how]
To simplify the code add a new function that decides if a symbol shall
be one or two cells wide.
That function is then used where we had explicit tests already.
Use the function also in the overlap correction code, such that the
overlap is corrected for the right cell occupancy of the concrete glyph.
[note]
I guess that the overlap correction for 'c' alignment for 2 cell wide
glyphs is also broken. But we do not have such glyphs, so we ignore it
for now :-}
This fixes the previous commit 'font-patcher: Fix overlap for align c and r'.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The box drawing glyphs (center aligned) and some Powerline glyphs (that
are right aligned and have a limited xy-ratio) are positioned wrong.
Affected are all box drawing glyphs (e.g. 2548) and some Powerline
glyphs (i.e. E0B2, E0B6, E0C5, E0C7, and E0D4).
[how]
The box drawing glyphs are center aligned and have overlap. The code
does not correct the overlap (left bearing) but uses the default case of
'make the left bearing zero'. The code does just check left aligned
glyphs and not center aligned ones.
Add the correct overlap for center aligned glyphs (i.e. half the
overlap).
The Powerline glyphs are right aligned. Usually that works, because the
glyphs are created with the right size, so that no additional
manipulation is needed.
But if the glyph has a ratio limit the resulting size will be different.
We could in fact fix the size code, somehow, but that is rather
complicated, formula-wise. Instead we just scale these glyphs (which are
the 5 listed above) and shift them to the right position such that the
correct overlap results.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
