On 09.09.2008, at 16:12, MacArthur, Ian (SELEX GALILEO, UK) wrote: >> 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.
No reason to apologize. Important thing is that we have a nice foundation. Merging code is much easier than writing from scratch. > 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. Ah, I see. Very interesting. This would open up new possibilities (commonly known as cans of worms ;-). W could emulate the fraction of GLib that we really need for fast and light rendering, but (eventually - no worries yet) allow linking with an original GLib as an option (when our Thailand user base increases significantly...). Thanks, Matthias ---- http://robowerk.com/ _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
