On Fri, Oct 08, 2010 at 01:20:16PM -0400, Jorge Arellano Cid wrote:
On Thu, Oct 07, 2010 at 07:08:31PM +0000, corvid wrote:
Jorge wrote:
I had to use mbrtowc() because for some reason utf8decode() didn't work for me.
I tried:
diff -r 686a69055264 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Thu Oct 07 12:09:37 2010 -0400 +++ b/dw/fltkviewbase.cc Thu Oct 07 12:46:26 2010 -0400 @@ -27,6 +27,7 @@ #include <fltk/events.h> #include <fltk/Cursor.h> #include <fltk/run.h> +#include <fltk/utf.h>
#include <stdio.h> #include <wchar.h> @@ -505,7 +506,7 @@ void FltkWidgetView::drawText (core::sty memset (&st2, '\0', sizeof (mbstate_t)); for (curr = 0; next < len; curr = next) { next = theLayout->nextGlyph(text, curr); - cb = (int)mbrtowc(&wc, text + curr, next - curr, &st1); + wc = utf8decode(text + curr, text + next - 1, &cb); if ((wcu = towupper(wc)) == wc) { /* already uppercase, just draw the character */ setfont(ff->font, ff->size);
@corvid: do you see why?
I think the 'end' is supposed to point to the byte past the end. (If so, that would mean that I have a bug that happens to have no effect where html.cc checks for ideographic chars.)
Yes it works with 'end' pointing to 'next' ;)
BTW, misc.c also uses the utf8decode().
I hesitate on whether to call utf8{de,en}code() directly from fltkviewbase.cc and fltkplatform.cc, or to add an API to the platform.hh, and implement it in layout.cc as nextGlyph(). The first one looks simpler.
It's ok to call it directly. fltkviewbase.cc is fltk-dependent anyway. But we can't call the fltk-based utf8 methods directly from files in dw/ that don't have the fltk prefix. Cheers, Johannes