On 3 August 2014 01:12, Tony Mechelynck <[email protected]> wrote:
> From what I read in the help, the only version of Vim which will try to use
> a glyph from a different font if the font you specified doesn't have the
> required glyph, is gvim with GTK2 GUI, which happens to be a Linux version
> (and maybe a rarely-used Mac+X11 version).
>
> Console Vim has of course no control over the fonts to be used: the terminal
> does it all.
>
> In all other gvim versions, including all Windows versions, you have to
> specify the exact font(s) to be used, except that gvim is clever enough to
> find the italic and/or bold fonts that go with a Regular font you specify.
> There are several options for that.
[Lots more elided]
Thanks for the explanation, but with all due respect, it doesn't seem
unreasonable to me for a user to expect that if they specify a
commonly-used monospace font like Consolas, Lucida Console, or even
Courier New, they should get behaviour that is similar to that of
every other text editor around, which is that characters outside of
the normal range of the font are displayed in a way (presumably using
an alternative substitute font) that makes their form discernable -
not a "no such character" box, but a usable representation. Having sto
set a series of options that require a deep understanding of character
sets and how fonts work should not be needed just to see the contents
of a file to the level of clarity that Notepad can manage.
I understand that Vim does things very differently from other programs
at an internal level to allow (for example) support for R-L character
set handling. And I appreciate that the code in Vim is old, dating
back to Windows 95 and earlier, and as such includes workarounds for
limitations of some very old systems.
But honestly, none of this matters. The simple fact is that Vim should
be able to do (at least) as well as everything else. I don't have an
issue with the fact that there's a problem right now, but I do expect
at least an acknowledgement that this is a bug and that fixes when
offered will be considered.
Neither my patch nor the DirectX one appear to be perfect (mine has
redraw issues when you move the cursor over the high-bit characters).
But it's hard to get motivated to do more work on them if they have to
be perfect (as opposed to just "better than things are now") to be
included.
Furthermore, my patch avoids use of a flag that is explicitly
documented as "System use only" at no preceivable cost that I can see
to cases other than ones that currently don't work. I don't see how to
validate it any better without getting a wider audience trying it out
(which basically means getting it into Vim). The same for the DirectX
patch - it's not going to get bug reports until it's available to the
vast majority of Windows users who *don't* build and patch their own
copy of Vim.
If there's a genuine known regression in my patch, then please can
someone clarify what it is and I'll look at fixing it. But if there
isn't, can someone explain why it's not acceptable. ("It might cause
issues for Chinese users" isn't much help - as far as I can tell, it
won't, but I've no means to prove that without a Chinese userbase for
my patch, and I have no means to get that. Even then, having to prove
that no issues exist is an impossible task.)
To be absolutely clear, here is my proposal formatted as a patch. I've
been using this patch since I posted it, with no issues (beyond the
minor redraw issue I noted above, which I will look into, but which I
do *not* believe is a showstopper).
diff --git a/src/gui_w32.c b/src/gui_w32.c
--- a/src/gui_w32.c
+++ b/src/gui_w32.c
@@ -396,10 +396,6 @@
# define pImmSetConversionStatus ImmSetConversionStatus
#endif
-#ifndef ETO_IGNORELANGUAGE
-# define ETO_IGNORELANGUAGE 0x1000
-#endif
-
/* multi monitor support */
typedef struct _MONITORINFOstruct
{
@@ -2339,12 +2335,6 @@
padding[i] = gui.char_width;
}
- /* 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. */
- if (os_version.dwPlatformId == VER_PLATFORM_WIN32_NT)
- foptions |= ETO_IGNORELANGUAGE;
-
/*
* We have to provide the padding argument because italic and bold versions
* of fixed-width fonts are often one pixel or so wider than their normal
@@ -2462,10 +2452,9 @@
#endif
{
#ifdef FEAT_RIGHTLEFT
- /* If we can't use ETO_IGNORELANGUAGE, we can't tell Windows not to
- * mess up RL text, so we have to draw it character-by-character.
- * Only do this if RL is on, since it's slow. */
- if (curwin->w_p_rl && !(foptions & ETO_IGNORELANGUAGE))
+ /* Windows will mess up RL text, so we have to draw it character by
+ * character. Only do this if RL is on, since it's slow. */
+ if (curwin->w_p_rl)
RevOut(s_hdc, TEXT_X(col), TEXT_Y(row),
foptions, pcliprect, (char *)text, len, padding);
else
Paul.
--
--
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.
