Meant for monospaced fonts ("fast rendering branch"), and after the main tb-issue57 fixes to cell sizing and alignment.
All this is highly dependent on font/size combination used. Modern fonts designed for terminal use ("Monospace" or "DejaVu Sans Mono") do not exhibit the problem.
(UC) Most often, the issue is an incomplete rendering of the "undercurl", such as the one used by SpellBad highlight group.
(UL) Sometime, even the underline decoration, used by the Underline highlight group, is not visible.
(US) Rarely, the underscore (or other low-positioned?) character may not be visible.
(UL) and (US) issues are resolved by ":set linespace=1" (sometimes, :set linespace=2 is needed). This appears to be a problem/design feature of the font (or its metric), and probably the reason why Vim has the 'linespace' option. Qt positions the glyph/decoration where the font tells it to, but parts falling outside the fixed-size cell (i.e. into the next line) do not get rendered or get overdrawn when the next line is drawn.
Examples: no UL: Liberation Mono at sizes <=10 or size 12 or 18, or (my system's) Courier New at sizes other than 14 and 20. Setting linespace=1 resolves the problem, except for Courier New regular style at size 14 or 20, where linespace=2 is needed. no US: in regular style only, Courier New at 8 or 12 pt.
The Courier New that I have installed exhibits a very strange metric (ascend or height or leading values depend on style; where is the baseline then?), which makes this font very atypical.
Undercurl (wavy line decoration): very often rendered incomplete and discontinuous, with only the top visible, so then it appears as a dashed line (at smaller sizes) or a row of "carets" (at larger sizes). Here setting the 'linespace' option to a positive value does not help: the lines spread apart, but the decoration appears clipped exactly as before.
Here Qt itself appears to position and clip the decoration (so as to be always below the baseline, and to not to exceed the design size of the font), and so setting the extra 'linespace' in Vim has no effect on this clipping.
Examples: Free Mono: UC good at 10 and 14pt, at other sizes disconnected/incomplete; Andale Mono: disconnected at 7,8,12, no problem at 9, 10, 11, 14 * Lucida Typewriter: disconnected at 7,8,9, good at 10, 11, 12, 14
Very often, the small sizes have the problem (it appears that Qt would require the font's 'descent' value to be at least 2 to fit the decoration in), but as the examples show, it is not a simple pattern (at larger sizes, Qt attempts to make the decoration larger, so a larger value of descent would be needed?).
The first thing to do would be to check that qvim is not itself setting drawing or clipping rectangles that are too small (or mis-positioned). But if the problem is not in qvim...
- Can this clipping done by Qt be overruled/configured somehow? void QTextLine::setLeadingIncluded ( bool included ) is mentioned in http://doc.qt.nokia.com/4.7-snapshot/qtextline.html#leadingIncluded but the signature and the description do not give much hope this would allow any configurable values
- Should one use a different/more flexible method for rendering the decoration?
- Should a much simpler decoration be used for certain font families to improve within-the-same-font consistency?