There's lot of good stuff in @RokerHRO statements. I do particularly agree with

Instead to pretend to offer such functionality you should be honest and say: FLTK handles Unicode strings (in UTF-8 encoding) as opaque blobs and left any processing on them to specialized libraries, to avoid wrong assumptions by the users.

However there are exceptions, for instance word wrapping in Fl_Text_Display/Fl_Text_Editor and labels (maybe more). But these should be limited as much as possible. And these features are (maybe, I hope so) documented as being incomplete (e.g. RTL text support).

The (historical) reason why there are such processing functions like fl_utf_strcasecmp() is very likely because the early implementors of the UTF-8 transition tried to keep as much as possible of the old convenience 8-bit string handling functions we had in 1.1. [And of course it's questionable if all these functions had to be in good old FLTK 1.1 in the first place.] They also picked from two different sources and "merged" them together to be able to select the proper ones from alternative functions later, which can IIRC still be deducted from the docs. Unfortunately the necessary cleanup did never take place, probably because none of the (earlier and current) developers had enough knowledge or time to do that job.

Now it would IMHO be a good time to clean up and remove unused and unnecessary functions from FLTK before the release of 1.4.0. I think we all agree that UTF-8 text processing is not the task of FLTK, but as @erco77 wrote it's difficult to decide where to draw the line. And such a cleanup process would likely need a lot of manpower.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.