> I supposed to develop a GUI which render multi language in a single gui > component(for example: in a single Fl_Box label). I am using unicode fonts > to display. Here comes the problem. > > I need to display the hindi word "हिंदी" in a Fl_Box label. That hindi > word gets altered while displaying.
Can you show in what way it gets "altered" here? For example, can you post little PNG images somewhere of what you expect to see, and what you actually get. In that way, we can look at what is happening in more detail. Also, what version of fltk, what host OS, what toolchain, etc... I do not know Hindi, so it is not clear to me what is correct. When I run your code, I do see a label displayed, and it does look a little bit different from the "raw" string I see in my editor, but I do not know if the difference is just because I have different fonts, or if it is the error you are seeing. For what it is worth, I suspect that this is a text compositing issue. Many languages (e.g. Arabic and other Semitic languages, but I think also Indic languages...) render the character glyphs differently depending on which characters they are next to, or where they occur in a word. However, I most cases the canonical value and order of the (UTF-8 encoded) "characters" in the raw source string does not change. So, for complex texts, before rendering the string, you need to composite the string for display - that is, you parse the canonical character order, then create a new string that has the *actual* glyphs you need to display for that word, in this context. FLTK does not do any string compositing for complex texts (it is not a fast and light thing to do) rather we assume that the strings passed to FLTK for rendering will already have been composited correctly (e.g. by using PanGo or ICU to parse the "raw" string into the "display" string.) So, I think that is what is going wrong, and I do not think there is any easy fix for this other than generating the composited versions of the strings for display, by some means, either via ICU... Or if they are fixed label strings that do not change, you can just work them out by hand... SELEX Galileo Ltd 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
