2012/8/8 :
> For basic Unicode data that we need to render text, it might however make
> sense to keep a copy if this makes a big enough difference in performance.
Depends on what you mean by "a big enough difference in performance".
2012/8/8 :
> Let's just go through things and decide togethe
On Aug 8, 2012, at 2:35 PM, ext Konstantin Ritt wrote:
>>> Yes. We don't want to continue or begin to carry our own Unicode data, CLDR
>>> and timezone database. ICU provides all of that.
>
> So, does this mean I should abandon my QUnicode* and QText* changes/branches?
Depends on what they do.
>> Yes. We don't want to continue or begin to carry our own Unicode data, CLDR
>> and timezone database. ICU provides all of that.
So, does this mean I should abandon my QUnicode* and QText* changes/branches?
Konstantin
___
Development mailing list
Deve
ookay, let's use ICU for the url and regular expressions handling, the
text segmentation, the bidi itemization, the text layouting, and so
on; otherwise it's something like a bad joke to me...
Konstantin
2012/7/31 Thiago Macieira :
> On terça-feira, 31 de julho de 2012 14.25.26, Björn Breitmeyer
On terça-feira, 31 de julho de 2012 14.25.26, Björn Breitmeyer wrote:
> Hi,
>
> i am a bit confused now, will ICU be hard dependency on 5.0 instead of 5.1?
> As i already mentioned we are having problems with a hard ICU dependency
> for WindowsCE as its not supported by the ICU buildsystem.
It alr
Hi,
i am a bit confused now, will ICU be hard dependency on 5.0 instead of 5.1?
As i already mentioned we are having problems with a hard ICU dependency
for WindowsCE as its not supported by the ICU buildsystem.
Will ICU become part of the 3rdparty repo with a more cross platform friendly
builds
Quick discussion on IRC happened. This is a summary of the discussion and
proposal for the SDK.
Situation:
The ICU libraries *do* offer a stable C API, which they say they will maintain
and keep compatible. However, the library soname changes on every version and
most distributors enable symbol r
