nanogui: Cyrillic font buit-in
Subject:
Re: [nanogui] Cyrillic font buit-in
From:
"Greg Haerr" ####@####.####
Date:
15 May 2008 17:45:25 -0000
Message-Id: <0ed301c8b6b3$e8c1b7f0$6401a8c0@gregnewport>
> 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
