[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>
[why]
In the patch loop we use two methods to do something with the glyphs
- the glyph object directly (i.e. font[codepoint])
- a selection of glyphs in the font
Using the selection is a bit anonymous and depends on lines far away
(where the selection is set); direct glyph access seems to be easier
understood and is used almost everywhere.
Direct glyph access can not be used for copy() and paste(), but for
everything else.
[how]
The direct glyph addressing is already in use almost for everything, but
not for the transform() calls. This is changed.
Now we transform a specific glyph and not 'all selected glyphs' (with
selection = that specific glyph).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The selection is never used.
Later in the code we use a sourceFont selection to paste the glyphs into
it, but that is selected just there, before, and locally not totally.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
This is a TODO item. Well, two in fact.
The symbolFont's selection is used for two things
- the main loop to iterate over all glyphs to insert
- to select the one glyph that is actually copied over
Because the main loop uses iterators on the selection.
The iterator is not 'stable' but invalidates if the selection
is changed.
The current code therefor restores the old selection before the loop
jumps to the head again.
This design is not very robust.
[how]
We need the selection to copy the symbol glyph.
But we can rewrite the loop that it does not need the selection at every
iteration, but that the selection is copied into a list, and we loop
over that list - which is independent on a later selection state.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
