On Tue, 22 Jul 2008 01:51:09 +0530 Gora Mohanty <[EMAIL PROTECTED]> babbled:
> On Tue, 22 Jul 2008 06:01:24 +1000 > Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote: > [...] > > this is why EFL doesn't have support. i'd have to write it all, OR use > > pango... and pango, last i looked, was not light on overhead, > > Agreed there. Have not actually benchmarked Pango myself, but by all > accounts it is resource-hungry, though that is probably not inappropriate > for a library aiming to handle all of Unicode. in all reality though - it's probably the ultimate way to go... or something of the kind... > > so as a matter of > > performance doing it the simple way its done now handles things for most > > people (who buy/use devices or linux systems as most people tend to speak a > > left-to-right friendly language). i have seen remarkably little interest in > > things like left-to-right languages over the years, and as there isn't a > > lot of demand and i don't actually speak any of these (i just speak > > european languages > > - a few of them, and east-asian languages), i just have never had it come up > > high enough on the list of things to do.. to ever do it. at least all the > > text internals are utf8 so... it's possible to do this without breakages... > > I would disagree here, though I can quite see why you might not want to > take this up. Having OpenMoko hardware handle Indic text would be a big > plus for its adoption here in India. An ability to send SMS in local > languages would be even more of a plus, though that will also have to > contend with service provider gateways that have no clue about UTF-8 or > Unicode. oooh - i was just talking about utf8 being how the code all deals with text. you have a lot fo glyph space available, so it's not limited. foo COURSE you will need to translate to other charsets when dealing with things like SMS, email etc. though natively id' say the software can just do all in utf8 and only when finally dealing with the GSM modem (or on receiving of SMS or email, and sending) then do the conversion to whatever charset is needed/desired. but as such utf8 should be enough of a superset for everything internally in applications and storage to just use it. > Given the current hardware limitations, the best approach for Indic > languages is probably to make a special font that includes all possible > glyph combinations, and a light-weight, custom rendering engine that > works with the font. This would also have the benefit of allowing the > rendering of Indic content on text-based terminals, such as the Linux > console. This is not really *that* hard a task, and from what I hear > various phone companies are sniffing around in India for someone able > to put this together. then you still need a converter tat converts series of chars into special utf8-encoded glyphs to represent this font... not pretty... but of course possible. > Regards, > Gora > > _______________________________________________ > Openmoko community mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/community -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
