[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