Loading ...
Sorry, an error occurred while loading the content.
 

RE: (PATCH) RE: vim56 - Win32 GUI glitch rendering Italics

Expand Messages
  • jason king
    Bram Moolenaar writes .. ... don t know what you re doing .. but Vince s patch works for me Win32 GUI Vim56 (the stable user release - I made the changes by
    Message 1 of 5 , Mar 18, 2000
      Bram Moolenaar writes ..

      >Vince Negri wrote:
      >
      >> > If somebody wants to try this out, have a look at
      >> > gui_outstr_nowrap(). Use the "back" argument also for italic text.
      >> > Then check if moving the cursor around no longer removes part of
      >> > the italic characters.
      >>
      >> Yes, this patch does make things a lot better: (Tested on Win32 GUI)
      >> Although for whole lines of italic text, I did see the last character
      >> truncated occasionally.
      >
      >Hmm, I tried this with Lucida Console, italic, size 10, and still see
      >the rightmost pixels of a "d" disappear when the cursor moves over it
      >from left to right. If this doesn't happen for you, I wonder why?

      don't know what you're doing .. but Vince's patch works for me Win32 GUI Vim56
      (the stable user release - I made the changes by hand because the line numbers
      didn't match up) on WinNT4SP6 with both Lucida Console and Courier New .. in
      9, 10 and 12 point fonts

      there are only two situations I can see where the bug still appears (actually
      three - but the third is only for those practising pedantry)

      1) if an overhanging character is the rightmost character on a line then
      placing a window over the top of the vim window (then switching back to vim)
      clips the overhanging part of the rightmost character

      2) characters that overhang to the left have not been fixed (as expected) ..
      like italic 'y' (rarely seen because it requires moving left over the line)

      btw .. thanks to Bram for the suggestion and Vince for the implementation - my
      woes are essentially at an end from this bug

      --
      jason - elephant@... -
    • Vince Negri
      ... left to ... I do see the pixels disappear when the cursor is on top of the d , but when the cursor is moved off it the d is restored to its former
      Message 2 of 5 , Mar 19, 2000
        > Bram Moolenaar wrote:
        > Hmm, I tried this with Lucida Console, italic, size 10, and still see the
        > rightmost pixels of a "d" disappear when the cursor moves over it from
        left to
        > right. If this doesn't happen for you, I wonder why?

        I do see the pixels disappear when the cursor is on top of the 'd',
        but when the cursor is moved off it the 'd' is restored to its former
        glory. Before the patch, the 'd' was permanently knackered.

        I presume this is because when the cursor is on the 'd', the 'd'
        is only drawn within the confines of a normal character cell.


        Vince



        Legal Disclaimer: Any views expressed by the sender of this message are
        not necessarily those of Application Solutions Ltd. Information in this
        e-mail may be confidential and is for the use of the intended recipient
        only, no mistake in transmission is intended to waive or compromise such
        privilege. Please advise the sender if you receive this e-mail by mistake.
      • Vince Negri
        ... Well, it s clear what is happening. When the block-style cursor is on top of the d , the cursor is drawn by drawing the character with cursor colours,
        Message 3 of 5 , Mar 19, 2000
          I wrote:
          > I do see the pixels disappear when the cursor is on top of the 'd',
          > but when the cursor is moved off it the 'd' is restored to its former
          > glory. Before the patch, the 'd' was permanently knackered.

          > I presume this is because when the cursor is on the 'd', the 'd'
          > is only drawn within the confines of a normal character cell.

          Well, it's clear what is happening. When the block-style cursor
          is on top of the 'd', the cursor is drawn by drawing the character
          with cursor colours, which are by default such that cursor fg =
          normal bg.

          Looking at the win32 gui_mch_draw_string, the code draws
          the character cell background itself, then the character is
          drawn transparently. But the character spills out of the character
          cell (this is most clearly seen if you click on another window and
          see the hollow cursor), so when the character is drawn in the
          cursor fg colour (= normal bg) it has the effect of erasing the
          part of the character outside the cursor block.

          To see this, place the block cursor on an italic 'd', and watch
          how the the right-most pixels seem to disappear and reappear
          as the cursor flashes. But then type
          :hi Cursor guifg=red
          and you will see that the right-most pixels _are_ being drawn.
          The trouble is that when the cursor is on an italic character, the
          block cursor doesn't cover the character cell.

          There are various immediate workarounds, e.g. set cursor fg
          to be != normal bg, but a more thorough solution is to
          use the clipping rectangle parameter to ExtTextOut. That's
          what I'm going to try now. Watch this space!


          Vince




          Legal Disclaimer: Any views expressed by the sender of this message are
          not necessarily those of Application Solutions Ltd. Information in this
          e-mail may be confidential and is for the use of the intended recipient
          only, no mistake in transmission is intended to waive or compromise such
          privilege. Please advise the sender if you receive this e-mail by mistake.
        Your message has been successfully submitted and would be delivered to recipients shortly.