On 24.10.2010, at 16:33, Duncan Gibson wrote: > /* second attempt: this time in fltk.development */ > > It seems to me that some of the goals of fltk-1.3.x have already been > reached, namely printing support, a Table widget, and doxygen docs. > The last major issue is UTF-8, which dominates the 1.3 Roadmap. > > Can we split UTF-8 support down into slices, and aim for those? > To see whether this even makes sense, I would propose having a new > poll question along the lines of: > > What level of character support do you require from FLTK in the future? > 1. plain ASCII only, so UTF-8 support needed > 2. ASCII plus Western accented characters > 3. simple left-to-right character sets (Greek, Cyrillic...) > 4. simple right-to-left character sets (Arabic, Hebrew...) > 5. complex character sets (Chinese, Japanese, Korean...)
We are beyond 1. and 2. already. 3. is the minimum we must do in UTF8, but 4. should be the goal IMHO. I don't know enough to ever solve 5. as a whole. I would like to suggest a mode of action to get UTF8 support complete. My main issue is not knowing where to start and which places in the source code were already touched. We agreed a long time ago to not introduce a new string type, so here is what we could do: Any parameter that should take a text string should contain utf8 in its name. For example, once we change Fl_Widget(int x, int y, int w, int h, const char *label) and *all* functions that depend on it, we can change the footprint to Fl_Widget(int x, int y, int w, int h, const char *label_utf8) This does not cover return types obviously. This would only be visible in doxygen docs. How about that? - Matthias _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
