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:
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:
(note that line spacing is indeed a bit different in the screenshot)
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,
> 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
2478├> font->draw (*drawable, xpixel, ypixel, text, count, fore, back);
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
Actually, it was because of null pointer dereference, for "font" being
NULL. Apparently, it is not expected for the preceding code to return
2459│ * Actually do the drawing of the string here
2461│ rxvt_font *font = (*fontset[GET_STYLE (rend)])[GET_FONT (rend)];
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
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
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 :)
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.
Jan's account has been disabled, so I'm closing this out. Jan (or anyone else), feel free to submit patches, though of course it'd be better if you sent them upstream :)