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 --/-/
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.