On 28 Sep 2007, at 19:58, matthiasm wrote: > On Sep 28, 2007, at 6:24 PM, imm wrote: > >> In case anyone is still following this thread, here: > > Oh yes, I am following this thread very excitedly. I just have no > time ATM to add anything substantial.
Lack of time I understand! Anyway: It seems a few people are following this, so I thought I'd try and lay out where I think this is going, and how far along I've got. Just to check if that's what people are wanting, etc... If you think there are things we need to address, or we should go in another direction, say so. Initial Objectives: 1: Get fltk-1.1.8 to handle strings encoded as utf8 and display the appropriate glyphs. This seems to be working now on linux, OSX and win32. I don't currently have access to a solaris, hp-ux, cray, etc... for further testing. I don't have much experience with non-LGC languages, so can't say for sure how well it is coping with displaying glyphs from outside the LGC ranges. 2: Add support for display text R-to-L as well as the fltk default L- to-R. This seems to be working. Probably needs optimisations. 3: Some rework and rationalisation of some of the "peculiarities" in the fltk-1.1 API. Not really done anything about this yet... Longer Term Objectives: Simply displaying the glyphs is only a (small) part of the problem of handling Unicode texts. To cope with a broad range of languages we'd really need to look at a complex text layout engine (http:// en.wikipedia.org/wiki/Complex_Text_Layout) of some sort, to cope with ligatures and bi-directional text and etc... Even the "western" languages might benefit from that - e.g. if the CTL finds an "ss" in a German word, it could decide whether it was really two "s" glyphs or one esszett "ß" glyph... or in English "encyclopaedia", but I guess most people are so used to seeing English words written without their ligatures they don't even notice any more! So - should fltk provide a CTL? Or should it simply provide the means to render the glyphs, and leave the user to provide the CTL layer? Frankly, I favour the latter approach (I see this as meaning that the people whose languages benefit from having a CTL will need to write the CTL - but they are also the people best placed to know what is needed.) Others may see this differently? I did briefly look at merging PanGo as a way to provide a well- established CTL for use with fltk. But that looked hard, so I quit. If someone else wants to take a run at that, or at something not derived from GTK (e.g. partly based on ICU http://www.icu- project.org/ or something) then that would be really good. Current Status: - Linux: Build seems to be OK, built with XFT. The non-XFT build is currently broken. I will probably try and fix that, but if someone else wants to fix it first, that'd be good. The state of the XIM support is unknown, I don't have any experience with Input Methods, and may have broken this. Someone who has experience with XIM could maybe test this? Also, should we be switching to SCIM instead under X? - Other Unices? Don't know... If they support XFT, they may be OK, if not... - OSX: Builds with Quartz mode enabled. Works fine but some widgets, notably Fl_Text_Editor, are very slow. Oddly, the slowness seems like it *might* be proportional to the size of the text being edited, so I suspect we are "scanning" more text than is necessary when we come to render the display... This is almost certainly exacerbated by my decision to enable ATSUSetTransientFontMatching() in the OSX build by default. Ideally we need to add a method to make that user selectable at runtime, I think. Also, Input Methods under OSX? Again, help welcomed. It might Just Work? - Win32: Only tested with Msys/mingw on WinXP and Win2K. Works OK. I don't have the tools to modify the various MS and other IDE project files, so these need to be brought up to date. Greg reports that the MS-VS project files are basically broken. Again, help on Input Method stuff is welcomed. Cheers, -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
