Draft: Scale powerline glyphs always #967
Closed
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
[why] When a non-Mono font (i.e. `Nerd Font` not `Nerd Font Mono`) is created the goal is to have big (up to 2 cell wide) symbols. But usually you still want to have only one cell wide powerline glyphs, to have them handable. [how] Introduce a new attribute parameter 'single' that means that the (xy in the changed cases) scaling to one cell shall take place even if `-s` is not given. It is ignored if the sourcefont is not monospaced, because we could not scale in that case anyhow (to which cell-size should we scale?). Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why] The overlap into the previous/next character is used to prevent small gaps in colored powerlines. These show up as small colored line and can usually be suppressed by changing the antialiasing method. But for people who can no change the antialiasing the overlap 'covers up' the gap. But this is not relevant if the glyph is just a 'line'. There just isn't any gap that needs covering-up. [note] Also: Add missing RHS-waveform instructions. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why] The vertical overlap has never been a problem (as far as I know). It is maybe good to have some overlap for the terminal emulators that support vertical overlap. On terminals that truncate at the nominal cell border too much overlap looks bad, i.e. the glyphs 'distorted'. If we ever increase the overlap it is most likely be meant to be the left-right overlap. [note] Originally this has been part of commit fecda6a of #780. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
|
This shows the current state for
The 'cell' is the rectangle in the middle. The glyphs are either right or left aligned to the cell border, with some small overlap. Horizontal spacing is untouched. That means that
Some of the right aligned glyphs, like flames, extend rather far into previous 'territory'. |
|
How does this relate to |
|
This is obsoloete / is now part of |
Finii
added a commit
that referenced
this pull request
Jan 12, 2023
[why] The vertical overlap has never been a problem (as far as I know). It is maybe good to have some overlap for the terminal emulators that support vertical overlap. On terminals that truncate at the nominal cell border too much overlap looks bad, i.e. the glyphs 'distorted'. If we ever increase the overlap it is most likely be meant to be the left-right overlap. [note] Originally this has been part of commit fecda6a of #780. [note2] Originally this has been part of PR #967. Although that had a bug 😬 It used max() instead of min() (T_T) Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
2 tasks
Finii
added a commit
that referenced
this pull request
Jan 12, 2023
[why] The vertical overlap has never been a problem (as far as I know). It is maybe good to have some overlap for the terminal emulators that support vertical overlap. On terminals that truncate at the nominal cell border too much overlap looks bad, i.e. the glyphs 'distorted'. If we ever increase the overlap it is most likely be meant to be the left-right overlap. [note] Originally this has been part of commit fecda6a of #780. [note2] Originally this has been part of PR #967. Although that had a bug 😬 It used max() instead of min() (T_T) Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Finii
added a commit
that referenced
this pull request
Jan 12, 2023
[why] The vertical overlap has never been a problem (as far as I know). It is maybe good to have some overlap for the terminal emulators that support vertical overlap. On terminals that truncate at the nominal cell border too much overlap looks bad, i.e. the glyphs 'distorted'. If we ever increase the overlap it is most likely be meant to be the left-right overlap. Note that the glyphs are usually valign='c' and the overlap is distributed half top and half bottom. There are no other valign values implemented (just 'not align' which is ... most likely bad). [note] Originally this has been part of commit fecda6a of #780. [note2] Originally this has been part of PR #967. Although that had a bug 😬 It used max() instead of min() (T_T) Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de> f
LNKLEO
pushed a commit
to LNKLEO/Nerd
that referenced
this pull request
Nov 24, 2023
[why] The vertical overlap has never been a problem (as far as I know). It is maybe good to have some overlap for the terminal emulators that support vertical overlap. On terminals that truncate at the nominal cell border too much overlap looks bad, i.e. the glyphs 'distorted'. If we ever increase the overlap it is most likely be meant to be the left-right overlap. Note that the glyphs are usually valign='c' and the overlap is distributed half top and half bottom. There are no other valign values implemented (just 'not align' which is ... most likely bad). [note] Originally this has been part of commit fecda6a of ryanoasis#780. [note2] Originally this has been part of PR ryanoasis#967. Although that had a bug 😬 It used max() instead of min() (T_T) Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de> f
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.
Description
After this PR the powerline glyphs (well, some of them) will always be scaled down to one cell, as if
-s(--mono) has been supplied. This is only relevant for the non-Mono font variants of course.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)