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

Re: win32 gvim: font width problem

Expand Messages
  • Muraoka Taro
    I made an experimental patch. Attached will help you. ... Muraoka Taro
    Message 1 of 12 , Feb 2 2:14 AM
    • 0 Attachment
      I made an experimental patch.
      Attached will help you.
      ----
      Muraoka Taro <koron@...>


      > Putty simply ignores the fact that it's double-width and prints it as
      > single-width anyway. This works fine for this particular glyph, since
      > there's nothing actually on the right half.
    • Glenn Maynard
      (Minor: you could drop the charwidth_cache_initialized stuff. Static data is always initted to all 0 unless given otherwise; charwidth_cache[] will be all
      Message 2 of 12 , Feb 2 3:13 AM
      • 0 Attachment
        (Minor: you could drop the charwidth_cache_initialized stuff. Static data
        is always initted to all 0 unless given otherwise; charwidth_cache[] will
        be all null. This is guaranteed by C.)

        On Sat, Feb 02, 2002 at 07:14:51PM +0900, Muraoka Taro wrote:
        > I made an experimental patch.
        > Attached will help you.

        1: I don't think this is a double-width problem anymore. Look at
        http://zewt.org/~glenn/pi.jpg; note that it doesn't realign properly.
        The pi symbol isn't quite double-width, so I suspect it'll still end up
        misaligned. (I havn't tried this yet; it's late and I don't have the
        source handy.)

        2: To operate "correctly", we should always output that character as
        single-width; if the font is off, we should err to Unicode, not the
        font. (That is, this fix may make it behave reasonably, but not
        correctly.) This is a nitpick; I'd be personally willing to accept
        mismatched character widths. (Even though it would, in theory, throw off
        ASCII-formatted textfiles, it's not nearly as much of a problem as, say,
        a terminal emulator mismatched with the underlying system.) You're
        probably more familiar with this issue than I am--are most Japanese
        users willing to accept minor width glitches like this?

        If #1 is incorrect (it may be), then this is probably sufficient; I'm
        not too concerned with #2 (exact text formatting isn't terribly
        important to me, at least in cases this isolated), though as it'd still
        be technically incorrect, I'd at least put #2 down as a low-pri todo.

        Thanks.

        --
        Glenn Maynard
      • Muraoka Taro
        ... I saw that. But I think it is one of Windows BUGS. How point size of font did you use?. It may be 10 or 11. Please try 9 or 12, it should be aligned
        Message 3 of 12 , Feb 2 5:38 AM
        • 0 Attachment
          > 1: I don't think this is a double-width problem anymore. Look at
          > http://zewt.org/~glenn/pi.jpg; note that it doesn't realign properly.
          > The pi symbol isn't quite double-width, so I suspect it'll still end
          > up misaligned. (I havn't tried this yet; it's late and I don't have
          > the source handy.)

          I saw that. But I think it is one of Windows BUGS. How point size of
          font did you use?. It may be 10 or 11. Please try 9 or 12, it should
          be aligned properly. (I think Windows can correctly show fix-width font
          which multiple of 3 points size.)
          ----
          Muraoka Taro <koron@...>
        • Bram Moolenaar
          ... I m glad you made something for this. Does this take into account that Vim can use several fonts at the same time? E.g. for bold and other highlight
          Message 4 of 12 , Feb 2 6:01 AM
          • 0 Attachment
            Muraoka Taro wrote:

            > I made an experimental patch.
            > Attached will help you.

            I'm glad you made something for this.

            Does this take into account that Vim can use several fonts at the same
            time? E.g. for bold and other highlight groups. These fonts should all
            use the same font size, but since this problem is about size differences
            the patch might need to handle wrong sizes anyway.

            --
            hundred-and-one symptoms of being an internet addict:
            159. You get excited whenever discussing your hard drive.

            /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
            ((( Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim )))
            \\\ Help me helping AIDS orphans in Uganda - http://iccf-holland.org ///
          • Muraoka Taro
            I wrote new patch. Please check it. ... From: To: Sent: Sunday, February 03, 2002 5:09 PM Subject: Re: win32 gvim:
            Message 5 of 12 , Feb 3 3:38 AM
            • 0 Attachment
              I wrote new patch.
              Please check it.

              ----- Original Message -----
              From: <KGD03011@...>
              To: <koron@...>
              Sent: Sunday, February 03, 2002 5:09 PM
              Subject: Re: win32 gvim: font width problem

              (snip)
              > But I've noticed these problems:
              >
              > 1. Starting VIM and changing fonts and font sizes is very slow
              > (15 to 30 seconds).

              Try new one. Cache became more clever than before.

              > 2. At font-sizes 26 and 28 with Japanese fonts in utf-8, Vim
              > seems to think that all characters, including kana, CJK etc, are
              > half-width.

              May be fixed. But there is another problem, Windows compress width of
              drawing text when using big size font. As a result of this, some dust
              will be shown.

              > 3. In utf-8, an insertion of text that moves text to near the
              > right margin of the window causes a crash. This does not happen
              > with cp932.

              I can't reproduce this.
              ----
              Muraoka Taro <koron@...>
            Your message has been successfully submitted and would be delivered to recipients shortly.