[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]
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]
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]
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>

Fixes: #1108

Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[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]
Defaults should come first.
Unify empty lines or no empty lines.
Add some docu.

Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why]
The unicode 2630 (Trigraph Heaven) is often used in vim powerlines (at
least).

[how]
Draw nice 3 rectangles.
Insert 'pa1', always scaling also in non mono fonts. That needs a new
attribute: '!'.

The scaling is in fact an issue. Using 'pa' is the way of least
resistance.
Without the new attribute the glyph would look different in mono and
nonmono, which is not nice.

Fixes: #589

Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why]
This is more an academic fix. If we calculate widths from with bounding
boxes we always need to take xmin and xmax into account. Usually xmin is
zero and so it does not make any difference.

But maybe one can see better what is calculated, especially as we use
xmin in other cases.

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>

[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 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]
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]
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]
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>