Few `Powerline Extra symbols` in `Caskaydia Cove Regular` are monospaced
PROxZIMA opened this issue ยท 19 comments
Requirements
- I have searched the issues for my issue and found nothing related and/or helpful
- I have searched the FAQ for help
- I have searched the Wiki for help
๐ฏ Subject of the issue
Experienced behavior:
Few Powerline Extra symbols in Caskaydia Cove Regular are monospaced.
v2.3.0 and above releases.
Expected behavior:
CascadiaCode Regular or Caskaydia Cove Nerd Font Complete Regular is non-monospaced font. So the above mentioned symbols should be wider.
v2.3.0-RC and below releases.
Example symbols:
E0C4: ๎E0C5: ๎E0C6: ๎E0C7: ๎E0CC: ๎E0CD: ๎E0CE: ๎E0CF: ๎E0D1: ๎
๐ง Your Setup
- Which font are you using (e.g.
Anonymice Powerline Nerd Font Complete.ttf)?- Caskaydia Cove Nerd Font Complete Regular
- Where did you get the file from (download link, self patched, source downloaded from link...)
- Which terminal emulator are you using (e.g.
iterm2,urxvt,gnome,konsole)?- kitty
- Are you using OS X, Linux or Windows? And which specific version or distribution?
- Arch Linux
โ Screenshots (Optional)
Included above
Thanks for reporting.
This needs some thoughts, but here the list of behaviours, the glyphs you mean are marked
(The problem is that the powerline glyphs need to have some dependable size, so they must be scaled in any case, the question is just ... how)
What is you use-case? Can you describe what you want to do?
In fact I thought if we want to have xy scaling here or just some y scaling, keeping the aspect ratio. Maybe that is better.
But as I said, we do need scaling to get the powerline glyphs up to line height.
These are the glyphs:
While I see the possibility to a maximize Y while keeping pa for the lower set, the big and small squares have the problem that there are matching right-hand-side icons, which are hand to handle for the Nerd Font variant on such scaling and with all the side constraints.
But lets see how to implement something for the lower set
What is your use-case? Can you describe what you want to do?
I am only using the fire symbols but encountered this small difference between Delugia Complete and Caskaydia Cove (as mentioned in adam7/delugia-code#80)
I didn't went through the patching logic yet but I assume the respective symbols needs to be scaled along y whilst preserving their aspect ratio.
The flames are xy scaled (acpect ratio is lost, x and y independently maximized) in a 2-cell length for non-mono (and a 1 cell length of course for --mono). In this way there width is deterministic and it is more easy to use left and right aligned versions together. At least that was my reasoning. Are they ok for you?
The problem with the legos is, that they are so wide, if they are scaled Y wise so big that they fill 'one height', the width will be more than 2 cells, which breaks the 'all glyphs are between 1 and 2 cells wide' promise.
Its a simple change to have the lower symbols (hexagons, legos) scaled preserve-aspect-ratio into a 1 height 2 wide target.
But then they will of course be also preserve-aspect-ration scaled for Mono fonts, which means they are FAR from touching the full line height. Maybe that does not matter. I have never seen an example of someone using them.
Here's an overview
blue: x and y maximized into one cell
green: x and y maximized into 2 cells (if not --mono)
red bar: Maybe people want to have them into one cell, but that looks rather condensed
pink: These scale now preserve-ascpect-ratio into 2 cell (if not --mono)
Mono font:
The legos come out smallish
when we switch from 'pa' to 'xz' just for Mono and the pink icons:
Any ideas and input welcome :-)
Note to self: The small and big squares ... maybe they can be xy2 with an xy-ratio limit set ๐ค
In this way we can make the 1.5 cells wide. Hmm, does pa2 work with xy-ratio? Hmm.
I use Caskaydia Cove as my terminal font and I've also noticed weird sizing issues with the flame glyphs. I wasn't sure if this was a problem with the font or with Windows Terminal's font rendering. This sounds related though.
and in the Windows font settings dialog:
The wideness of the glyphs seems to confuse the font rendering. If I switch to the Complete Mono version it renders fine, but the flame glyphs are mashed into a single char width.
Is this a limitation (or bug) of the font or is it a problem with how it's rendered?
@arpsmack
I do not believe it is the font. I am using Iosevka and have rendering issues with glyphs e0bc: ๎ผ and eb99: ๎พ when using proportional, but not monospace. I was not seeing this in fonts patched with a previous version.
Here is neovim within the Microsoft Terminal, using both the Atlas rendering engine and their original renderer, with Iosevka mono and variable.
What would be the rendering you want/expect?
Both Mono renderings in you image are the same. The triangular powerline divider is rather steep, because it need to go from bottom to top in one width-step. As expected.
In the non-Mono variant it is packed into two cells, like all other icons (for example the warning or light bulp icon in your last line, which is wider than one 'cell'):
The wider symbols are the reason for the non-Mono font.
With the non-Atlas rendering the non-Mono version renders ok as far as I can see - if one expects the powerline divider to be two-cells wide like the other symbols:
On the right hand side of that prompt, what is missing is the blank after the divider. You immediately switch color and so the rest of the divider becomes hidden.
The Atlas engine on the other hand seems to scale down the warning icon, but not the powerline dividers. They are just cut off. Windows Terminal is very 'smart' and handles different codepoints in very different ways. (I prefer dumb terminals, that do not assume anything and just render what is there.) With the non-Atlas rendering it seems to scale the glyph down a tiny bit, which creates a very ugly step ๐
Whatever.
From what I see here and what you say, I assume you would like to have the dividers be just one cell wide, which would render ok in all the situations you show?
I'm not sure which version of the font you are using, unfortunately the screenshot is but off just above.
This is how it looks on my machine with the current release font (2.3.3):
Comparison with you image, where the first flame draws over the e, which it does not in my image:
The flames are 2 cells wide (but occupy only one, like all the other bigger glyphs), so you need a blank after the icon and all looks good:
(Well, not with the font version you are using, because there the flame is even wider than 2 cells).
In Windows Terminal I see the same behavior:
Your comment
Well, you do not want small symbols of Mono.
If the symbols shall be wider than one cell we have two options:
- Just make them wider - but then of course the font is not
monospacedanymore - Keep them one-width wide but let them extrude into the next cell (which must then carry a blank)
See also
@Finii
Thank you for the detailed breakdown.
It makes sense that the glyph would be a single cell in monospace, and potentially 2 in non-mono.
The glyph on the website's cheat-sheet appears like it's intended to be wide, so constraining it to a single cell might not be what users expect in the non-mono variant.
For me personally, either would look fine as long as they're not rendered with the boundary/scaling issue I'm currently seeing. However, if I'm understanding correctly, it seems like those issues have more to do with the Terminal's rendering engines than the font itself, so it may be their problem to fix instead.
Does that sound right?
@Finii
I was almost certainly using a really out of date version of the font. I just upgraded to 2.3.3 and tried again, except this time I added the extra trailing space characters like you suggested.
Works great! Can't believe I didn't think to add extra space characters to pad out the extra wide flames. I apologize for adding noise to the issue.
The cheat sheet actually uses the Nerd Font Mono variant, where all glyphs are equally sized, but unlike 'ordinary' letter fonts the font it uses has a square cell. That makes them look 'wide' in comparison to usual patched fonts that are always taller than wide. On the other had it looks not as wide as the '2 cell width' limit the the other fonts have. So in principle (and that was the idea) it is somewhere in between to represent both.
Well, all terminals render the fonts differently. And which Nerd Font variant works best depends on that.
But there are also our 'design goals'. The different variants try to stick to that and transmogrify the gyphs to best implement the design goal.
For the powerline symbols we have really different rules for each glyph. We can change them that it represents best what people expect. How it comes out is then further different for the different variants, but the rules set the stage. And here we can play and change the general rules for each powerline glyph individually.
For example
# Arrow tips
0xe0b0: {'align': 'l', 'valign': 'c', 'stretch': 'xy', 'params': {'overlap': 0.02, 'xy-ratio': 0.7}},
0xe0b1: {'align': 'l', 'valign': 'c', 'stretch': 'xy', 'params': {'xy-ratio': 0.7}},You see that we want both to be
- left aligned
- vertically centered within the line
- stretched vertically and horizontally to the 'cell' limits
- but their ascpect ratio is limited to 0.7 (has precedence before
xy) - the
x0b0shall overlap the previous glyph by 2 % to avoid an ugly gap
These abstract rules are taken by the font-patcher and depending on variant result in different glyph-implementations.
Whatever... We can decide ... shall the flames be always one cell or allowed to be two cell if possible.
Shall the lego glyphs be distorted (xz scaling) or preserve their aspect ratio pa`? When preserving we can of course never fill the cell in both directions. And so on.
And here is the place to speak up. What would you expect, what do you want, etc. I personally do not use all these fancy icons and so I have no clue what people want ;-) I can just solve the problems technically.
So. There are always rendering problems for wider-than-one-cell glyphs. Nonetheless most people want not-tiny icons and use these font variants. That seems all straight forward. But when it comes to the actual powerline glyphs, this is more complicated because most of them shall also reach up to the whole line spacing. And that is where the problems come. See the differently colored groups in #1106 (comment). This is just what I dreamed up one night. We can change the groups and or their members.
@arpsmack Thanks for the feedback!
And if I read you correctly you would be not happy with flames that are only one cell wide, right?
Or do you not care? I thought they look strange when only one cell wide, but see my precious previous comment, we can change everything ;)
Edit: What for a typo ๐คฃ Gollum: "my preciousssss"
I've always wanted the wider flames just like how they look on the nerd fonts home page. I think the mono ones look bad. I couldn't figure out what I was doing wrong... until now!
Iosevka unpatched has all the 'simpler' powerline glyphs in single cells.
I guess we should also do that.
My verdict would be
- all one cell except
- flames and waveform 2 cells wide
- lego things
pa - hexagons ... I tend to one cell
To be frank, lego and hexagons are probably the least used powerline symbols. So they aren't used in place of Arrow tips or Rounded arcs.
- lego and hexagons -> x scaling, keeping the aspect ratio (Even if they do not scale up to line height? That's still a issue.)
- Flames and waveforms are already in better shape
- Big/small squares -> 2 cell wide or similar to how Flames and waveforms are to be transformed.
v2.3.0-RC font patcher
Lines 662 to 714 in da88bdb
The way these glyphs were designed:
See how flames/waveform/squares/lego/hexagons are 2 cell wide (end to end of the square boundary)
This will 1123 do:
- Make the triangulars 1 cell wide, as for example Iosevka also does.
- Make the Legos 2 cell wide with pa scaling to make them look nicer.
- Make the Hexagons 2 cells wide and keep their aspect ratio if possible.
- Make small and big Squares also 2 cell wide and keep their aspect ratio
of possible.
For the small and big Squares add a tiny bit of border (negative
overlap), because they have no smooth border line over their open and
closed squares, and that might look strange if some touch and some dont.
Opinions? (Maybe post opinions in the PR thread)
This issue has been automatically locked since there has not been any recent activity (i.e. last half year) after it was closed. It helps our maintainers focus on the active issues. If you have found a problem that seems similar, please open a new issue, complete the issue template with all the details necessary to reproduce, and mention this issue as reference.