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

RE: vim56 - Win32 GUI glitch rendering Italics

Expand Messages
  • Bram Moolenaar
    About the italic drawing problems: This problem already exists for some time. It is similar to when drawing bold characters by overwriting them with a
    Message 1 of 13 , Mar 13 5:50 AM
    • 0 Attachment
      About the italic drawing problems: This problem already exists for some time.
      It is similar to when drawing bold characters by overwriting them with a
      one-pixel offset.

      One thing wasn't mentioned yet: To handle the one-pixel wider bold fonts, the
      GUI code contains some tricks to redraw them properly. This involves finding
      the leftmost character of a sequence of non-blank characters which are bold.
      This is required when the cursor moves over the text. The same could be done
      for italic characters.

      To make this work perfect, we would need to detect whether the italic font
      actually has the problem. Since this might be complicated and perhaps
      inaccurate, we could just do it always for italic text. The performance
      shouldn't be reduced that much (since italics isn't used very often, and
      because mostly strings are redrawn completely already).

      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.

      Note that this trick only works when the character spills over to the cell on
      the right. For a character that spills over to the cell on the left another
      solution should be used (which is probably more complicated). Didn't see this
      problem myself yet anyway.

      > Martin Dalecki wrote:
      >
      > > > - Characters are drawn with a solid background.
      > >
      > > That depedns at least the GTK+ and raw Xlib guis are handling this
      > > differently.
      >
      > But when you draw a new character over an old one, how does the old one get
      > erased? Maybe a rectangle is drawn explicitly first? That's equivalent to
      > drawing with a solid background as far as the issues here are concerned.

      All text is assumed to be drawn with an opaque background. Although at a low
      level a transparent background is sometimes used (e.g. to make characters
      bold).

      > > > - The background drawn is a rectangle which is of "normal" character
      > > > size, even if the character drawn spills over the edge of this.
      > >
      > > There are X11 font's for which this isn't true. Some errorneous ISO8859-2
      > > font was overshooting his own official border (no it wasn't event italic).
      > > The overshoot took place at some diacritical marks.
      >
      > No matter, this could just be counted as normal character overflow, and
      > fixed the same way as for other over-flowing characters (but only if we can
      > tell which ones are at fault of course). Or otherwise, we could always draw
      > the background rectangle ourselves to make sure it can't over-shoot, and
      > then draw the characters with a transparent background.

      Let's please stick to the standard font handling as much as possible. If a
      font is broken, fix the font. Only fix text drawing inside Vim when really
      needed.

      > The pixel snow effect only exists because some characters go beyond their
      > background rectangles.

      Which could also be interpreted that the character cell size was too small.
      We do accept spilling over to the right cell for bold characters, but others
      should not be allowed. Especially spilling over to cells above/below, since
      that could result in redrawing many lines.

      > > > - Can we tell which characters in which fonts are too big, and in
      > > > which directions? You would think so (and I'm sure you can in
      > > > Only if we control the font ourself.
      > > > X, where the problem can also exist), but I seem to remember
      > >
      > > NO in practice you can't tell anything reliable about a particular font
      > > in X11.
      >
      > Although we could use my ugly hack idea of drawing each character into a
      > small bitmap and testing which edges did overflow.

      A font can have many characters. When UTF-8 support has been added, we will
      run into (performance) problems.

      > > > Now, what have I forgotten?
      > >
      > > You just forgot that the easiest way to circumvent all the problems above
      > > is just to provide our own font set.

      The user should still have the possibility to use another font. E.g. for a
      specific language. We can rule out "broken" and proportional fonts, but any
      fixed-witdh font should be usable.

      > Huh? Nothing I suggested was THAT difficult. What I suggest only affects
      > the GUI display code, whereas proportional fonts would require fundamental
      > changes throughout vim. Even the simplest command like "j" would need to be
      > changed, and this is apart from the obvious change in direction of
      > development for vim. All I'm trying to do is fix a bug.

      There is the possibility to use a proportional font in a fixed-width cell.
      The cell would be about the maximum width of all characters. Each character
      would have to be centered in the cell, probably. It won't look nice, but it
      helps when there is no fixed-width font for your language.

      --
      hundred-and-one symptoms of being an internet addict:
      153. You find yourself staring at your "inbox" waiting for new e-mail
      to arrive.

      /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
      \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
    • jason
      howdy .. I ve got a small GUI bug report for Win32 (haven t tested on any other platforms) when using italics .. it s difficult to describe but simple to
      Message 2 of 13 , Mar 14 4:06 PM
      • 0 Attachment
        howdy ..

        I've got a small GUI bug report for Win32 (haven't tested on any other
        platforms) when using italics .. it's difficult to describe but simple
        to reproduce and observe

        Observing the Problem
        ----
        when using an Italic font (which I do for my Comment syntax specifier)
        there is a display problem with the top-right part of certain characters
        when moving the cursor to the right over the characters .. this only
        appears to happen with certain characters .. but that's almost certainly
        because of the structure of the characters themselves .. eg. there's not
        much in the top-right part of the character 'p' .. but a significant
        amount in the character 'd'

        to see it .. write a row of 'd's in an Italic font .. they'll be missing
        the majority of their vertical stroke .. if you cause a refresh of the
        characters then the rendering glitch will be corrected
        ----

        Analysing the Problem
        ----
        when the cursor is in column X it will be redrawing the character in
        that column .. however it redraws the background over the top of any
        part of the character in column X-1 that happens to be overlapping into
        the character space for column X

        I hope I've used the words 'small' and 'glitch' enough to illustrate
        that this is a very low priority bug .. I'm just making this report
        because it's the sort of thing that might not have been noticed
        ----

        Workaround
        ----
        use ^L alot *8^)
        ----

        Comment
        ----
        below is some information that you might want .. but this problem also
        existed in 5.4 .. and probably all Win32 versions allowing Italic fonts

        also .. I've not done a complete ":so bugreport.vim" because I'm sure
        it's not needed for this sort of thing .. there are no settings that
        I've come across that affect it .. nor are there likely to be
        ----

        Version
        ----
        VIM - Vi IMproved 5.6 (2000 Jan 16, compiled Jan 16 2000 16:05:28)
        MS-Windows 32 bit GUI version
        Compiled with (+) or without (-):
        +autocmd +browse ++builtin_terms +byte_offset +cindent +cmdline_compl
        +cmdline_info +comments +cryptv -cscope +dialog_gui +digraphs
        +emacs_tags
        +eval +ex_extra +extra_search +farsi +file_in_path -osfiletype
        +find_in_path
        -hangul_input +insert_expand +langmap +linebreak +lispindent +menu
        +mksession
        +modify_fname +mouse +multi_byte -ole -perl +quickfix -python +rightleft
        +scrollbind +smartindent -sniff +statusline +syntax +tag_binary
        +tag_old_static -tag_any_white -tcl -tgetent +textobjects +title
        +user_commands +visualextra +viminfo +wildignore +wildmenu +writebackup
        -xfontset -xim -xterm_save
        user vimrc file: "$HOME\_vimrc"
        2nd user vimrc file: "$VIM\_vimrc"
        user exrc file: "$HOME\_exrc"
        2nd user exrc file: "$VIM\_exrc"
        user gvimrc file: "$HOME\_gvimrc"
        2nd user gvimrc file: "$VIM\_gvimrc"
        system menu file: "$VIMRUNTIME\menu.vim"
        ----

        OS
        ----
        WindowsNT 4.0 Workstation Service Pack 6.0a on Intel PentiumIII
        ----

        Options
        ----
        .vimrc
        --
        set nocompatible
        behave xterm
        set selectmode=mouse

        set ai
        set bs=2
        set ts=2
        set sw=2
        set ch=2
        se ru
        --

        .gvimrc
        --
        set guifont=Lucida\ Console:h9
        set lines=50
        set columns=100

        if version >= 500
        syntax on
        set mousehide
        endif
        --

        Please Note: "Lucida Console" is a fixed width TrueType font .. but the
        problem also exists with the default "Courier New" (which is the default
        fixed width font) .. the problem also exists with different point
        sizes - I've tried both fonts (Courier New and Lucida Console) at 9, 10
        and 12 point .. same problem
        ----

        Termcap Settings
        ----
        I'm a Windows user .. I'm insulated from such things *8^) .. it's the
        full 32 bit GUI version of Vim
        ----

        Mappings
        ----
        Irrelevant
        ----

        Abbreviations
        ----
        Irrelevant
        ----

        Highlight Groups
        ----
        Irrelevant
        ----

        Variables
        ----
        Irrelevant
        ----

        Machine Type
        ----
        Irrelevant
        ----

        --
        jason -- elephant@... --
      • jason
        followup to bug report with same Subject sorry (not very thorough was I ?) .. also happens with bottom-left of characters like y (in fact in the current font
        Message 3 of 13 , Mar 14 4:48 PM
        • 0 Attachment
          followup to bug report with same Subject

          sorry (not very thorough was I ?) .. also happens with bottom-left of
          characters like 'y' (in fact in the current font that's the only one
          that it happens with) .. but change "X-1" to "X+1" and "right" to "left"
          where appropriate in the original report *8^)

          same problem .. just that I noticed it with 'y' going left as well

          --
          jason -- elephant@... --
        • Vince Negri
          This is already in the todo list. The reason it happens is that Vim squeezes the bold and italic fonts into the same size character cell as the normal font (so
          Message 4 of 13 , Mar 15 12:07 AM
          • 0 Attachment
            This is already in the todo list. The reason it happens is that
            Vim squeezes the bold and italic fonts into the same size
            character cell as the normal font (so that you can use
            bold and italic in a fixed-pitch context), but sometimes
            these fonts are too big for that size cell and overwrite each other.

            The todo entry:

            7 Add an option to disable adding a pixel row for bold and italic
            fonts?
            Same option as for multi-byte (patch from Nam)?
            Add another option to add one to the character width? Lucida
            Console
            italic is wider than the normal font ("d" overlaps with next char).


            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.
          • Marcin Dalecki
            ... Apparently from the source code there slight differences (read: BUGS) in different Win32 implementations with respect to font handling. I doubt any kind of
            Message 5 of 13 , Mar 15 1:02 AM
            • 0 Attachment
              Vince Negri wrote:
              >
              > This is already in the todo list. The reason it happens is that
              > Vim squeezes the bold and italic fonts into the same size
              > character cell as the normal font (so that you can use
              > bold and italic in a fixed-pitch context), but sometimes
              > these fonts are too big for that size cell and overwrite each other.
              >
              > The todo entry:
              >
              > 7 Add an option to disable adding a pixel row for bold and italic
              > fonts?
              > Same option as for multi-byte (patch from Nam)?
              > Add another option to add one to the character width? Lucida
              > Console
              > italic is wider than the normal font ("d" overlaps with next char).

              Apparently from the source code there slight differences (read: BUGS)
              in different Win32 implementations with respect to font handling.
              I doubt any kind of option adding will help. One sould try to hide
              the problem from the user as far as possible. There are aleady far too
              many "twaking" options in Vim.
            • Vince Negri
              ... And Win16, where fixed-pitch TrueType does Strange Things(tm). ... One could always do what Borland used to and supply a specially-created font which
              Message 6 of 13 , Mar 15 1:21 AM
              • 0 Attachment
                > Apparently from the source code there slight differences (read: BUGS)
                > in different Win32 implementations with respect to font handling.
                And Win16, where fixed-pitch TrueType does Strange Things(tm).

                > I doubt any kind of option adding will help. One sould try to hide
                > the problem from the user as far as possible. There are aleady far too
                > many "twaking" options in Vim.

                One could always do what Borland used to and supply a
                specially-created font which doesn't have this problem.


                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.
              • jason
                Vince Negri writes .. ... I don t know what the overhead would be - can t imagine that it would be significant - but wouldn t it be quite easy to require the
                Message 7 of 13 , Mar 15 1:52 PM
                • 0 Attachment
                  Vince Negri writes ..

                  >> I doubt any kind of option adding will help. One sould try to hide
                  >> the problem from the user as far as possible. There are
                  >> aleady far too many "twaking" options in Vim.
                  >
                  >One could always do what Borland used to and supply a
                  >specially-created font which doesn't have this problem.

                  I don't know what the overhead would be - can't imagine that it would be
                  significant - but wouldn't it be quite easy to require the cursor to
                  repaint the character underneath it as well as the two adjacent
                  characters

                  I have no idea about this sort of programming .. so that solution (read:
                  workaround) is probably too simplistic .. it was just a thought

                  btw .. I found two another instances of what appears to be the same bug
                  .. one is simple to reproduce the other - not so

                  print a line of 'd's (in italic font) .. then move a window over the top
                  of the vim window .. the 'd' in rightmost column will lose its head

                  the second situation is more difficult to describe .. let's make up some
                  names first .. the bit of the font that is outside the character cell
                  I'll call "The Overhang" .. the window on top I'll call "The Attacker"
                  and the vim window with the sample text in it I'll call "The Victim"

                  if you place The Attacker in such a way that the border of that window
                  sits directly over The Overhang - but NOT over the rest of the character
                  cell (ie. you can see the normal character cell - but not The Overhang)
                  .. then when you switch back to The Victim then that The Overhang of
                  that character will not be repainted .. but only as much of The Overhang
                  that you covered with The Attacker will be gone

                  I'm sure this makes sense to those in the know .. but without an
                  understanding of how this sort of repainting happens (I'm no great
                  windows event programmer) it's difficult for me to know whether this is
                  caused by the same thing as the other effect or not .. so I'm telling
                  y'all *8^)

                  --
                  jason -- elephant@... --
                • Martin Dalecki
                  ... That depedns at least the GTK+ and raw Xlib guis are handling this differently. ... There are X11 font s for which this isn t true. Some errorneous
                  Message 8 of 13 , Mar 15 5:28 PM
                  • 0 Attachment
                    Robert Webb wrote:
                    >
                    > Vince wrote:
                    >
                    > > This is already in the todo list. The reason it happens is that Vim
                    > > squeezes the bold and italic fonts into the same size character cell
                    > > as the normal font (so that you can use bold and italic in a
                    > > fixed-pitch context), but sometimes these fonts are too big for that
                    > > size cell and overwrite each other.
                    > >
                    > > The todo entry:
                    > >
                    > > 7 Add an option to disable adding a pixel row for bold and
                    > > italic fonts? Same option as for multi-byte (patch from Nam)?
                    > > Add another option to add one to the character width? Lucida
                    > > Console italic is wider than the normal font ("d" overlaps
                    > > with next char).
                    >
                    > Rather than an option, couldn't we try to solve this properly? (And I
                    > don't want an extra pixel in my character width anyway!).
                    >
                    > First, lets review a few points about drawing characters in vim
                    > (correct me if I'm wrong, because I may well be!):
                    >
                    > - Characters are drawn with a solid background.

                    That depedns at least the GTK+ and raw Xlib guis are handling this
                    differently.
                    >
                    > - The background drawn is a rectangle which is of "normal" character
                    > size, even if the character drawn spills over the edge of this.

                    There are X11 font's for which this isn't true. Some errorneous
                    ISO8859-2
                    font was overshooting his own official border (no it wasn't event
                    italic).
                    The overshoot took place at some diacritical marks.

                    > - Can we tell which characters in which fonts are too big, and in
                    > which directions? You would think so (and I'm sure you can in
                    Only if we control the font ourself.

                    > X, where the problem can also exist), but I seem to remember

                    NO in practice you can't tell anything reliable about a particular font
                    in X11.

                    > some talk that you couldn't in win32. If this is the case, you
                    > could always draw each character into a hidden bitmap and then
                    > test the four edges to see whether any pixels were drawn off the
                    > edge (a total hack, but it would work!). So we can assume that
                    > it is possible to tell for a given character of a given font,
                    > which edges it spills over.
                    >
                    > It seems to me there are two problems:
                    >
                    > (1) When a character is too big, drawing an adjacent character
                    > will wipe part of it out.
                    >
                    > (2) When a character is too big, redrawing a different character
                    > over it will leave the over-flowing part from the previous
                    > character. (The "pixel snow" effect).
                    >
                    > Solution(?): In some situations, some characters need to be redrawn,
                    > but with a transparent background, so as not to wipe out bits spilling
                    > over from adjacent characters. This requires each character position
                    > in the window to have a flag which indicates that it needs
                    > "transparent" redrawing. These characters would then be redrawn when
                    > there is an idle moment, ie all other stuff has been redrawn and there
                    > is no further pending input.
                    >
                    > So which characters should be marked for "transparent" redrawing? I
                    > think these are the tests required after drawing some character:
                    >
                    > - If an adjacent character (of which there are four, or can we
                    > spill diagonally too?!) spills on our side, then mark that
                    > character for redraw. (This solves problem (1) above).
                    >
                    > - Consider the previously displayed character. If it was
                    > different from the new character, and it spilt over at least one
                    > edge, then redraw the previous character first in the background
                    > color. This should get rid of it completely, including spilt
                    > bits. Our spilt bits may have over-written adjacent characters
                    > though, so for each adjacent character into which it spilt, mark
                    > that character for redraw. (This solves problem (2) above).
                    >
                    > And of course, when any character is drawn normally, it may un-mark
                    > itself for redraw.
                    >
                    > Now as long as we draw all the marked characters again with a
                    > transparent background, the drawing of those characters shouldn't lead
                    > to us requiring any further marking.
                    >
                    > Now, what have I forgotten?

                    You just forgot that the easiest way to circumvent all the problems
                    above
                    is just to provide our own font set. Unless VIM starts to support
                    proportional fonts you can forget all the above aolutions they are
                    basically
                    requiring as much work as would be needed to just go ahead and implement
                    support for proportional fonts.


                    > I was figuring most of this out as I went, and now I see that there's
                    > a much simpler, but not perfect solution, which should at least solve
                    > the "pixel snow". Instead of drawing characters with a solid
                    > background, draw the previous character first in the background color,
                    > then draw the new character with a transparent background. Possibly
                    > we'd still need to use the solid background anyway (not sure what else
                    > it's hiding). This alone would solve (2), but not (1), so some
                    > characters may appear clipped, but there shouldn't be any stray dots.
                    >
                    > And that's about it from me. I won't get around to implementing any
                    > of this, but others are welcome! Has anyone made it this far down my
                    > email anyway? :-)

                    Yes. Apparently you really never actually tryed to deal in practice
                    with all this kind of problems.

                    >
                    > Rob.

                    --
                    Marcin Dalecki
                  • jason
                    ... Hash: SHA1 Robert Webb wrote .. ... I presume by two problems you mean two issues affecting the solution of the problem of overlapping bits not being
                    Message 9 of 13 , Mar 15 7:46 PM
                    • 0 Attachment
                      -----BEGIN PGP SIGNED MESSAGE-----
                      Hash: SHA1

                      Robert Webb wrote ..

                      >It seems to me there are two problems:
                      >
                      > (1) When a character is too big, drawing an adjacent character
                      > will wipe part of it out.
                      >
                      > (2) When a character is too big, redrawing a different character
                      > over it will leave the over-flowing part from the previous
                      > character. (The "pixel snow" effect).

                      I presume by "two problems" you mean two issues affecting the solution
                      of the problem of overlapping bits not being redrawn for adjacent
                      characters .. because (at least in my vim) there's no existing problem
                      (2) of pixel snow that you describe above

                      drawing an italic '.' over an italic 'd' replaces the entire 'd' -
                      including the part that overhangs the character cell

                      >Solution(?): In some situations, some characters need to be redrawn,
                      >but with a transparent background, so as not to wipe out bits spilling
                      >over from adjacent characters.

                      this poses an immediate problem in my vim because I'm using a block
                      cursor .. and so the background of a character needs to be repainted to
                      make the blinking cursor happen .. and in fact - even with a non-block
                      cursor you could have a similar problem

                      unless I'm misunderstanding what you mean by "transparent background"
                      (which is entirely likely - because I have no experience in this level
                      of programming)

                      it would be a reasonably reliable solution to redrawn half of the
                      adjacent characters during the redraw of the current character .. but I
                      don't know how possible that sort of thing is

                      seems to me that the real solution comes by adjusting the character
                      cell when using italic font .. in reality that's what has happened ..
                      leaving the character cell in 'normal' format relies on an italic font
                      being the same width as a normal font which doesn't seem sensibile

                      if the character cell (and the cursor) were adjusted to the same slope
                      as the italic writing then I imagine that the problem would solve
                      itself .. vim would only repaint what's inside the character cell ..
                      which - now sloped - would include all the current character and none
                      of the adjacent ones

                      > - Consider the previously displayed character. If it was
                      > different from the new character, and it spilt over at least one
                      > edge, then redraw the previous character first in the background
                      > color. This should get rid of it completely, including spilt
                      > bits. Our spilt bits may have over-written adjacent characters
                      > though, so for each adjacent character into which it spilt, mark
                      > that character for redraw. (This solves problem (2) above).

                      problem with that is that an italic sequence of 'dy' produces a
                      loopback situation .. the redrawing of 'd' (at least in italic Lucida
                      Console) wipes out some of 'y' and vice versa

                      - --
                      jason -- elephant@... --

                      -----BEGIN PGP SIGNATURE-----
                      Version: PGP 6.5.1i for non-commercial use <http://www.pgpi.com/>

                      iQA/AwUBOM/MgDYpBpopJvWUEQIkBQCg7+IfwA38u5GF6TeUUFAm8EWqtsoAoKBp
                      AJjcpPvXwXeYx6BFy8hIZ6Yn
                      =t5Qk
                      -----END PGP SIGNATURE-----
                    • Vince Negri
                      ... [Lengthy, ingenious Dedaelian scheme for dealing with character overwrites snipped] It s days like this when I m glad to be writing from inside good old
                      Message 10 of 13 , Mar 16 1:16 AM
                      • 0 Attachment
                        Robert Webb wrote:
                        >
                        [Lengthy, ingenious Dedaelian scheme for dealing with character
                        overwrites snipped]

                        It's days like this when I'm glad to be writing from inside good old
                        cmd.exe.... ;)

                        I hope that before anyone rolls up their sleeves on this, they really
                        think about the design. At present the Win32 GUI routines interpret
                        the terminal strings coming their way quite literally, so they're
                        often drawing single characters in isolation.

                        Looking at other editors which offer bold/italic, (e.g. ME or CW) they
                        don't have this terminal layer to deal with, so their life is easier.
                        However, we can probably still learn from their approach which is more
                        based around a line at a time. That is to say, when a set of 'write
                        string' instructions comes in the program buffers them up until it the
                        updates have moved to a different line (or we reach idle time), then the
                        whole line (including the bits which haven't changed) is zapped and
                        redrawn. That way the program doesn't need to know what characters
                        are overhanging.

                        The approach is similar to my patches for increased text speed in the
                        Dos32 version, although their I was tackling a different problem and
                        so the code isn't transplantable.

                        In a nutshell, whatever solution is employed should be an integrated
                        one, rather than simply layered on top of what's already there and
                        possibly slowing down GUI repaints. Which is not to rubbish Rob's
                        suggestion per se; rather, such an idea if fully worked through should
                        demand that the basic drawing code be optimised around it.

                        As far as character ascenders/descenders being overwritten, that's a
                        case of ignoring the font's metrics at your peril.. :)




                        --
                        Vince Negri (vnegri@...)
                        Application Solutions Ltd. Tel:+44(0)1273-476608 Fax:+44(0)1273-478888
                        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.
                      • Robert Webb
                        ... Rather than an option, couldn t we try to solve this properly? (And I don t want an extra pixel in my character width anyway!). First, lets review a few
                        Message 11 of 13 , Mar 16 3:47 AM
                        • 0 Attachment
                          Vince wrote:

                          > This is already in the todo list. The reason it happens is that Vim
                          > squeezes the bold and italic fonts into the same size character cell
                          > as the normal font (so that you can use bold and italic in a
                          > fixed-pitch context), but sometimes these fonts are too big for that
                          > size cell and overwrite each other.
                          >
                          > The todo entry:
                          >
                          > 7 Add an option to disable adding a pixel row for bold and
                          > italic fonts? Same option as for multi-byte (patch from Nam)?
                          > Add another option to add one to the character width? Lucida
                          > Console italic is wider than the normal font ("d" overlaps
                          > with next char).

                          Rather than an option, couldn't we try to solve this properly? (And I
                          don't want an extra pixel in my character width anyway!).

                          First, lets review a few points about drawing characters in vim
                          (correct me if I'm wrong, because I may well be!):

                          - Characters are drawn with a solid background.

                          - The background drawn is a rectangle which is of "normal" character
                          size, even if the character drawn spills over the edge of this.

                          - Can we tell which characters in which fonts are too big, and in
                          which directions? You would think so (and I'm sure you can in
                          X, where the problem can also exist), but I seem to remember
                          some talk that you couldn't in win32. If this is the case, you
                          could always draw each character into a hidden bitmap and then
                          test the four edges to see whether any pixels were drawn off the
                          edge (a total hack, but it would work!). So we can assume that
                          it is possible to tell for a given character of a given font,
                          which edges it spills over.

                          It seems to me there are two problems:

                          (1) When a character is too big, drawing an adjacent character
                          will wipe part of it out.

                          (2) When a character is too big, redrawing a different character
                          over it will leave the over-flowing part from the previous
                          character. (The "pixel snow" effect).

                          Solution(?): In some situations, some characters need to be redrawn,
                          but with a transparent background, so as not to wipe out bits spilling
                          over from adjacent characters. This requires each character position
                          in the window to have a flag which indicates that it needs
                          "transparent" redrawing. These characters would then be redrawn when
                          there is an idle moment, ie all other stuff has been redrawn and there
                          is no further pending input.

                          So which characters should be marked for "transparent" redrawing? I
                          think these are the tests required after drawing some character:

                          - If an adjacent character (of which there are four, or can we
                          spill diagonally too?!) spills on our side, then mark that
                          character for redraw. (This solves problem (1) above).

                          - Consider the previously displayed character. If it was
                          different from the new character, and it spilt over at least one
                          edge, then redraw the previous character first in the background
                          color. This should get rid of it completely, including spilt
                          bits. Our spilt bits may have over-written adjacent characters
                          though, so for each adjacent character into which it spilt, mark
                          that character for redraw. (This solves problem (2) above).

                          And of course, when any character is drawn normally, it may un-mark
                          itself for redraw.

                          Now as long as we draw all the marked characters again with a
                          transparent background, the drawing of those characters shouldn't lead
                          to us requiring any further marking.

                          Now, what have I forgotten?


                          I was figuring most of this out as I went, and now I see that there's
                          a much simpler, but not perfect solution, which should at least solve
                          the "pixel snow". Instead of drawing characters with a solid
                          background, draw the previous character first in the background color,
                          then draw the new character with a transparent background. Possibly
                          we'd still need to use the solid background anyway (not sure what else
                          it's hiding). This alone would solve (2), but not (1), so some
                          characters may appear clipped, but there shouldn't be any stray dots.

                          And that's about it from me. I won't get around to implementing any
                          of this, but others are welcome! Has anyone made it this far down my
                          email anyway? :-)

                          Rob.
                        • Robert Webb
                          ... But when you draw a new character over an old one, how does the old one get erased? Maybe a rectangle is drawn explicitly first? That s equivalent to
                          Message 12 of 13 , Mar 16 5:17 AM
                          • 0 Attachment
                            Martin Dalecki wrote:

                            > > - Characters are drawn with a solid background.
                            >
                            > That depedns at least the GTK+ and raw Xlib guis are handling this
                            > differently.

                            But when you draw a new character over an old one, how does the old one get
                            erased? Maybe a rectangle is drawn explicitly first? That's equivalent to
                            drawing with a solid background as far as the issues here are concerned.

                            > > - The background drawn is a rectangle which is of "normal" character
                            > > size, even if the character drawn spills over the edge of this.
                            >
                            > There are X11 font's for which this isn't true. Some errorneous
                            > ISO8859-2
                            > font was overshooting his own official border (no it wasn't event
                            > italic).
                            > The overshoot took place at some diacritical marks.

                            No matter, this could just be counted as normal character overflow, and
                            fixed the same way as for other over-flowing characters (but only if we can
                            tell which ones are at fault of course). Or otherwise, we could always draw
                            the background rectangle ourselves to make sure it can't over-shoot, and
                            then draw the characters with a transparent background.

                            The pixel snow effect only exists because some characters go beyond their
                            background rectangles.

                            > > - Can we tell which characters in which fonts are too big, and in
                            > > which directions? You would think so (and I'm sure you can in
                            > > Only if we control the font ourself.
                            > > X, where the problem can also exist), but I seem to remember
                            >
                            > NO in practice you can't tell anything reliable about a particular font
                            > in X11.

                            Although we could use my ugly hack idea of drawing each character into a
                            small bitmap and testing which edges did overflow.

                            > > Now, what have I forgotten?
                            >
                            > You just forgot that the easiest way to circumvent all the problems
                            > above
                            > is just to provide our own font set.

                            Do all users know how to do that? I mean I like the font I use, but bold
                            characters leave pixels around the place. What are you suggesting I do?
                            Use a font editor to edit the characters and make sure they don't overflow?
                            Then some bold letters will look clipped. It's rediculous to suggest that
                            all users of vim should have to either create their own font set or find one
                            that doesn't overflow and use that (although they may not like the look of
                            it). When all users have to perform any task before vim works properly I'd
                            suggest that it's something that needs fixing. (Yeah, not all users will
                            run into the problem anyway, if they're lucky, but most users on Win32 will
                            I think).

                            > Unless VIM starts to support
                            > proportional fonts you can forget all the above aolutions they are
                            > basically
                            > requiring as much work as would be needed to just go ahead and implement
                            > support for proportional fonts.

                            Huh? Nothing I suggested was THAT difficult. What I suggest only affects
                            the GUI display code, whereas proportional fonts would require fundamental
                            changes throughout vim. Even the simplest command like "j" would need to be
                            changed, and this is apart from the obvious change in direction of
                            development for vim. All I'm trying to do is fix a bug.

                            > > Has anyone made it this far down my email anyway? :-)
                            >
                            > Yes. Apparently you really never actually tryed to deal in practice
                            > with all this kind of problems.

                            What a bizarre thing to say. Why wouldn't my solution work? I believe
                            something similar is done in vile in fact. What do you care if we fix a
                            bug?

                            Rob.
                          • Robert Webb
                            ... Actually, the main problem I have is bold characters spilling over to the left. I use set guifont=Courier New:h9:w5 on Win32 gui, and some bold
                            Message 13 of 13 , Mar 20 4:28 AM
                            • 0 Attachment
                              Bram wrote:

                              > Note that this trick only works when the character spills over to
                              > the cell on
                              > the right. For a character that spills over to the cell on the
                              > left another
                              > solution should be used (which is probably more complicated).
                              > Didn't see this problem myself yet anyway.

                              Actually, the main problem I have is bold characters spilling over to the
                              left.
                              I use "set guifont=Courier\ New:h9:w5" on Win32 gui, and some bold
                              characters such as 'b' spill to the left. When doing "cw" with the cursor
                              at the start of a bold word starting with 'b' two pixels get left behind.
                              The worst problem is when dragging a status line up or down between two
                              windows. The windows either side of it generally scroll a bit, and some
                              characters will leave a trail of pixels as they scroll.

                              Is there a similar fix which could work to the left and the right? Note
                              also that my bold font is not displayed using the double drawing technique,
                              but is a separate font that Windows has found to match my normal "Courier
                              New:h9:w5" font.

                              Rob.

                              PS. If it's useful for anyone to see a bitmap of my problem, I can send one.
                            Your message has been successfully submitted and would be delivered to recipients shortly.