Sorry to awake this old thread...there was a newer thread requesting
correct display of unicode chars >= 0x10000, but I can't find it, so I
reply to this. Since this thread is so old, I'm quoting the whole
thread below. Sorry if this offends you in some way ;-)
I can confirm that the Mac OS X versions of vim (carbon gvim and
console vim) display characters outside of the BMP correctly (carbon
vim has some drawing issues, but it has those as well when it displays
BMP double-width characters as well. If we get this going, I could
look into that as well). I can test on win32 and ubuntu (gtk version)
as well if there's interest.
Here's a diff (which is not supposed to become an official
patch! ;-) ) that enables displaying of characters outside of the BMP:
Index: screen.c
===================================================================
--- screen.c (revision 475)
+++ screen.c (working copy)
@@ -2305,9 +2305,9 @@
prev_c = u8c;
#endif
/* Non-BMP character: display as ? or fullwidth ?. */
- if (u8c >= 0x10000)
- ScreenLinesUC[idx] = (cells == 2) ? 0xff1f : (int)'?';
- else
+ //if (u8c >= 0x10000)
+ // ScreenLinesUC[idx] = (cells == 2) ? 0xff1f : (int)'?';
+ //else
ScreenLinesUC[idx] = u8c;
for (i = 0; i < Screen_mco; ++i)
{
@@ -3678,25 +3678,25 @@
if ((mb_l == 1 && c >= 0x80)
|| (mb_l >= 1 && mb_c == 0)
|| (mb_l > 1 && (!vim_isprintc(mb_c)
- || mb_c >= 0x10000)))
+ /* || mb_c >= 0x10000 */)))
{
/*
* Illegal UTF-8 byte: display as <xx>.
* Non-BMP character : display as ? or fullwidth ?.
*/
- if (mb_c < 0x10000)
- {
+ //if (mb_c < 0x10000)
+ //{
transchar_hex(extra, mb_c);
# ifdef FEAT_RIGHTLEFT
if (wp->w_p_rl) /* reverse */
rl_mirror(extra);
# endif
- }
- else if (utf_char2cells(mb_c) != 2)
- STRCPY(extra, "?");
- else
- /* 0xff1f in UTF-8: full-width '?' */
- STRCPY(extra, "\357\274\237");
+ //}
+ //else if (utf_char2cells(mb_c) != 2)
+ // STRCPY(extra, "?");
+ //else
+ // /* 0xff1f in UTF-8: full-width '?' */
+ // STRCPY(extra, "\357\274\237");
p_extra = extra;
c = *p_extra;
@@ -6229,12 +6229,12 @@
u8c = utfc_ptr2char(ptr, u8cc);
mbyte_cells = utf_char2cells(u8c);
/* Non-BMP character: display as ? or fullwidth ?. */
- if (u8c >= 0x10000)
- {
- u8c = (mbyte_cells == 2) ? 0xff1f : (int)'?';
- if (attr == 0)
- attr = hl_attr(HLF_8);
- }
+ //if (u8c >= 0x10000)
+ //{
+ // u8c = (mbyte_cells == 2) ? 0xff1f : (int)'?';
+ // if (attr == 0)
+ // attr = hl_attr(HLF_8);
+ //}
# ifdef FEAT_ARABIC
if (p_arshape && !p_tbidi && ARABIC_CHAR(u8c))
{
On Jul 29, 4:03 pm, Tony Mechelynck <[EMAIL PROTECTED]>
wrote:
> Bram Moolenaar wrote:
> > Tony Mechelynck wrote:
>
> >> Talking of todo lists, is the following item on it?
>
> >> - In the GUI, when using a multi-byte 'encoding' use glyphs for any
> >> codepoints
> >> present in the 'guifont', even for Unicode codepoints above U+FFFF.
>
> >> Rationale: Many CJK codepoints are inplane2 (U+20000 to U+2FFFF).
> >> Representing all of them indiscriminately by double-wide question marks
> >> makes
> >> editing East-Asian text files difficult.
>
> >> Hm... There seems to be something similar at todo.txt (2007-Jul-22) line
> >> 720:
>
> >> 8 When 'encoding' is "utf-8", should use 'guifont' for both normal and
> >> wide
> >> characters to make Asian languages work. Win32 fonts contain both
> >> type of characters.
>
> >> This is already implemented (at least in the GTK2 GUI) for wide and narrow
> >> characters in the BMP (Basic MultilingualPlane, U+0000 to U+FFFF). It
> >> remains
> >> to be implemented for characters outside the BMP. Many TTF fonts installed
> >> on
> >> my Linux system (and which I got from Novell/SuSE but also from various
> >> other
> >> royalty-free sources) include glyphs both inside and outside the BMP, as
> >> can
> >> be seen by displaying the page in Firefox with an appropriate CSS sheet.
> >> The
> >> latest fonts which I installed are particularly complete if not extremely
> >> pretty: "HAN NOM A" and "HAN NOM B", both from
> >>http://sourceforge.net/project/showfiles.php?group_id=153105&package_...
> >> -- I got the tip fromhttp://en.wikipedia.org/wiki/GB18030#Glyphs
>
> > It is very unlikely I will work on this myself. Thus we will have to
> > wait for someone to work on this.
>
> OK. Anyone wants to take up the challenge? I have done some preliminary
> detective work. The problem is in function gui_mch_draw_string() which is
> different for each GUI flavour, as follows, checking for a test on (c >=
> 0x10000). Line numbers below are for the latest (7.1.043) sources.
>
> gui_gtk_x11.c:6064 if >= U+10000, replace by question mark
> gui_mac.c no special handling
> gui_photon.c no special handling
> gui_riscos.c no special handling
> gui_w16.c no special handling
> gui_w32.c:2343 if >= U+10000, convert to UTF-16 surrogate pair
> gui_x11.c:2565 if >= U+10000, replace by question mark (1)
> gui_x11.c:2572 if >= U+10000, replace by question mark (2)
>
> (1) with FEAT_XFONTSET, if current_fontset != NULL
> (2) otherwise
>
> It seems that the Win32 GUI converts UTF-8 to UTF-16 with surrogates (thus, I
> suppose, displaying characters correctly even outside the BMP) and that X11
> GUIs (GTK, and non-GTK-non-Photon) explicitly replace anything outside the BMP
> by a wide question mark (which I call the "faulty" handling). For Mac, Photon,
> RiscOS and W16, either the OS handles it transparently or the problem cannot
> occur (+multi_byte not possible?), I don't know.
>
> I don't feel up to modifying this platform-dependent code, but I hope that
> with the above, someone will be willing. Any takers?
>
> Best regards,
> Tony.
> --
> The temperature of Heaven can be rather accurately computed. Our
> authority is Isaiah 30:26, "Moreover, the light of the Moon shall be as
> the light of the Sun and the light of the Sun shall be sevenfold, as
> the light of seven days." Thus Heaven receives from the Moon as much
> radiation as we do from the Sun, and in addition 7*7 (49) times as much
> as the Earth does from the Sun, or 50 times in all. The light we
> receive from the Moon is one 1/10,000 of the light we receive from the
> Sun, so we can ignore that ... The radiation falling on Heaven will
> heat it to the point where the heat lost by radiation is just equal to
> the heat received by radiation, i.e., Heaven loses 50 times as much
> heat as the Earth by radiation. Using the Stefan-Boltzmann law for
> radiation, (H/E)^4 = 50, where E is the absolute temperature of the
> earth (300K), gives H as 798K (525C). The exact temperature of Hell
> cannot be computed ... [However] Revelations 21:8 says "But the
> fearful, and unbelieving ... shall have their part in the lake which
> burneth with fire and brimstone." A lake of molten brimstone means
> that its temperature must be at or below the boiling point, 444.6C. We
> have, then, that Heaven, at 525C is hotter than Hell at 445C.
> -- From "Applied Optics" vol. 11, A14, 1972
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
