![]() You can also see in that screen shot how the ligature arrows render in the terminal instance look for text= ->. The top half of this shows the ligature enabled version of the font, and the bottom half is the non-ligature version. I've added some debug prints and adjusted the showcase method that you mentioned above and here is a screenshot: I'm no expert on this topic, but did render this font in my browser and saw the correct width, and I opened up the font in fontforge and the ligature appears to be double width, which makes me believe that there is probably some additional special case that could be added to kitty to make this happen there too. I'm testing with the sequence -> but finding that kitty renders this as a single width character rather than the double width ligature that we see with, for example, Fira Code. You'll need to have the operator mono font (not free) to use that repo to generate the ligature enabled version if you want to try to reproduce this issue. I'm trying to use with kitty but am running into a similar sounding issue to this one. Or you can add code to kitty to impose these ligatures on all fonts via a config option. So you can either ask the font designer to create calt based ligatures for these characters - then becomes a ligature containing just the glyph, just like -> becomes a ligature contianing just the arrow glyph. As long as you are careful to only use these characters followed by a space, there should be no issue. What you can do is mark some characters as ligatures, so then they and the next character are rendered together as though they were an actual ligature. The problem is if you override wcwidth for a character then the program running in the terminal will think the character is 1 cell wide, while the cursor in the terminal emulator will move two cells for the character. how many characters does it have? It could be possible to kjust extend the maximum number of ligatures in kitty from 5 to say 9, without too much of a performance hit. What is the largest ligature in your font? i.e. I'd be happy to take a look at this issue and see if I can come up with a solution if you could point me in the right direction (and if this is a feature that you'd like to include in the first place). Where is the glyph scale determined (the code that determines that e.g. ![]() ![]() Based on this I'm guessing that proper monospaced fonts can't have glyphs spanning multiple columns, but kitty still renders most ligatures correctly for non-monospaced fonts. PragmataPro comes in two versions where the version with ligatures is non-monospaced, and the version without ligatures is monospaced. I noticed #179 which states that kitty requires a monospaced font. The ligature renders fine, but is rendered at a reduced size and clipped. While certain ligatures like !=, <= and render just fine, other ligatures and glyphs don't render properly.Īs you can see double-width glyphs (some of the symbols in the statusline) are rendered at 50% of their size. Strings like have ligatures that converts the string into a wide glyph. Some fonts like PragmataPro supports double-width glyphs and ligatures that occupy 5+ columns in the terminal. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |