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, 2000
    • 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 --/-/
    • 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 2 of 13 , Mar 15, 2000
      • 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 3 of 13 , Mar 15, 2000
        • 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 4 of 13 , Mar 15, 2000
          • 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 5 of 13 , Mar 15, 2000
            • 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 6 of 13 , Mar 15, 2000
              • 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 7 of 13 , Mar 15, 2000
                • 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 8 of 13 , Mar 16, 2000
                  • 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 9 of 13 , Mar 16, 2000
                    • 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 10 of 13 , Mar 16, 2000
                      • 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 11 of 13 , Mar 20, 2000
                        • 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.