All (well, anyone who's following this thread, anyway...) There's a new version of the fltk-1.1.8-utf8 port here:
http://www.imm.uklinux.net/fltk/fltk118-utf8-2007-06-23.tar.bz2 This builds and works OK for me on my test platforms of OSX, linux FC5/6 and win32 (XP) so I think it is OK. But... Under the hood, there's a fairly large change here; I'm attempting to unify the disparate Unicode/UTF8 implementations that are in the FLTK2 code and the OksiD fltk-1.1.6 port. None of the utf8/Unicode functions are common between these two variants, although they have equivalent functionality. To allow maximum compatibility for the future, I have decided to use the FLTK2 functions wherever practical (Note: this is no reflection on the OksiD code, I just want to be as compatible as possible with the FLTK2 codebase.) I have modified the code to use the FLTK2 functions now, but the changes were implemented "by hand" and there are some API differences that I may have missed, so it is possible this change has introduced some new bugs... Be on your guard! This change should be transparent to most users - but if you are utilizing the UTF8 functions from the OksiD port directly, you *may* have some porting work to convert to the (similar but subtly different in potentially confusing ways) FLTK2 API... Sorry about that, but I believe it is for the best in the longer term. Also - I have had to rename the FLTK2 functions to be more compliant with the fltk-1.1 style to fit into the FLTK1 "namespace" (as it were) e.g. the function utf8locale() has become fl_utf8locale() etc... None of the function API's are changed, though. This seems sensible to me, and we can provide a simple porting layer to re-map the function names at some point in the future if/when it is required. As usual - comments, test reports, etc., welcome -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
