Bug 1054223 - underscores are invisible in gvim with Monospace font at 10.5pt with Slight hinting
Summary: underscores are invisible in gvim with Monospace font at 10.5pt with Slight h...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: vim
Version: 22
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-16 13:36 UTC by Joel Uckelman
Modified: 2018-10-11 11:21 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-08 19:23:14 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Joel Uckelman 2014-01-16 13:36:56 UTC
Description of problem:

When running gvim in Cinnamon using the default Monospace font (which I believe is DejaVu Sand Mono) at 10.5pt with Antialiasing set to Rgba and hinting set to Slight, underscores are invisible. I.e., spaces and underscores become indistinguishable. This does not happen if hinting is set to anything other than Slight, if Antialiasing is set to None, or with the font set to 10pt or 11pt.

Unfortunately, I'm finding 10pt too large and 11pt too small, and it's important to be able to see underscores in code. Strangely, with the same font settings, gnome-terminal has no problem displaying underscores.


Version-Release number of selected component (if applicable):

vim-filesystem-7.4.027-2.fc20.x86_64
vim-minimal-7.4.027-2.fc20.x86_64
vim-common-7.4.027-2.fc20.x86_64
vim-X11-7.4.027-2.fc20.x86_64
vim-enhanced-7.4.027-2.fc20.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. Set Antialising to Rgba or Greyscale.
2. Set Hinting to Slight.
3. Set font in gvim to Monospace 10.5pt.

Actual results:

Underscores look like this:         


Expected results:

Underscores look like this: _______

Comment 1 Joel Uckelman 2014-01-16 13:45:11 UTC
It seems like gvim is only getting this wrong with DejaVu Sans Mono. Inconsolata at 10.5pt looks fine.

Comment 2 Fedora End Of Life 2015-05-29 10:32:04 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Fedora End Of Life 2015-06-29 14:30:25 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 4 Joel Uckelman 2015-07-06 19:56:26 UTC
This still occurs with:

vim-common-7.4.640-4.fc22.x86_64
vim-X11-7.4.640-4.fc22.x86_64
vim-minimal-7.4.640-4.fc22.x86_64
vim-filesystem-7.4.640-4.fc22.x86_64
vim-enhanced-7.4.640-4.fc22.x86_64

in Fedora 22.

Comment 5 rmatts 2016-01-02 16:39:00 UTC
This bug is still present on Fedora 23.

It also happens with gedit, it's not limited to gvim.

On gnome-terminal, which is using the same monospace font (Deja Vu Sans Mono, 10.5) the underscore character is show successfully.

Comment 6 Ding-Yi Chen 2016-02-09 01:42:06 UTC
In my case, it only happend in gVim.
Other Gtk2 apps such as gimp do not seem to have this problem.



References

(Maybe the root cause) Autohinting causes glyphs to overflow the bounding box
http://savannah.nongnu.org/bugs/?37182

Workaround that also work-for-me:
http://stackoverflow.com/questions/21964631/gvim-display-underscore-as-space

Comment 7 rmatts 2016-02-13 12:37:28 UTC
The workaround suggested also works for me on gvim: set linespace=2 (or any value greater than 1).

Comment 8 Ding-Yi Chen 2016-02-15 07:33:50 UTC
The other workaround: Use Oxygen Mono instead.

Fedora has oxygen-mono-font.

That font basically have similar characteristic to DejaVu Mono.

Try it with following string "oisl _OIS.015!,"

Comment 9 Karsten Hopp 2016-04-08 19:23:14 UTC
This looks a lot like the autohinting issue mentioned in comment #6. This isn't a bug in gvim, just an unfortunate interaction between font, linespace and autohinting.
I'd suggest to use the workaround in comment #7 if you insist on 10.5pt

Comment 10 Nadav Har'El 2018-10-11 11:21:51 UTC
I still see this bug on Fedora 28. The original report makes it sound like one needs to choose a very specific combination of fonts, sizes, etc., for underscores to be invisible, but the point is that I didn't *choose* anything - I'm just using the default font, default size, etc. The workaround of comment 7 ("set linespace=2") worked, but is ugly. If I choose most font in the edit->select font menu, the underscores also come back. It's just the default "Monospace Regular" font, at any size (I tried the default size 10, and also size 11), which has this problem.

I don't know if to call this a Vim bug per se, but I think it is certainly vim's duty to *avoid* this bug, even if it's in another component - perhaps by picking a different default font.


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