Hide Forgot
Description of problem: Using "xft:Terminus:pixelsize=12" for my terminal results in vertically-centered ellipses characters (…). Using "-xos4-terminus-medium-r-normal-*-14-*-*-*-*-*-*-*" also fails whereas "-xos4-terminus-medium-r-normal-*-16-*-*-*-*-*-*-*" works. It used to look fine. Version-Release number of selected component (if applicable): levien-inconsolata-fonts-1.01-9.fc20.noarch ISTR this working not too long ago, but looking at inconcolata's yum history, it might be something else at work here. The 1.01-8 build (installed February) was definitely fine. The 1.01-9 was installed August 6. I'm also seeing Japanese characters rendering as something as other than 2-wide boxes, which I would not expect as new from a simple 1.01 rebuild. What else could affect this?
You mention terminus, but this is filed against inconsolata? Which font are you seeing this in? There's really been 0 change in the inconsolata font. It's the same source since 2009 or so.
Oops...yeah. Wires crossed here. I used Inconsolata for the longest time and moved over to Terminus in March. Anyways, looking for the right package, I see: Feb 24 20:38:49 Updated: terminus-fonts-4.36-4.fc19.noarch Feb 24 20:40:32 Updated: terminus-fonts-console-4.36-4.fc19.noarch Aug 06 23:06:32 Updated: terminus-fonts-4.36-5.fc20.noarch Aug 15 22:21:35 Updated: terminus-fonts-console-4.36-5.fc20.noarch Sep 16 20:59:38 Updated: terminus-fonts-4.38-1.fc21.noarch Sep 16 20:59:39 Updated: terminus-fonts-console-4.38-1.fc21.noarch And the 4.38 update is a plausible time frame. I hope the component change works properly (using JS since the drop down takes aaaages to render).
I just tried "….…." in xterm and gnome-terminal with terminus-fonts-4.38-2.fc20.noarch and have seen no such problem. The dots all lined up. Will try again after the next reboot.
Created attachment 825872 [details] Ellipses with 4.38-2.fc20 This is what I see with 4.38-2.fc20 in urxvt256cc.
I still cannot reproduce the issue. The ellipses in "….…." look good here with terminus-fonts-4.38-2.fc20.noarch rxvt-unicode-9.19-1.fc20.x86_64 rxvt-unicode-256color-9.19-1.fc20.x86_64 when I run $ urxvt -fn xft:Terminus:pixelsize=12 & $ urxvt256c -fn xft:Terminus:pixelsize=12 & $ urxvt256cc -fn xft:Terminus:pixelsize=12 & [3] 10592 unable to connect to the rxvt-unicode daemon: No such file or directory [3]+ Exit 2 urxvt256cc -fn xft:Terminus:pixelsize=12 $ urxvt256cd & rxvt-unicode daemon listening on /home/ndim/.urxvt/urxvtd-infty. $ urxvt256cc -fn xft:Terminus:pixelsize=12 & [5] 12374 $
Ah ha. If the font is set with `-fn`, it looks fine. I have this in my ~/.Xdefaults: URxvt.font: xft:Terminus:pixelsize=12 Is there some weird code path the X resources go through that -fn doesn't (or vice versa)?
I just added an ~/.Xdefaults file and set URxvt.font. Still no shifted ellipses.
Did you run xrdb -merge ~/.Xdefaults to update the resources for the current session? Only new instances after running that will get the new data. I'll try with a fresh user profile when I get the chance.
Yepp. Tried with and without the "xrdb -merge". I'll try a fresh user profile as well.
I'm seeing things are better in Rawhide with: terminus-fonts-4.38-3.fc21.noarch I'll test F20 at work on Monday.
Now it works with terminus-fonts-4.38-2.fc20.noarch… I wonder if the -2 update did work, just that I hadn't restarted X for a while and the bad glyph was cached (never did get around to testing a new session).
Oops. Nope. *Bold* ellipses are fine. Regular ones are still weird.
OK, so I ended up nuking my font caches and it's back to normal (once new machines started showing up as OK, I figured it was cached somewhere). I guess one of the releases had a bad glyph and I just happened to hit the jackpot.