1. equalsraf
  2. vim-qt
  3. Issues
Issue #35 open

problem drawing italic font

equalsraf
repo owner created an issue

^^//[This issue was automatically imported from Google Code(vim-qt#35), some data may have been lost ]//^^

^^//[Import-Original-Author: set...@gmail.com]//^^

What steps will reproduce the problem?

:set guifont=Monaco \12 and displaying italic font

What is the expected output? What do you see instead?

Italic font is not well drawed (some part of character are missing), and a Warning, fake monospace font? is displayed in the console

What version of the product are you using? On what operating system?

ubuntu-oeniric, vim-qt latest version (Wed Nov 16)

Please provide any additional information below.

see the attach file

Comments (9)

  1. equalsraf reporter

    [Import-Original-Author: equals...@gmail.com]

    Sorry I've been busy for the past month, this should have been fixed by now.

    It seems the the italic version of Monaco does not fit inside the cell space, so it gets cropped. I can confirm this also happens on my side with Monaco italic 12. Can you try calling vim with QVIM_DRAW_STRING_SLOW=1? it seems to fix it for me.

    This issue is related to the discussion going on in issue21. The problem is that vim-qt either draws fast but poorly for some fonts(which is your case) or properly but really slow(QVIM_DRAW_STRING_SLOW=1).

    The proposed fix (for all these issues) is in the tb-qimagestring branch, that makes QVIM_DRAW_STRING_SLOW behave a lot faster - the idea would be to make that the default font rendering method, but I've been to busy to properly test this

  2. equalsraf reporter

    [Import-Original-Author: set...@gmail.com]

    it does not solve the problem ( I have also test to use the tb-qimagestring .. I get ugly font with it).

    by the way, if I remove the line 288 from gui_qt.cpp : vimshell->setSlowStringDrawing( true ); and set it to false..

    I get FastDrawing everytime.. and the font is displayed correctly.. (but in the console I get a lot of message like : drawString rect mismatch, this is serious, please poke a developer about this ...)

    so it's still a solution for me.. the font is well displayed :D

  3. equalsraf reporter

    [Import-Original-Author: equals...@gmail.com]

    Now that is odd, if i remove the line some of the letters improve (capitalized W) but other get worse (9,8).

  4. equalsraf reporter

    [Import-Original-Author: equals...@gmail.com]

    Please poke me about this later. Based on latest tests the solution for this is to initialize the char width using the with of italic (or rather bold italic) Monaco instead of the width for the normal font type.

    In more detail:

    1. Monaco is not a real monospace font in the sense the the char width for bold italic and normal fonts is different. This means it always triggers the slow paint path.
    2. When vim loads the font it declares the font width as the width of a capital 'M' for the normal typeface - but when rendering bold/italic the letters get cropper.
    3. Presumably the solution for this is - for the slow paint path - to use the maximum width among the combinations of typefaces.
  5. equalsraf reporter

    Finally some progress on this.

    Some loose pseudocode to determine a reasonable width for non-monospace fonts

    font.setItalic(true)
    font.setBold(true)
    charWidth <= font.width + qAbs(font.leftBearing) + qAbs(font.rightBearing)
    

    Basically we were not considering the left/right bearing. A quick test with Monaco shows that this works, naturally the result is horrible because the font width gets too wide - but this is the only way to properly display italic characters.

    Pending issues:

    • We may have to adjust the width for monospace fonts too, I'm not sure yet. But at least now we know where to look.
    • Hopefully the same method can be used for both monospace and non monospace fonts.
  6. equalsraf reporter

    Pushed a fix for this into the master branch.

    • When the font is non-monospace change the method to determine the font width, adding the font bearing
    • The behaviour for monospace fonts remains unchanged

    I expect some non monospace fonts will now look different, for example Monaco will now look wider. Remember that if you want a font to look good, it needs to be monospace AND have the regular/italic/bold variants available - otherwise it is hard to render them properly.

    Please let me know if you see any issues.

  7. Tomas Pospichal

    The same effect can be exhibited for monospaced fonts, so this issue should not be automatically reduced to the problem of how to define a useful "width" value for non-mono spaced fonts. Those are two separate problems here, in a way, because for monospaced fonts, "fixing" this slight visual problem by increasing the cell width would not be appropriate. Maybe #21 could be considered the "monospaced" problem, and this "non-monospaced", but it is a bit unclear.

    Opening

    <i>
     adff adff
     addd addd
     WWWW
     WWWW WWWW
     MMMM
     MMMM MMMM
    </i>
    

    as html file (with syntax highlighting on) and setting the font to some large-size font (Free Mono 18) will make the same problem visible.

    "drawString rect mismatch" would be up to the difference of 3 with this font on this file. Those three pixel-columns get clipped at the end of word/or line, and that is already visible on medium-resolution screens (for W, d or other letters with long ascenders on the right side of the glyph).

    With the cursor on "W" or "d" (which I believe to be positioned correctly), one can see those pixels that are "outside" the character cell, and that is what "drawString" is complaining about. Seems harmless, except at the end of word/line, where the pixels really get clipped and one can see it at large-enough sizes.

  8. Log in to comment