Created attachment 1647295 [details] emacs -Q frame (resized) Character spacing with Inconsolata is too wide, as shown in the attached screenshot; it shows the Emacs window I get on running `emacs -Q'. Emacs version is 26.3. I think it happened after upgrading `levien-inconsolata-fonts' to version 3.000, but I'm not sure whether it is the font packages' fault because it works correctly in Gedit and LibreOffice.
I can reproduce this issue by installing emacs and `levien-inconsolata-fonts-3.000-1.fc31`, launching `emacs -Q` and evaluate `(set-default-font "Inconsolata")`. I believe this is a regression in levien-inconsolate-fonts, as the issue goes away by downgrading to version 2.012-5.fc31. CC'ing the maintainer of levien-inconsolata-fonts: any idea what could be the issue?
(In reply to dan.cermak from comment #1) > CC'ing the maintainer of levien-inconsolata-fonts: any idea what could be > the issue? No. It's been reported before in bugzilla, but if someone could file it upstream that would be best... https://github.com/googlefonts/Inconsolata/issues I note that it's not all faces that do this... For example I think the condensed ones look fine.
> if someone could file it upstream that would be best... Done. Happy holidays :-) Andrea
(In reply to Andrea from comment #3) > > if someone could file it upstream that would be best... > Done. For the reference, this is it: https://github.com/googlefonts/Inconsolata/issues/42 Does anyone know if this is an issue with the font or with emacs? It looks like the former, but since the font is ok in other applications, I am not 100% sure about that.
My guess is that something is wrong with the font, but I'm not sure. As Emacs uses X resources, could you please post the output of "xrdb -q"? It's probably not related, but it's better to be sure.
> As Emacs uses X resources, could you please post the output of "xrdb -q"? $ xrdb -q Xft.dpi: 115 Xft.antialias: 1 Xft.hinting: 1 Xft.hintstyle: hintslight Xft.rgba: rgb Xcursor.size: 24 Xcursor.theme: Adwaita
You might try to tweak the Xft.*, especially the dpi, and see if it makes any difference. But to me, the settings don't look like anything out of ordinary.
> You might try to tweak the Xft.*, especially the dpi, and see if it makes any difference. I'm sorry but I really don't know what to do. I've been suggested to report this bug to Emacs developers, here's the link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39082
In https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-01/msg00509.html Robert Pluim mentions that using a cairo build and disabling xft fixes this problem. Do you think that it is feasible to turn off xft in the rpm?
I have raised the issue concerning switching to cairo on the openSUSE Bugzilla as well and was informed that the cairo backend is currently not yet stable and it would not be advisable to switch to using it. So that option is off the table.
This seems to be fixed in Fedora 32 with emacs 27.1
Right, Emacs 27.1 should fix many font problems. Also, it's been built with the cairo backend, which is now fully supported by upstream.