As mentioned in the fltk.coredev thread on a roadmap for 1.4.0,
we could really use some help with reviewing the Unicode/UTF-8
docs because the two original contributors rokan and oksid are no
longer active here.
Hm, okay, that's bad. :-(
I didn't know enough when I updated the dox to resolve the issues
so please feel free to apply your knowledge to improve the docs at
https://www.fltk.org/doc-1.4/unicode.html and the unicode stuff at
https://www.fltk.org/doc-1.4/todo.html
sigh Yes, the unicode.html is full of outdated or just plain wrong statements. Far to much to mention them all here. Perhaps I should open a separate ticket for that?
There's a big difference between being able to add an accented
character to a string, and dealing with higher level issues of case
comparison, non-latin scripts, etc.
Yes, but is that the business of FLTK? I doubt that.
To remain Fast and Light, where should FLTK draw the line?
That is quite easy:
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
in other words: "Do it right or don't do it at all!" :-)
So the general question is: What does the FLTK users do with (Unicode) strings in FLTK? I'd say:
- using them as string literals for widget labels, button texts etc.
- giving (runtime-variable) strings from somewhere to FLTK (e.g. to display it in a FL_Output)
- taking user's input from FLTK, e.g. FL_Input::value() as opaque string.
These 3 cases should cover >90% of all usecases. Internally FLTK might need more features, e.g. for text rendering or text editing in the Widgets. I don't know whether FLTK delegates that to other rendering/Unicode handling libraries or implemented it by itself.
Unfortunately there are already some API functions that I consider questionable, e.g. {{FL_Input_::index(int i)}}: What shall this be good for? The documentation is unclear and shows that its author mixed up different Unicode terms: "This function returns the UTF-8 character at i as a ucs4 character code."
I wrote done some of the questions and problems related to "Unicode-aware software":
https://roker.spamt.net/unicode/checklist.txt
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
[ Direct Link to Message ] |