Fix unequal weather icon scale #916
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is not enough, because while the scaling is kept identical within a group, the shifting is not. This will still not match despite same scale factor:
The stem is too high to fit into the outer line. But that is already tackled by because we have the same problem there: #837 (comment) 😬 |
2 tasks
1006281 to
dbc7f17
Compare
|
This required a lot of rework on the Now the combined / virtual bounding box of all symbol glyphs that are in one ScaleGlyph entry is retained. For all glyphs in a ScaleGlyph entry the vertical alignment is the same and based on the virtual bounding box. This solves the issue described above with the thermometer. If all glyphs in the ScaleGlyph have the same advance width they (as a group) are considered 'monospaced', and additionally to the vertical alignment also the horizontal alignemnt is synchronized for them based on the bounding box. |
dbc7f17 to
fbc52d3
Compare
fbc52d3 to
155800f
Compare
|
Rebase on master, force push |
5ead818 to
ce22313
Compare
[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>
47647be to
1e134ca
Compare
|
🤔 .o( This needs a test ) ;) |
|
Ahh, setting up the tests and then using
Showing the degrees-icon moving up to were it belongs |
|
Pffff, what a PR. All tests seem to be okay and this is indeed doing what is intened ;-) |
3 tasks
LNKLEO
pushed a commit
to LNKLEO/Nerd
that referenced
this pull request
Nov 24, 2023
Fix unequal weather icon scale Tests will come in extra PR.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[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
Fixes: #658
Requirements / Checklist
What does this Pull Request (PR) do?
How should this be manually tested?
Any background context you can provide?
What are the relevant tickets (if any)?
Screenshots (if appropriate or helpful)