On 07.10.2013, at 18:28, Darin Adler wrote:
> On Oct 7, 2013, at 1:34 AM, Patrick Gansterer wrote:
>
>> On 05.10.2013, at 19:13, Brent Fulgham wrote:
>>
>>> The WinCairo port is as close to the AppleWin port as possible. It uses ICU
>>> and I have no intention of changing that.
>>>
>>> The W
On Oct 7, 2013, at 1:34 AM, Patrick Gansterer wrote:
> On 05.10.2013, at 19:13, Brent Fulgham wrote:
>
>> The WinCairo port is as close to the AppleWin port as possible. It uses ICU
>> and I have no intention of changing that.
>>
>> The WinCE port is maintained by Patrick Gangsterer. I believe
On 05.10.2013, at 19:13, Brent Fulgham wrote:
> The WinCairo port is as close to the AppleWin port as possible. It uses ICU
> and I have no intention of changing that.
>
> The WinCE port is maintained by Patrick Gangsterer. I believe that this port
> does not want to use ICU, preferring to use
05.10.2013, в 04:09, Konstantin Tokarev написал(а):
> There is an issue with ICU: it uses UTF16 as its internal representation,
> while most of the Web nowadays is UTF8. Therefore, page text goes through
> unnecessary encoding conversion, and takes more memory than in UTF8 (for most
> of lang
> "Since ICU uses Unicode (UTF-16) internally, all converters convert
> between UTF-16 (with the endianness according to the current platform)
> and another encoding.”
The claim I would like to verify is that this design is slower and "takes more
memory” due to "unnecessary encoding conversion”.
I think the question was about the performance impact of using UTF-16 as
an internal representation of characters.
The original claim was in effect that the encoding conversion to UTF-16
is so costly that it offsets any gain of doing codepoint operations on
UTF-16 instead of UTF-8.
It is a very s
Geoffrey, http://userguide.icu-project.org/conversion/converters says:
"Since ICU uses Unicode (UTF-16) internally, all converters convert
between UTF-16 (with the endianness according to the current platform)
and another encoding."
That said, I don't think it's a major concern because ICU works
> There is an issue with ICU: it uses UTF16 as its internal representation,
> while most of the Web nowadays is UTF8. Therefore, page text goes through
> unnecessary encoding conversion, and takes more memory than in UTF8 (for most
> of languages). So it might be not a good development direction
The WinCairo port is as close to the AppleWin port as possible. It uses ICU and
I have no intention of changing that.
The WinCE port is maintained by Patrick Gangsterer. I believe that this port
does not want to use ICU, preferring to use the limited subset of i18n features
provided by the oper
05.10.2013, 09:38, "Darin Adler" :
> Hi folks.
>
> A while back the WebKit project made use of ICU directly. There were some
> port maintainers who instead wanted to make WebKit work without ICU. At the
> time, the strategy we pursued was to make a Unicode layer in WTF that layered
> on top of
On Oct 4, 2013, at 11:48 PM, Dirk Schulze wrote:
> On Oct 5, 2013, at 7:37 AM, Darin Adler wrote:
>
>> Any thoughts on this? I am not sure what the status of the WinCE port is,
>> but I’d like to hear from the maintainers of that port on the port status
>> and their view on this strategy.
>
On Oct 5, 2013, at 7:37 AM, Darin Adler wrote:
> Any thoughts on this? I am not sure what the status of the WinCE port is, but
> I’d like to hear from the maintainers of that port on the port status and
> their view on this strategy.
Do you really mean WinCE or WinCairo? I thought that WinCE
Hi folks.
A while back the WebKit project made use of ICU directly. There were some port
maintainers who instead wanted to make WebKit work without ICU. At the time,
the strategy we pursued was to make a Unicode layer in WTF that layered on top
of ICU. We then created multiple implementations o
13 matches
Mail list logo