On 30 Sep 2008, at 17:04, Fabien Costantini wrote: > It's a good thing, but as we still support it in 1.3, it should > work as before, even if not supporting utf8. > I'll see what I can do to fix it.
Great. > BTW I would really like to start helping in the utf8 add-on, A good volunteer is worth ten pressed men, they always say! > the only thing is that I'd also like to see someone that is > involved in the current modifications to please update the > READ.fltk118-utf file to explain in it: Actually, I'd rather see that Readme removed - I only wrote it to mark the changes in my 1.1.8 patch, and most of the things it mentions are either in 1.3 now, or added to the STR list, so should not be tracked through this Readme file. > - What is really done in the utf8 modification today > (i.e: we don't fully support it, > like the glyphs variable width placement in the text and so on, I think we are pretty good on basic glyph handling. The layout of basic glyphs pretty much works, and uses the host OS mechanisms where possible. I think that is actually OK. What we don't do is handle composed characters, ligatures, etc. well, nor RTL or (worse) bi-dir text, or basically anything that needs complex text layout to render correctly. We do have mechanisms for rendering RTL text in a widget but, for example, the text_editor widget will not work in RTL mode. I don't see us *ever* putting full complex-text-handling into fltk, actually - for that we would need PanGo or one of the other complex- text-layout engines, and in any case that falls outside the GUI library remit. The other area where we could improve a lot is the handling of alternate Input Methods, e.g. Xim or SCIM on X-windows, and the equivalent (but different) systems on OSX and Windows for inputting languages that don't fit well on a standard keyboard (most CJK languages, many Indian languages, etc... Basically, most of the world population in fact.) > what is the Oksid ...) Oksid, a.k.a. O'ksi'D, a.k.a. Jean-Marc Lienher ( http://oksid.ch ) did the orginal fltk-1.1.6-utf8 patch. > - What are the new inputs/output strings types expected in the > process (we have to deal in fl_font_mac.cxx with UTF8,UTF16, char, > UniChar,...) I think the intent is to handle everything as utf8, at least internally. Pretty much all the OS we support are able to operate with utf8 data, and most have proper utf8 modes now. There was a "fashion" for wide-character modes, but (it seems to me, anyway) that most are slowly coming round to the realisation that utf8 is a more practical solution. (Backwards compatible with most 8- bit character methods, no endianness issues, strict superset of basic ASCII, and so on) and most web things and so forth are heading that way... Anyway, what I'm saying is that we possibly don't need to invest to much in non-utf8 Unicode formats... If we catch all the non-utf8 text at the "edges" of fltk and fix it there, all should be well... For example, the mechanisms for receiving drag'n'drop text can probably convert incoming text into utf8 if it is in some wide-char format, say MBCS or UTF16, and the rest of the code never has to deal with that at all. > The UTF8 format is, from what I see, not complicated at all (at > least it's encoding method), but I currently have difficulties to > understand what is still to be fixed/enhanced in 1.3 The basic stuff is, I think, mostly in place. At least, it works well for me. But my needs are not that complex so... What we do need to do is improve handling for RTL languages, and chase out the bugs. And make it more consistent across platforms - like the "feature" Albrecht has where the (non-utf8) strings render differently on win32 and linux (I think his "clean" utf8 strings are OK on both platforms.) > For now I understand there must be 2 different functionalities: > output an utf8 coded string in a text-related widget (like in the > utf8 demo), input special characters to be encoded internally as > utf8 (keyboard input modifications ?). Indeed. The output stuff is well on its way, but we should be better able to handle RTL or even bi-directional text output (e.g. many right-to-left languages still output numeric strings in left-to-right order, making them quite difficult for us - our basic output widgets have no hope of comprehending that!) This whole area is made more difficult by the different approaches taken by our host OS systems, and the relative maturity (or otherwise) of their mechanisms. OSX is pretty good in this area, both win32 and linux lag behind. For example, XFT on linux can be made to do many of the clever things that OSX does (automatic font substitution for missing glyphs etc) but it requires more effort from us to get it working. The input stuff needs work, we do need to get on top of the various key-composition / dead-key methods, and also be able to handle the external Input Method programs (Xim, Scim, etc, etc.) Generally these comprise of an external app (often part of the OS) the user can use to composite some complex "character" which is then delivered to our app via an input method interface. OksiD had code for making Xim and the win32 input methods work, but I believe it has suffered from "bit- rot"... Also Xim is often replaced by SCIM and other tools on more recent linux boxes, and I don't know how compatible that might be. And I have never even looked at the OSX equivalents. -- Ian _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
