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
