Height clipping for certain glyphs & underline

[nree]

Related to #60 , the change is step in right direction since it fixes horizontal clipping last character for italics.

Change also introduce this new behavior:

I confirmed undoing change in #60 will not do this, it always will clip. So no different renders. Setting line height to +1.5 (for me) will fix clipping height.

After change in #60 I see there is the possibility can fix height issue without need for line height setting. Problem now is it will revert on subsequent renders (or go back and forth). Setting line height to +1.5 for me will fix this too (no back and forth). But as shown in gif, it can render properly without need for line height.

Not shown is it affects underline too.

[yatli]

it's related to the rendering method: for each target span, first the background is drawn, and then the text is rendered on the background.

The text rendering may span into the next line, but when the next line draws, it is clipped. Thoughts?

[yatli]

after watching your gif for minutes I feel that the upper part of a line is not properly utilized... I'm drawing the glyphs too low?

[yatli]

for "g", the upper part (~30%) of the cell is empty

but then again, the powerline glyphs occupy the full cell height, which means that if we simply offset, it will underflow.

[yatli]

@nree this patch may help: 3a0f08e

[nree]

@yatli no change for me, same behavior. except compile faster (less warnings) 😛

Btw I changed font 'SF Mono' -> 'Cascadia Code', this one doesn't re-render different like in gif above. Default line height and 'g' no issues with vertical clipping. Only issue still is the squiggle underline looks poor / clips.

In SF Mono I can fix issues if I set line height big enough, in Cascadia Code, line height makes no difference on squiggle underline.

Btw if you want to reproduce:

• set guifont=SF\ Mono:h16
• start with default line height
• italic 'g' (i use dracula theme)
• for squiggle underline, i'm using ale , don't know how to manually trigger

[yatli]

Very interesting. What I want to do is described in the comments in RenderText:

    //  h = [padding space 1] + above baseline | below baseline + [padding space 2]

I use FontMetrics.Top for "above baseline" and Bottom for "below baseline". You can think of paddings as 1/2 leading space. So, flipping items around we can calculate the padding, and the baseline.

But actually the equation simply does not hold in the clipping case -- here's some running data logged:

ui: h: 17.142857 bottom: 6.841290, top: -16.205219, total padding: -5.903652

Which means, (top+bottom) is actually bigger than what I measured as line height (???)

[yatli]

Trying proportional projection... Update: not really working, clips either up or down.

[yatli]

@nree should be fixed now