Little addendum: I just tested nitin's example code on a WinXP box (albeit one with complex text handling enabled, which is *not* the default for LGC Windows systems, though it is enabled by default for Asian systems I think) and it seems to be displaying the text correctly. IIRC the CTL was enabled on this test box to enable it to render Thai scripts, but you get all manner of other CTL support as a side-effect, including support of Indic scripts it would appear...
For those who are following along at home, what's happening here (caution: vague and erroneous generalisations follow!) is that we are passed a string with the characters represented in some canonical order (based on how the sounds form I think) but which is written in a different order (due to typographical rules.) E.g., imagine in a Latin script we had a string with the syllable "ki" in it, and that's the sound it makes, but the typographical rules tell us (they don't of course, but work with me here!) that the "i" should be written before the consonant it modifies, the "k"... I think in this specific case the glyph analogous to the "i" in my example is the one with the big loop above the line, and that loop is meant to reach over the related consonant, the "k" in my example. Now, it appears that on OSX and WinXP(with CTL enabled) the renderer is getting this right for us, with no further intervention. This is unexpected, but I guess probably a good thing? However, on Linux the renderer is printing the glyphs in the canonical order, not the display order, and this is a Bad Thing. It is, however, what I expected fltk would actually do on *all* platforms. Unfortunately it seems that nitin, the OP, is on a Linux system... I guess the best bet is for him to pre-format the strings into display order before rendering - this is what ICU or PanGo can help with, of course, but in this case, if it is just a few simple transpositions, some language-specific hook might be the easier option. I.e. write a little function that scans the passed in string, finds the specific transposition cases and swaps the chars over, before passing the "corrected" string to the renderer for display... I think that should Just Work, but who knows! > > It works perfectly well on OS X. I am sorry that I can't > > say anything for Linux. > > > I just tested this on my Mac, and in a VM running ubuntu 11.04. > > I'm not entirely sure what the correct rendering of the > labels is, but: > > - Under OSX, the text appears to be the same in Mail, Xcode > and in the fltk example when it runs. > > - Under linux, the text appears the same as the above when > viewed in gedit (I don't have kdevelop installed so can't say > how it looks...) but looks different in the fltk example when > it runs. The ordering of the displayed glyphs appears to be > different, though I do not know what would be considered > correct or not, for the two strings indicated in the > comments, whilst the other two strings appear to be OK... > > I'd have to guess that this is a consequence of what I > mentioned in my previous email, that the canonical ordering > of the characters in the string does not match the rendered > order on the display once the string is composited, but > really I am out of my depth here, I do not know any Indic > languages... Gedit uses PanGo for its compositing so > (presumably) gets it right, and I'd assume the Apple > applications also get it right (they use ICU under the > covers, I think?) > > Why the fltk app appears correct on OSX I am not sure - it > may be that the Apple text renderer under Quartz is "fixing" > things for us, which I find unexpected. > > I do not know. > > OK - I just fed the string "उपस्थिति" into Packetizer.com as > you suggested, and it displays the individual glyphs in what > I assume is the canonical ordering, and that looks a lot like > what the fltk-linux version is showing, except that the > fltk-linux version is joined up rather than single glyphs. > > So, I guess that's what the issue is - you need to pass the > fltk rendering code the strings composited into the display > order (at least under linux, anyway) and then they will > probably display OK. > > For that, you'll need to look at ICU or PanGo or something > for preparing the text strings, as that's way beyond the > scope of what fltk can do. 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-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
