> Winding myself through the depths of Unicode and utf8 > encoding, I have
You are in a maze of twisty passages, all exactly alike... > come across "GLib". GLib is part of the GTK toolkit and incorporates > everything that the GUI part of GTK needs to work, but wihich is not > strictly GUI (sounds familiar?). I looked at it too. I can't now remember why I didn't use more of it... I think I was rying for some compatability with the fltk-2 code. > Anyway, GLib contains among many other features all the Unicode > handling routines we need for FLTK1. Sure, most of the stuff is > already implemented in the patch (some code even twice or three > times ;-), Yes - sorry about that. I had tried to move most of the functions to use the fltk-2 versions (presumably from Bill?) as an alternate to the OksiD ones from the 1.1.6 patch. I assumed that would allow the fltk-1 and flkt-2 trees some commonality. But I didn't remove the OksiD stuff, and there was some other "clutter" in there already, so... Hence the current mess. > but GLib IMHO has a cleaner interface. This leaves > me with the following options: > > 1: go strictly with our patch, remove duplicates, and clean up our API This was where I had headed for, using the fltk-2 functions. I never got there. > 2: use the already clean GLib API and hook that up with the > guts from the patch ...interesting... > 3: extract the unicode from GLib and replace code from the > patch (but > GLib is LGPL, FLTK is modified LGPL, so I am unsure if that is OK) ... Sounds like it might be "tricky"... > 4: require GLib and link against it (my least favourite solution) Not immediately keen on this. But... It seems to me that the key thing that might make using Glib (or "emulating" Glib if we can't use it directly) an attractive proposition, is PanGo. Being able to render Unicode glyphs (which is all the patch does) is only the start of the problem. If we actually want to be able to handle text from non-LGC languages, we need a layout engine that knows the language rules. (I'm not writing one of those!) However, there are several options available, and PanGo is a prominent one. But it depends on Glib. But if we have (or emulate) Glib, maybe PanGo will play for us too...? I really am not sure about this at all. Not sure that was any help... -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
