On 17 Apr 2011, at 14:03, Duncan Gibson wrote: > > In all of the discussions about the initial level of UTF-8 and Unicode > support that would be incorporated into FLTK-1.3.x, surrogate pairs > were one of the things that were deliberately excluded. Ironic, no?
Were they? I don't recall that. We claim to be able to handle the whole range up to 0x0010FFFF, and at least on XFT (and I think Xlib) that was true. It was *nearly* true on OSX and not true on Win32. So I'm only trying to make things consistent. It is now almost true everywhere - Manolo has fixed the OSX issues, and I posted a tweak to his fix - I have some issues with text_extents on win32 to beat down, and I think it is done. I think I can make this work, but the mechanism I have coded just looks a bit rubbish (valid results notwithstanding!) > I wonder whether one platform or another is going to require that FLTK > also supports composing characters, or one of the other things that > appeared to be "optional" at the beginning, for implementation later. Composing chars ought to be done via the platform's IME, not via the app, so it should not be our problem - the app should have composed chars delivered from the OS. Well, maybe... That would be nice, anyway... _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
