On 20.04.2010, at 10:08, MacArthur, Ian (SELEX GALILEO, UK) wrote: > Well... I still wonder if we need "src/xutf8/fl_wcwidth.c" at all? > > My preference would be to put that functionality into the existing file > "src/fl_utf.c", which is kind of where I think it belongs anyway... > > In particular, that would mean that the fl_wcwidth() function would be > able to take account of the macros (defined in "src/fl_utf.c") that > define our utf8 error handling policy, in particular ERRORS_TO_CP1252 or > STRICT_RFC3629. > > If we have ERRORS_TO_CP1252 set (it normally *is* set) in "src/fl_utf.c" > then for the code points in the 0x80 to 0x9F range the fl_wcwidth() > function would need to return (+1) whereas at present it will return > (-1), which will not be what we want... > Indications are that there's *a lot* of text out there that claims to be > utf8 but actually uses that C1 control chars range (0x80 to 0x9F) as per > the CP1252 characters, so we probably do want to do this. > > Thoughts?
Sounds good, although I must admit that I didn't look at the sources (lack of time, sorry). Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
