Mike said: > FWIW, I would actually prefer that FLTK handles the conversion to display > order (as needed) since otherwise you end up with every Unicode app > re-implementing the same damn code, and all of the other > (mainstream/popular) GUI toolkits handle this for the developer as well.
This is true, of course, but could be a fair bit of work for us to make it fly - we would certainly be into the 1.4/3.x range for this! > Since Mac OS X and Windows provide the necessary support already, we > would just need to use ICU or Pango on the X11-based platforms to > achieve parity. I took a look at this (though very briefly) a while back, and it has a lot of "interesting" little "wrinkles" to it... I chickened out... There are a few things we'd want to do differently right up front to make this easier, for example: - switch to rendering (at least) word-by-word rather than glyph-by-glyph, as this makes it easier to interpret the context of each glyph in the word and composite it correctly. - consider doing a line-by-line render; this might make bi-dir text easier to grok. In particular, many nominally r2l texts are really bi-dir in practice, e.g. Arabic and Hebrew text is often bi-dir because, although the text section is r2l, it is not uncommon for numbers and foreign loan-words to appear in the string and be rendered l2r. So composing the entire line might be easier than each word... Maybe... > There are some other helpful things that FLTK could provide without a > lot of overhead/bloat: Though maybe with some extra dependencies... > 1. A number formatter and scanner that uses the current locale - > particularly for Arabic, but also to handle decimal and thousands > separators. I'd guess that ICU / PanGo / iconv must know this stuff anyway? Decimal / thousands seps is a bugbear for European texts too, of course, though we seem to be coping (or at least the non-English speaking members are tolerating our one-true-way solution!) Is there something specific about number handling for Arabic texts? I don't know but I always assumed, since the number system in Arabic texts is derived from broadly the same Indic sources as the numbers used in modern LGC scripts, that they would be more or less the same - is that not the case? > 2. A method that returns the default display order for the current > locale - left to right, right to left, top to bottom, bottom to top. Yup, again ICU and PanGo do this, AFAICT... > This could be used to reposition Something got clipped here? I guess "reposition the text on the line" or something? > 3. Methods to implement localization of strings (perhaps layered > on top of the corresponding OS API, or using FLTK-specific code - I > can contribute a .po/.strings file loader) Yup - gettext / catgets / whatever OSX and WINXX do... I have no real idea about this... 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
