> On a first test with GrSetGCUseBackground(gc, GR_FALSE); the application > work but not show the symbol (also with unsigned short type).
Then there is second bug with the internal font display where for some reason the clear background triggers an assert in fblin32.c. I can probably debug this (unrelated) bug if you send me your .bdf file and original nano-X .c program. > I have wrote a win32 application starting from mtest.c (see attach) > Both application not draw the symbol 1024 The quickest test I can think of for the next step would be to use convbdf -f to create a .fnt file from your .bdf file, and then comment out the builtin font, and let nano-X/win32 load the .fnt file (using the same code in your application) from disk, and using the tested .fnt file method for displaying unicode fonts. If this works, then we know that the problem is in the builtin font display mechanism. If it still fails, then there is some issue relating to the .bdf file and/or the way we're decoding and indexing the font glyphs. > where I call MwExtTextOut directly but result is the same: symbols from > UTF8 coded file are wrong. but everyone show different > symbol reading from the same file. > Furthermore, I have see that I read 20 char from UTF8 file but only 8 > are showed. Do the nano-X and win32 programs display different text in these cases? You might put some printf() debug statements in the engine/devfont.c::ConvertEncoding (I think that's the function name) which converts to and from all text encodings). We should also take a quick look at the builtin font structure where you specify your builtin .c font: its very important what you use for the "encoding" member. Regards, Greg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
