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_mac" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
