On 12.12.2014 00:12, Marc Lehmann wrote: >> My aim is to use extended glyphs in my shell, e.g. "🐍" to indicate the >> current Python version etc. > > I didn't know the snake indicates the current python version, but I don't > see why it shouldn't work unless the font is broken.
The problem is not a broken font, but that wcwidth(3) returns 1 for it and then rxvt-unicode assumes it is too wide! A simple fix for this is to use the glyph's width instead of WCWIDTH in rxvt_font_xft::has_char. Then rxvt-unicode does not assume the glyph to not be there at all in the font, but it will be displayed in a single cell. Would you accept a patch in this regard? diff --git i/src/rxvtfont.C w/src/rxvtfont.C index c56921c..557837b 100644 --- i/src/rxvtfont.C +++ w/src/rxvtfont.C @@ -1341,7 +1341,7 @@ rxvt_font_xft::has_char (unicode_t unicode, const rxvt_fontprop *prop, XftTextExtents32 (term->dpy, f, &ch, 1, &g); int w = g.width - g.x; - int wcw = max (WCWIDTH (unicode), 1); + int wcw = max((w + term->fwidth - term->fwidth/2) / term->fwidth, 1); careful = g.x > 0 || w > prop->width * wcw; That's not optimal, since it will be displayed using its height (for 2 cells), but that can probably be fixed/improved to scale it to the cell's width (making it smaller, but displayed in total). btw: what about using another indicator for "no font provides this char", and "char exists, but we cannot display it"? >> While I could understand that this would still not get accepted, there is >> at least one commit, which might make sense: supporting the space character >> in the builtin rxvt_font_default: >> https://github.com/blueyed/rxvt-unicode/commit/a42453c30b6b8c03d7dbe2330e1270c772b5282b > That would likely slow down urxvt, and I can't parse "[it] is required > when requesting the same font to be used for spaces as with the previous > char" - what does that mean? It is about the "careful" handling / rendering mask: in case careful changes, a redraw is forced, so in the case of "G ", where "G" is a glyph to be 2 cells wide, the "G" is "careful", but the space would not be. Not too sure about that anymore though, so do not spend more time on trying to parse it, if it's not obvious by now.. ;) > To get this whole topic back on track: you do NOT start with a bug (a > broken or unsuitable font) and then modify your editor, your text files > and the terminal - you'd fix the font first. if you use a unicode locale, > you get a font that follows the unicode standard w.r.t. glyph size, > problem solved, no hacks needed at all. You keep on insisting that the font is broken, but it is about the Unicode standard, and the wcwidth(3) function after all. With Unicode 9 emojis have now a defined size of 2 ("Emoji style standardized variation sequences behave as though they were East Asian Wide, regardless of their assigned East_Asian_Width property value."), but libc's (glibc and musl) have not been updated in that regard. So, given an updated or patched wcwidth, urxvt actually considers the Snake to be two cells wide, and everything is nice (assuming that programs use wcwidth(3) also - which is not the case for Vim by default). However, then there is the Private Use Area (see my other mail, "Re: [PATCH] Add space to extent_test_chars to recognize Font Awesome"), where relying on wcwidth(3) as a set of fixed tables just does not work, since it depends on the font being used for that area after all. (I am assuming my interpretation of "Private Use Area" here, which allows to use codepoints from there for things like FontAwesome and Powerline) So I ended up going that route, which I will announce in a separate thread: it is basically about rxvt-unicode providing a shared object to be used with LD_PRELOAD (to inject wcwidth/wcswidth). This makes applications indirectly ask rxvt-unicode about the number of columns needed through a socket. The patch is available https://github.com/exg/rxvt-unicode/compare/master...blueyed:wcwidth-hack, and there is a Arch PKGBUILD for it. But let's keep discussing that to the new thread - just be warned.. ;) Cheers, Daniel.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
