On 01/08/14 00:40, Paul Moore wrote:
On 31 July 2014 16:05, Paul Moore<[email protected]> wrote:
On 31 July 2014 15:51, Mike Williams<[email protected]> wrote:
Bram's nod AFAIK. I have been using it for the last 18 months and have had
no problems with it. I don't know if anyone else, other than the original
developer, has been using it. Can't see any obvious problem rolling it out
since people have to actively use it at the moment.
Yeah, I guess what I really meant was is there any way to get Bram to
review/approve it? Maybe this thread will remind him about it...
Actually, I also see the rendering bugs referred to in the thread
there. Maybe there's still some work needed on that patch.
On the other hand my proposal of removing use of ETO_IGNORELANGUAGE
seems minimal and works without issues, as far as I can see. So I'd
say implement that for the short term, and the full DirectX patch once
the rendering issues are ironed out (the DirectX rendering is nicer
than the default, so I do think it's worth using).
Paul
Taking a look at your fix, the original comment in the code says:
/* On NT, tell the font renderer not to "help" us with Hebrew and
Arabic
* text. This doesn't work in 9x, so we have to deal with it
manually on
* those systems. */
The documentation under ExtTextOut() for the ETO_IGNORELANGUAGE flag broadly
says it is an "internal system flag" that, if missing, skips glyph
substitution
and could result in no text being output.
However, if you check the documentation for this flag under the Windows
Enhanced
Metafile specification
(http://msdn.microsoft.com/en-us/library/cc231172.aspx),
it says:
"This bit indicates that no special operating system processing for
glyph
placement should be performed on right-to-left strings; that is,
all glyph
positioning SHOULD be taken care of by drawing and state records
in the
metafile"
i.e., as implied by the original comment in the code, there was a
problem with
right-to-left font processing in gViM which caused the flag to be
inserted in
the first place. Like most Windows GDI functions, font processing goes
via the
Enhanced Metafile layer.
The proposed patch may fix glyph replacement but have you broken
right-to-left
display using Hebrew and Arabic fonts? I haven't checked the code but it
appears
gViM may do its own RTL processing which is why this flag was specified.
You should check this as well before declaring your patch "safe".
Cheers,
--
--
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.
