Hide Forgot
Created attachment 1506226 [details] Comparison of before-after man page rendering (using Inconsolata font), emphasis is mine When I was investigating rvxt-unicode vs powerline-fonts compatibility, I stumbled upon these patches: https://github.com/blueyed/PKGBUILD-rxvt-unicode-wide I did not help in that regard, but actually enabled other things to work properly, most notably display of DocBook-based (I believe) man pages for which it may be significantly more common to contain non-ASCII characters (glyphs) like "Em dash" (U+2014, UTF-8: e2 80 94). See the attached comparison between "before/after new patches applied" that used "man systemd-ask-password" for a reference (the other visual difference is caused by focused/blured window). I've applied these patches from the referenced repo for my experiment: * font-width-fix.patch * line-spacing-fix.patch (note that line spacing is indeed a bit different in the screenshot) * enable-wide-glyphs.patch Rarely (it has always been on "systemctl status <something>" command), I hit a segmentation fault, but that should be tractable (will remember to analyse that next time around). Please consider enabling wide glyphs support so that the man pages render just fine regardless of the characters they use.
re [comment 0]: > Rarely (it has always been on "systemctl status <something>" command), > I hit a segmentation fault, but that should be tractable (will remember > to analyse that next time around). It's actually reliable, and the backtrace has the lower frame corrupted, rest is: > rxvt_term::scr_refresh() (this=this@entry=0x5600ace51660) at screen.C:2478 > rxvt_term::flush() (this=0x5600ace51660) at command.C:1008 > ev_invoke_pending() () at ./../libev/ev.c:3314 > ev_run(int) (flags=flags@entry=0) at ./../libev/ev.c:3717 > main(int, char**) (argc=3, argv=0x7ffd672d8288) at rxvt.C:38 in scr_refresh(): 2477│ else 2478├> font->draw (*drawable, xpixel, ypixel, text, count, fore, back); 2479│ May be caused with the circle point that is in "systemctl status", but "echo ●" doesn't cause this problem alone.
> It's actually reliable, and the backtrace has the lower frame > corrupted Actually, it was because of null pointer dereference, for "font" being NULL. Apparently, it is not expected for the preceding code to return like that: 2458│ /* 2459│ * Actually do the drawing of the string here 2460│ */ 2461│ rxvt_font *font = (*fontset[GET_STYLE (rend)])[GET_FONT (rend)]; 2462│ where the index-like access is actually a C++ overloaded operator, so more investigation would be needed as to why this happens.
... and the workaround is to use 'systemctl --no-pager'. Apparently, this is because of some bad interaction with "less -FRSXMK". Also removing 'R' from implicit SYSTEMD_LESS seems to help (i.e., export SYSTEMD_LESS=FSXMK), but at the cost of degrading the output.
Regarding the stated systemctl problem, it disappears when enable-wide-glyphs.patch is omitted. Good news is that initially illustrated problem with rendering extra characters in the man page doesn't return in that case.
Also this character from powerline-go is not rendered correctly unless rxvt-unicode compiled with font-width-fix.patch (between quote marks): "⚑" (used to denote something git repo related, perhaps number of files affected with uncommitted changes)
Is there a reason upstream does not include these patches? My preference would be to include them there first unless it's impossible for some reason.
No idea, went the easy way, grabbed the patches from the other downstream, my problem went away. Sure, upstream would be an optimum as always, what may be slightly problematic is the authorship/licensing concerns. That might be worked around with figuring out the weak spot from existing patches and fixing the same anew, but IANAL. One would have hoped that the original patch author would push it upstream on his/her own.
I took at closer look at the patches. There are five in total. As far as I can tell, you're asking for these two (but correct me if I'm wrong): - font-width-fix.patch is recommended against by the maintainer of that fork; see https://github.com/blueyed/PKGBUILD-rxvt-unicode-wide/commit/f32975b117205707fc43298fcb0b96b4050b94c9 - line-spacing-fix.patch has no information on where it came from, so we can't include that anyway. The other three: - enable-wide-glyphs.patch was rejected by upstream as well: http://lists.schmorp.de/pipermail/rxvt-unicode/2014q4/002043.html . It also appears to cause a systemd pager bug you mention above. - sgr-mouse-mode.patch came from a random gist and has no authorship info. - add-space-to-extent_test_chars.patch seems to have been rejected by upstream already: http://lists.schmorp.de/pipermail/rxvt-unicode/2016q4/002309.html So some questions for you. 1. Can you restate the problem you're seeing? 2. Does setting "URxvt*letterSpace: -1" on unpatched urxvt fix it? 3. If not, are both font-width-fix and line-spacing-fix required to fix it, or would only one work (and if so, which one)? I'm not comfortable including patches that we can't prove authorship information for. I'd like also to get upstream's opinion on anything we include (and preferably, have them commit it first). This would probably require you (or someone else experiencing the problem) to submit them upstream (or find upstream's comments if they've already been submitted), but we can deal with that when we get there.
Timed out; please reopen if you can answer any of the above.
Ok, I see, I want it, I shall invest some effort here. Currently don't have the capacity for that and it may turn out to be rather long-winded. I am reopening this bug nonetheless, since it can be trivially checked that the same problem as in the attached screenshot comparison is present in rxvt-unicode-9.22-18.fc32.x86_64, it didn't go away. Feel free to reassign it to me if it generates any kind of bad feelings for you. I am going to eventually take a crack on this if nobody beats me to it, rxvt-unicode (its flagship) is my daily driver.
Sounds good. To be clear, I'm not opposed to having this fixed, but I can't take any patches we don't know the copyright on. If you plan to fix it, that's great news :)