On 31/07/2014 19:30, Paul Moore wrote:
On 31 July 2014 18:51, Mike Williams <[email protected]> wrote:
Actually, I also see the rendering bugs referred to in the thread
there. Maybe there's still some work needed on that patch.
Is this the cut'n'paste issue? Do you have test data? TIA
It looks similar in behaviour (although I have to say I only skimmed
the thread). But it wasn't after a cut and paste. I opened a file with
the following text in it:
unicode_text = u"""Polish: Ą Ł Ż
Chinese: 倀 倁 倂 倃 倄 倅 倆 倇 倈
Musical Notes: ♬ ♫ ♯"""
Thanks for this.
If I remember correctly, I opened the file with the default encoding
and then set enc=utf-8. When I scrolled down to the musical notes
line, the second note was doubled and the rest of the line shifted
along (as if the redraw code lost track of the correct horizontal
position). Moving the cursor along the line with "l" (forcing a
character by character redraw) fixed the display.
I can see this now. All I can say at the moment is that it is ...
complicated.
The problem glyphs are the two beamed musical notes. If your current
font does not have glyphs for them then the DirectX font renderer is
selecting an additional font to provide the glyphs. In our setups these
glyphs appear to be between 1 and 2 cells wide which causes the problems
with the display. There is an interaction between drawing runs of
glyphs and tracking where on the line the next run lies - the initial
display has the glyphs complete but the first double quote is drawn over
so only two appear. Moving the cursor over the glyphs, or refreshing
the display with CTRL-L, updates the display resulting in clipped glyphs
for the musical notes but all the double quotes are now displayed.
gVim does have some affect on all this - the problem occurs when pasting
the text or editing a file with the text with gVim already started.
Starting gVim with the file does not have the problem, that is it shows
clipped glyphs and all double quotes to start with. But that is not
really an excuse.
However, using the DejaVu Sans Mono font, which has the beamed musical
notes, does not have a problem displaying these glyphs.
So the problem is down to the automatic font substitution in the
DicrectX font renderer. At this stage it appears to have its own rules
for font selection and picks one such that for the required cell height
the glyph is between 1 and 2 character cells in width resulting in the
end with clipped glyphs.
And yes this comes down to a more basic question of which font renderer
to use - the older GDI renderer or the newer DirectX? There are pros
and cons for each one, each solving different problems it appears the
other cannot.
If more people can give the DirectX renderer patch a go and see if there
are any other issues then there is a better chance of improving it to be
a viable alternative for those that need or want its benefits.
Mike
--
It's psychosomatic. You need a lobotomy. I'll get a saw.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
