Bug 1650312 - Fix rendering with Inconsolata
Summary: Fix rendering with Inconsolata
Alias: None
Product: Fedora
Classification: Fedora
Component: rxvt-unicode
Version: 33
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Robbie Harwood
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-11-15 19:55 UTC by Jan Pokorný [poki]
Modified: 2020-09-10 20:22 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-09-10 20:22:27 UTC
Type: Bug

Attachments (Terms of Use)
Comparison of before-after man page rendering (using Inconsolata font), emphasis is mine (159.95 KB, image/png)
2018-11-15 19:55 UTC, Jan Pokorný [poki]
no flags Details

Description Jan Pokorný [poki] 2018-11-15 19:55:59 UTC
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:

* 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.

Comment 1 Jan Pokorný [poki] 2018-11-15 23:34:28 UTC
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);

May be caused with the circle point that is in "systemctl status",
but "echo ●" doesn't cause this problem alone.

Comment 2 Jan Pokorný [poki] 2018-11-21 13:07:47 UTC
> 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)];

where the index-like access is actually a C++ overloaded operator, so
more investigation would be needed as to why this happens.

Comment 3 Jan Pokorný [poki] 2018-11-21 13:37:46 UTC
... 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.

Comment 4 Jan Pokorný [poki] 2018-11-29 15:23:51 UTC
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.

Comment 5 Jan Pokorný [poki] 2019-01-07 16:10:46 UTC
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)

Comment 6 Robbie Harwood 2019-10-23 16:37:12 UTC
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.

Comment 7 Jan Pokorný [poki] 2019-10-31 15:10:58 UTC
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.

Comment 8 Robbie Harwood 2019-10-31 16:33:19 UTC
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.

Comment 9 Robbie Harwood 2019-11-20 22:12:49 UTC
Timed out; please reopen if you can answer any of the above.

Comment 10 Jan Pokorný [poki] 2019-11-28 17:27:27 UTC
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.

Comment 11 Robbie Harwood 2019-12-03 19:26:08 UTC
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 :)

Comment 12 Ben Cotton 2020-08-11 13:05:36 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 13 Robbie Harwood 2020-09-10 20:22:27 UTC
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 :)

Note You need to log in before you can comment on or make changes to this bug.