On 29.03.2008, at 20:46, imm wrote: >> > Also, there's the WinCE port that Mikko_L posted back in June last > year (was it that long ago?) - again, I haven't looked at it, but I > think that "we" (in the wider sense, i.e. somebody, maybe even Mikko > if he's around?) probably should look at it since it *must* have > addressed wide-char issues to get it working at all on WinCE, and > WinCE integration would be a Good Thing in the wider sense anyway.
Yes. I suggest Fl types for strings and individual characters. Currently I have: Fl_String: basically typedef'd to "char*" (UTF-8 encoded unicode), but on WinCE, it would be WCHAR* Fl_Char: a single Unicode character (32-bit), or WCHAR on CE Fl_Shortcut: a Unicode character pls flags for modifier keys (alt, ctrl, etc.) Furthermore, we need to manage fonts Fl_Font: 32 bit index (or "enum", just like it is) into the font table and we need to manage graphics coordinates: Fl_Coord: and this one is tricky! Currently we use 32bit in the interface and 16bit internally. Going 32bit is obvious, but is that sufficient? To look good, text must be positioned at subpixel resolution! Would it make sense then to give all coordinates in "float"? Or even "double"? Or we can continue to differentiate between window coordinates and quick drawing (32 bit integer) and "slow" graphics going through the matrix and text (float). Does that mean we will need two types then: Fl_CoordI and Fl_CoordF? > >> Your latest version is fltk118-utf8-2008-02-24, right? > > Just checking... yes, that seems right. Which means I've missed most > of the recent fixes, e.g. the work Yuri did... Do you want me to > merge that and post a new version, or are you OK for now? Time might > be a bit tricky for me this next two weeks - not that I'm trying to > sway your decision there...! ;-) No need to merge. I will apply the patch by hand andline by line anyways, so I kow the code. > If all we are doing is providing the means to *render* utf-8 encoded > strings (which is what I think we should do, and is what the current > code does), and we do not intend to provide the various layers above > that to actually implement the various language rules, then we are > probably OK... So long as the user composites the utf-8 string > correctly for rendering, and sets the text direction, we can probably > do the right thing. That is all we will be doing, plus allowing for basic Unicode text entry of course. We can not provide a full fledged bidirectional universally language-compatible word processing widget. Matthias ---- http://robowerk.com/ _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
