On 18 Jul 2011, at 17:02, Michael Sweet wrote: > We could certainly introduce Pango or ICU support as an experimental addition > in 1.3 and default in 3.0 for X11. The current situation definitely limits > how much Unicode can be supported without platform-specific code.
True - though we can do a lot with what we have now... Languages that are r2l we can *just about* manage, but as soon as we need to do any bi-dir text or complex text layout we run into troubles. On the other hand, we can cope with most LGC or CJK stuff now I think, and I've had a lot of success with using the higher planes music rendering sections. And we can render things like Cuneiform, Linear-B and Futhork now, which is obviously useful for everyday computing needs... >> - 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. > > You want line (or phrase) rendering; word rendering loses bi-dir text > handling. That would be my preference too - I was worried it might be viewed as too big a jump from our current per-glyph approach though. > Basically, fl_draw would need to be modified slightly to pass each line it > formats through Pango (or ICU) to generate the final display sequences. Yes, that would be good; make fl_draw handle the passed string as an entity and composing the string as a whole. I guess that still allows for the user to process text in smaller chunks by passing individual words, or even "characters", to fl_draw if they want to bypass the CTL. >> 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? > > It is, unfortunately, not the case... Ah, right. That's a pity, as I'd hoped it would Just Work... >> Something got clipped here? >> I guess "reposition the text on the line" or something? > > Ooops, must have deleted the rest by accident - "This could be used to > reposition widgets and change the appearance of widgets." Oh, I see; so if we determine the text is predominantly r2l for example, we could redraw the widgets for a r2l biased layout, that sort of thing? E.g. move the buttons in a stock dialog to the lower left rather than lower right, and so on? (Do we / should we, do that for r2l text? I don't know...) > >>> 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) > > > I've done enough wrappers - not a big deal to implement efficiently. Sounds like we might need that!
_______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
