Me: >> Well, so far, for solving the STR-2158 problems at least, I had >> only identified one place where fl_wcwidth() would be needed, and >> seeing as you have to call fl_utf8decode() to get the ucs value >> to pass to fl_wcwidth(), the extra testing is already done in >> fl_utf8decode().
Ian: > Ah. OK. > I was thinking of the general case, of course, where someone might > call fl_wcwidth() directly, and was wanting to be "safe"... > ... > And you are right - we maybe do not want to expose a UCS interface, > but keep all the interfaces utf8. Me: >> [Hmm. Now I look at it, it probably makes sense to simplify this >> code further by also providing an "fl_wcwidth(const char* src)" >> version which does the decoding too.] Ian: > OK - I think I quite like that; it takes the "un-decoded" utf8 and > tells you the glyph width. Seems good. I have implemented this in src/fl_utf.c just in case we ever require access to the CP1252 macros. This is a C file, so I can't overload the name. Therefore, we currently have: int fl_wcwidth_(unsigned int ucs); int fl_wcwidth(const char *src); The first takes "raw" Unicode, and returns -1 for the C0/C1 control characters and DEL. The second version may map C1 control characters (0x80-0x9f) to their CP1252 personae and return their widths instead, depending on the original build options. Anyone wanting to handle the C0 control characters differently, eg to show ^G or \a or \0x07 or even <BEL>, will need to test for these first and handle separately. Anyway, this has been committed and is now live... Cheers Duncan _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev