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

DejaVu Sans Mono, MacVim, Combining Diacritics

Expand Messages
  • Kenneth Reid Beesley
    Problem with rendering Combining Diacritics, using DejaVuSansMono in MacVim/gvim I use MacVim/gvim with either 1. DejaVuSansMono.ttf , currently 2.29, or 2.
    Message 1 of 3 , Apr 15, 2009
    • 0 Attachment
      Problem with rendering Combining Diacritics, using DejaVuSansMono in
      MacVim/gvim


      I use MacVim/gvim with either

      1. DejaVuSansMono.ttf , currently 2.29, or
      2. BrighamVuSansMono.ttf (my modification of DejaVuSansMono.ttf
      2.22 that I augmented, using FontForge, with Deseret Alphabet glyphs)

      With input sequences involving combining diacritics, and having
      nothing to do with the added Deseret Alphabet glyphs, I somehow have
      better results with BrighamVuSansMono.ttf (based on DejaVuSansMono.ttf
      2.22) than with DejaVuSansMono.ttf 2.29.

      For example, if, using DejaVuSansMono.ttf 2.29, I enter (in MacVim/
      gvim) the sequence

      0 0061 LATIN SMALL LETTER A
      1 0328 COMBINING OGONEK
      2 0301 COMBINING ACUTE ACCENT
      3 0020 SPACE
      4 0061 LATIN SMALL LETTER A
      5 0301 COMBINING ACUTE ACCENT
      6 0328 COMBINING OGONEK
      7 0020 SPACE
      8 000a

      the gvim rendering is garbled. (I should see two instances of 'a'
      with ogonek below and an acute accent above.)
      The 'a's are not displayed, and there are some floating accents.
      Here's a picture of the result in my gvim window:


      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_multibyte" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • James Cloos
      I tested that combination in my terminal (which uses DejaVu Sans Mono, rendered via the bytecode), which was handy. My version of DejaVu as installed is svn
      Message 2 of 3 , Apr 15, 2009
      • 0 Attachment
        I tested that combination in my terminal (which uses DejaVu Sans Mono,
        rendered via the bytecode), which was handy.

        My version of DejaVu as installed is svn revision 2351 of
        2009-03-20T02:27:23.189619Z.

        I tried your example of U+61 with U+328 and U+301 in either order.
        AKA: » ą́ « and » ą́ «.

        When rendering U+301 before U+328 the two accents are centered on the.
        base letter. However, if U+328 precedes U+301, then U+328 is located
        at the right stem; U+301 remains centered. (The vertical placement is
        corrent in both instances.)

        Emacs has the same rendering as urxvt.

        AIUI, the UCS provides no guidance on this, but Unicode says that U+301
        has ccc="230" and U+328 has ccc="202", which means that the cannonical
        order is U+61 U+328 U+301.

        -JimC
        --
        James Cloos <cloos@...> OpenPGP: 1024D/ED7DAEA6

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_multibyte" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Tony Mechelynck
        ... [...] You re spurring me to run some more tests on my version of gvim. I m on Linux with GTK2 gvim, and I don t have BrighamVu Sans Mono installed, but I
        Message 3 of 3 , Apr 17, 2009
        • 0 Attachment
          On 16/04/09 01:57, Kenneth Reid Beesley wrote:
          > Problem with rendering Combining Diacritics, using DejaVuSansMono in
          > MacVim/gvim
          >
          >
          > I use MacVim/gvim with either
          >
          > 1. DejaVuSansMono.ttf , currently 2.29, or
          > 2. BrighamVuSansMono.ttf (my modification of DejaVuSansMono.ttf
          > 2.22 that I augmented, using FontForge, with Deseret Alphabet glyphs)
          >
          > With input sequences involving combining diacritics, and having
          > nothing to do with the added Deseret Alphabet glyphs, I somehow have
          > better results with BrighamVuSansMono.ttf (based on DejaVuSansMono.ttf
          > 2.22) than with DejaVuSansMono.ttf 2.29.
          >
          > For example, if, using DejaVuSansMono.ttf 2.29, I enter (in MacVim/
          > gvim) the sequence
          >
          > 0 0061 LATIN SMALL LETTER A
          > 1 0328 COMBINING OGONEK
          > 2 0301 COMBINING ACUTE ACCENT
          > 3 0020 SPACE
          > 4 0061 LATIN SMALL LETTER A
          > 5 0301 COMBINING ACUTE ACCENT
          > 6 0328 COMBINING OGONEK
          > 7 0020 SPACE
          > 8 000a
          >
          > the gvim rendering is garbled. (I should see two instances of 'a'
          > with ogonek below and an acute accent above.)
          > The 'a's are not displayed, and there are some floating accents.
          > Here's a picture of the result in my gvim window:
          [...]

          You're spurring me to run some more tests on my version of gvim.

          I'm on Linux with GTK2 gvim, and I don't have BrighamVu Sans Mono
          installed, but I have DejaVu Sans Mono and I normally use Bitstream Vera
          Sans Mono (another avatar of DejaVu, I think). I tried your examples
          with a very large font size (20) to avoid any possible errors due to
          incorrectly seeing what was displayed. Also, I added several spaces
          before, between and after the two complex characters so as not to miss
          badly located combiners. I'm not sure which versions of the fonts are
          installed, but gvim is 7.2.148 and GTK2 is 2.14.4.

          Bitstream Vera Sans Mono 20: for both examples the first combining char.
          is correctly located but the second one is one character cell to the
          right of where it ought to be; when moving the block cursor over it by
          one cell at a time, I see the following: with the cursor on the a, the
          ill-placed combiner blinks in opposite phase with it; if I move the
          cursor right from there, that ill-placed combiner disappears, but Ctrl-L
          or focus off-on makes it reappear. Moving the cursor left from the a
          makes the ill-placed combiner stay visible.

          DejaVu Sans Mono 20: the first example is displayed correctly (with
          acute above and ogonek below). The second one has its ogonek correctly
          placed, but the acute is now one cell left of where it ought to be, and
          the visual weirdness described above is reversed: displayed in opposite
          phase when the block cursor blinks atop the a (but this time barely
          visible against the background during the blinking cursor's "on" phase),
          disappears if I move the cursor left from there, reappears by Ctrl-L or
          focus off-on, remains shown if I move the cursor right from there.

          Let's try another font: Courier New 20. Here the second example is
          displayed correctly, the first one has its acute one cell right of where
          it ought to be, same weird interaction with the blinking block cursor as
          the BitStream Vera ogonek.

          And another: Lucida Typewriter 20. Same results as with Bitstream Vera.

          And another: FZFangSong 20 (a Chinese font). Same results again (yes,
          even ogoneks exist in this Chinese font).


          I wonder what makes one character display correctly (for me) in DejaVu,
          the other one in Courier, and neither in the other fonts. I don't think
          it is Vim (though I might be wrong), but is it something in the font, or
          something in the GUI interface (GTK2 in my case)? I don't know.


          Best regards,
          Tony.
          --
          Any fool can paint a picture, but it takes a wise person to be able to
          sell it.

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_multibyte" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        Your message has been successfully submitted and would be delivered to recipients shortly.