[Development] Unicode/i18n support

lars.knoll at nokia.com lars.knoll at nokia.com
Fri Nov 25 13:14:01 CET 2011


On 11/25/11 11:42 AM, "ext Thiago Macieira" <thiago.macieira at intel.com>
wrote:

>On Friday, 25 de November de 2011 10:54:59 Simon Hausmann wrote:
>> > At the same time I'd propose to (over time) get rid of relying on
>>glibc,
>> > windows and Mac specific APIs as much as possible. We could also
>>remove
>> > most Unicode related data tables in Qt and only keep the ones that are
>> > performance relevant (text layouting relies on certain Unicode
>>tables, and
>> > it might be faster if we have inline access to these tables).
>> >
>> > 
>> >
>> > The things ICU supports that Qt doesn't currently offer could be
>>exposed
>> > through wrapper APIs over time. That task should be a lot simpler
>>than it
>> > would be today.
>> >
>> > 
>> >
>> > Opinions?
>> 
>> I think it's a good idea and with my WebKit hat on I'm all for it.
>>It'll 
>> simplify our code paths significantly and reduce maintenance overhead.
>
>With your provision above for inline access to important things, I'm all
>for 
>it too.
>
>Also note that some transformations we currently do in QString by
>accessing 
>the Unicode tables can probably be replaced by calls to ICU functions
>that 
>execute the same transformations (uppercasing, lowercasing,
>normalisation, 
>etc.)

Sure, these things are rarely as performance critical, and if done on a
whole string (not char by char), the call into ICU shouldn't be the big
issue.

In general, this would help reduce the burden of having to maintain a lot
of table data inside Qt.

Cheers,
Lars




More information about the Development mailing list