Fix unequal weather icon scale #916

[why] First the new ScaleGlyph has been introduced with commit e5768e9 font-patcher: Redesign ScaleGlyph parameter and afterwards it has been enhanced to avoid rounding errors with commit 983226a font-patcher: Fix scaleGlyph related rounding error The later commit uses a function that explicitely says it will destroy the glyph at a specific location, AFTER we already patched in one glyph (namely F000). It does not look too bad, bad that glyph is not correctly rescaled or translated. Only that glyph is affected because only Font Awesome uses the new ScaleGlyph capabilities, and only the first glyph of a set is affected. [how] The ScaleGlyph calculations need to be done before the final glyph is patched in. It is shifted some lines up. Usually that glyph is not existing in the to-be-patched font, so we create a dummy first. Also need to correct distinction between 'unicode in symbol font' and 'unicode in to-be-patched font', as this would bite us in cases where we move the symbol's codepoint. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

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

[why] When the combinded bounding box of a range of glyphs is to be determined and the range contains an empty glyph the resulting bounding box will always include the [0, 0] point (that is the point-ish bounding box of the empty glyph). [how] If more than one codepoint is to be considered empty glyphs are ignored. But if only one (concrete) codepoint is queried do return the empty (i.e. [0, 0, 0, 0]) bounding box. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why] If we use a ScaleGlyph range (i.e. use the same scaling on a range of glyphs; the scaling is determined by the combined bounding box of all that glyphs), we probably want to shift the glyphs identically as well to preserve relative positions not only sizes of the glyphs within the range. But the data is stored nowhere. [how] Store the 'virtual' bounding box along with the scale. [note] With combined (virtual) bounding box we mean the bounding box that a glyph would have where all the individual glyphs would be stamped over each other without shifting/scaling beforehand. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why] We might want to handle monospaced symbol fonts differently then proportional symbol fonts. Proportional symbol fonts usually have no uniform symbol scaling, while monospaced symbol fonts usually have a well designed placement of the symbols within the cell. [how] Add new member to the dimensions dict. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why] If we define glyph groups in ScaleGlyph we want them to be scaled alike, but they are aligned individually, which makes previously matching pairs looking odd. [how] If we have a combined bounding box stored in a ScaleGlyph range, that box is used to align all symbols in the range identically. If the symbol font is proportinal only the v alignment is synced. If the symbol font is monospaced v and h alignemnts are synced. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why] Man do I hate these indented tables in code. Specifically because they break conciseness of commits if one needs to re-indent unrelated entries. [how] Do it in this separate commit that does not change functionality. [note] Smuggled in unrelated code shift by some lines. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why] This is obviously a complete mess. Firstly it seems the author (me) used the array elements as ranges, which is of course not possible. And them the end has a typo. Sigh. [how] Not consecutive codes must all be given one by one (unfortunately). Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

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

[why] The weather icons have some symbols that have a different bounding box but should nevertheless be scaled alike, because for example one is the outer line of a thermometer and one is the matching stem. [how] Just add a scaleGlyph set. Fixes: #915 Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why] The weather icons have a glyph for degress, a small cirle for up. That gets completely destroyed on scaling to fit. [how] Just add a scaleGlyph set. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why] When creating a non-Mono font the vertical alignment does not observe a possible ScaleGlyph group. Icons that should be far up (like the degree-icon, which is ScaleGlyph-grouped together with a full height symbol) end up centered vertically. [how] When the glyph is not scaled we just do not use the ScaleGlyph. But that data is also needed for just shifting the glyph. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why] Very slender symbols added to a proportional patch end up being at least one mono-width wide, which mixes proportional and monospaces metrics. [how] When we create a proportional font we should a) not try to align them in a (non existing) monocpace cell b) insert the symbols with their own (advance) width Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>

[why] The previous commit is somewhat incomplete in some cases and plain wrong in others (with proportional fonts). Examples: The Heard 0x2665 gets a positive right side bearing, which is unexpected. The commits prevents negative right side bearings but not positive ones. The glyphs with overlap (which are the Powerline ones) like 0xE0B0 and 0xE0B2 end up in wrong sizes. This can especially be seen with the Symbols-Only (non-Mono) font, because that is (secretly) a 'Nerd Font Propo' (--variable-width-glyphs) font. [how] This is kind of a design choice: As with the other patched font variants we ignore existing borders (positive bearings) around the glyph. The previous commit tried to keep them, which seems to be impossible and is inconsistent). Also negative bearings would be ignored (but there are none). The only place where bearings come into play is now when we have overlap. All non-overlap glyphs render without any bearing. If we have overlap we need to a) reduce the width by the overlap b) introduce a negative bearing on the appropriate side First we remove any left side bearing by transforming the glyph to the side, such that the bearing becomes zero. For left-side overlap we additionally transform the glyph by the overlap amount to the left (as usual). This creates the neg. left bearing. For right-side overlap we keep the left bearing to be zero. After correcting the left-side bearing (by transforming) we set the corrected width. That is the width subtracted by the overlap. In the left-aligned case this makes the right-side bearing zero. In the right-aligned case this results in a negative right-side bearing. Note how fontforge handles size and bearing changes: Fontforge handles the width change like this: - Keep existing left_side_bearing - Set width - Calculate and set new right_side_bearing 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>

[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 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] 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] 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] 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] 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] There are several instances of if x is True: This should be written as if x: instead. See PEP 8: https://peps.python.org/pep-0008/#programming-recommendations 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] 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] 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>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix unequal weather icon scale #916

Fix unequal weather icon scale #916

Commits on Jan 4, 2023