bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

win32 bdf unicode display bug(fix)


From: f . vdijk
Subject: win32 bdf unicode display bug(fix)
Date: Wed, 18 Jul 2001 22:29:59 +0200

Hi

this bug concerns the NT port of GNU Emacs:
"GNU Emacs 20.7.1 (i386-*-nt4.0.1381) of Tue Jun 13 2000 on buffy"

I was attempting to edit UTF-8 files using the mule-ucs package and
unicode bdf fonts. (see http://www.cs.uu.nl/~otfried/Mule on how to
set that up)

The problem I encountered was that Unicode characters in the range
(0x80..0xff) are not displayed (not even as a hollow box). The characters
in this range are mostly west-european accented characters
(latin-1). This occurs on the NT port of GNU Emacs; the linux port
behaves as expected. I saw no fixes for this bug on the various lists,
so I had a look into the code.

The bdf fonts are displayed using a function called w32_BDF_TextOut()
in w32bdf.c. This function takes as some of its parameters the number
of bytes a character occupies (the 'dimension': 1 or 2) and a buffer
with those characters. If the dimension is 1, the buffer is expected
to contain only single byte characters; if the dimension is 2, the
buffer is expected to contain only double byte characters. When the
w32_BDF_TextOut() function is called, the dimension is taken from the
dimension of the character set.

Unfortunately, the function that calls w32_BDF_TextOut(), dumpglyphs()
in w32term.c, collapses characters with a 0 MSB (0x0..0xff) to 1
byte. The result is that w32_BDF_TextOut() gets a buffer with a mix of
1 and 2 byte characters, which it can't handle, resulting in the
display problem.

(Note: the characters in the range 0x0..0x7f are displayed correctly,
because the mule-ucs package represents them with the 1 byte ascii
character set instead of a 2 byte unicode character set)

The patch below makes sure that w32_BDF_TextOut() gets what it wants:
2 byte characters if the character set is 2 bytes. There are likely to
be better ways to fix this, but this quickly solves the problem at
hand. Some tests with different mule modes and fonts seem to show that
the fix doesn't cause additional problems.

*** w32term.c.original  Sat May 13 11:14:23 2000
--- w32term.c   Wed Jul 18 21:17:19 2001
***************
*** 988,998 ****
            || (charset != CHARSET_ASCII && charset != charset_latin_iso8859_1))
          {
            /* Convert x_2byte_buffer into a buffer of single byte
!              characters - possibly containing MBCS runs.  */
            bp = x_1byte_buffer;
            for (i = 0; i < len; i++)
              {
!               if (BYTE1 (*(x_2byte_buffer + i)))
                  *bp++ = BYTE1 (*(x_2byte_buffer + i));
                *bp++ = BYTE2 (*(x_2byte_buffer + i));
              }
--- 988,1003 ----
            || (charset != CHARSET_ASCII && charset != charset_latin_iso8859_1))
          {
            /* Convert x_2byte_buffer into a buffer of single byte
!              characters - possibly containing MBCS runs. If a bdf
!              font is used and the character set is 2 bytes, then
!              w32_BDF_TextOut expects 2 byte characters, so don't
!              collapse 2byte characters in that case, even if they
!              have a zero MSB */
!           BOOL bdfwide=font && font->bdf && CHARSET_DIMENSION(charset)==2;
            bp = x_1byte_buffer;
            for (i = 0; i < len; i++)
              {
!               if (bdfwide || BYTE1 (*(x_2byte_buffer + i)))
                  *bp++ = BYTE1 (*(x_2byte_buffer + i));
                *bp++ = BYTE2 (*(x_2byte_buffer + i));
              }




mvrgr frank



reply via email to

[Prev in Thread] Current Thread [Next in Thread]