[why]
The symbol glyphs are rescaled (when --mono is specified) so that they
have a predefined width after insertion in the source font (to be
patched font, called 'target font' below).
Sometimes the width of the glyph after insertion is off a bit, like
0.2% or so. This seems strange, as we calculate the target width
exactly.
[how]
As expected this are rounding errors. In the old code we take the
original width of the glyph when it is in the symbol font and
rescale it when it is in the target font. The width of the glyph
should be the same in the source and the target font, right?
It fact it is not, because the coordinate systems of the two fonts can
(and usually are) different. fontforge's magic scales the glyph
into the new coordinate system on insertion, such that it is approx
the same as before. But when the coordinate system is integer based
we get some small rounding errors just from copy and paste.
To solve this, we
- first copy the glyph from the source into the target font
- then determine the glyphs width
- then rescale the glyph to the target width
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The ScaleGlyph just gives a lot of anonymous numbers.
[how]
Write down which glyphs are rescaled and group them to related
groups.
They are not changed to 'new' ScaleGlyph method.
[note]
Checked the current Devicons, and they are completely different to ours.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
While patching for --mono with Font Awesome we get glyphs that are
too wide, for example '_520' (0xF22B). In the symbol font original
it is about 1918 wide. According to ScaleGlyph FONTA_SCALE_LIST
it shall be scaled as 0xF17A - which is only 1664 wide.
[how]
Fill the ScaleGlyph of Font Awesome with groups of glyphs that shall be
kept same-sized after scaling.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
While patching for --mono with Font Awesome we get glyphs that are
too wide, for example '_520' (0xF22B). In the symbol font original
it is about 1918 wide. According to ScaleGlyph FONTA_SCALE_LIST
it shall be scaled as 0xF17A - which is only 1664 wide.
This results in too wide symbols in the patched font.
[how]
The ScaleGlyph dict works like this:
- 'ScaleGlyph' Lead glyph, which scaling factor is taken
- 'GlyphsToScale': List of (glyph code) or (list of two glyph codes
that form a closed range)) that shall be scaled
Note that this allows only one group for the whole symbol font, and
that the scaling factor is defined by a specific character, which
needs to be manually selected (on each symbol font update).
The redesign drops 'ScaleGlyph' and changes the glyph list to:
- 'GlyphsToScale': List of ((lists of glyph codes) or (ranges of glyph codes)) that shall be scaled
Each item in 'GlyphsToScale' (a range or an explicit list) forms a group of glyphs that shall be
as rescaled all with the same and maximum possible (for the included glyphs) factor.
The old data structure is automatically rewritten to new entries.
[note]
This commit just changes the algorithm. As the new ScaleGlyph is not
used for any font, there is no change in the patched fonts.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Sometimes fonts patched with --mono are not recognized as monospaced
fonts.
One reason can be that the inserted glyphs are too wide. This will show
in the end in the font's advanceWidthMax property which is not congruent
to the normal font width.
[how]
After all the scaling and jiggling we double check if the new glyph
already in the to-be-patched is not wider than our design goal for the
width. Normally one would expect that this always holds.
An exemption could be if we insert ligatures, that are two spaces wide.
But at the moment we can not anyhow (because there is no way to add
information to the ligature tables right now).
If a glyph is wider a warning is issued.
No warning is issued if the glyph shall have some overlap. That overlap
is taken into account of this check.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The code around `currentSourceFontGlyph` and `copiedToSlot` is
needlessly complex and checks for conditions that are impossible to
occur (possibly because the algorithm was different in the past).
It becomes rather hard to follow which variable holds what kind of value
and when.
[how]
Drop all the string-that-contain-hex-numbers stuff and use a regular
integer list/variable.
Format the string when it is output.
Drop obsolete checks.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
