On 16/04/09 01:57, Kenneth Reid Beesley wrote:
> Problem with rendering Combining Diacritics, using DejaVuSansMono in
> 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.
Any fool can paint a picture, but it takes a wise person to be able to