You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
No underscores on ubuntu with no editor preferences #42
That seems to happen with some fonts, typically with specific scaling. At CWI, I use Fedora, where you get exactly the same issue using the default font. Luckily the screen is a bit too highres for my eyes, so I scaled the font up a little and then the problem disappeared. I did some investigation. First I thought it was caused by xpce computing a too small clipping area, but that doesn't seem to be the problem. You find similar complaints from other applications using specific fonts. It is unclear whether the problem is with the font itself or the font rendering.
I don't know a good solution. Possibly we should select a different default font as to avoid this buggy one, but how? The current approach is to be as default as possible: just ask for monospace and hope the system finds a nice one.
I think the above is a lucky shot and will not work for all setups :(
It's suprising that the default default (the one if you have no prefs file) has different behavior than if you just have a file. That's going to lead somebody into confusion when they create a file for other reasons.
Maybe we should file the bug with X or with linux?
I doubt how useful that is. The bug is either in libXft or in the specific font that is selected by default.
If I recall well, this has been reported. Our use case is six layers deep and we probably have to make a minimalistic version.
It's suprising that the default default (the one if you have no prefs file) has different behavior than if you just have a file. That's going to lead somebody into confusion when they create a file for other reasons.
That is probably something we have to sort out ourselves ... Shouldn't be too hard, but I must admit it is not my priority ....
Activity
JanWielemaker commentedon Jun 28, 2016
That seems to happen with some fonts, typically with specific scaling. At CWI, I use Fedora, where you get exactly the same issue using the default font. Luckily the screen is a bit too highres for my eyes, so I scaled the font up a little and then the problem disappeared. I did some investigation. First I thought it was caused by xpce computing a too small clipping area, but that doesn't seem to be the problem. You find similar complaints from other applications using specific fonts. It is unclear whether the problem is with the font itself or the font rendering.
I don't know a good solution. Possibly we should select a different default font as to avoid this buggy one, but how? The current approach is to be as default as possible: just ask for monospace and hope the system finds a nice one.
I think the above is a lucky shot and will not work for all setups :(
Anniepoo commentedon Jun 28, 2016
Maybe we should file the bug with X or with linux?
Anniepoo commentedon Jun 28, 2016
It's suprising that the default default (the one if you have no prefs file) has different behavior than if you just have a file. That's going to lead somebody into confusion when they create a file for other reasons.
JanWielemaker commentedon Jun 28, 2016
I doubt how useful that is. The bug is either in libXft or in the specific font that is selected by default.
If I recall well, this has been reported. Our use case is six layers deep and we probably have to make a minimalistic version.
That is probably something we have to sort out ourselves ... Shouldn't be too hard, but I must admit it is not my priority ....
Anniepoo commentedon Jun 28, 2016
My enthusiasm for tracking it down is also low. 8cD I was just taught when I saw a bug to report it or fix it.